cara menggunakan kontrol versi


19

Saya sedang mengembangkan situs web dalam php di localhost dan ketika modul-modulnya selesai, saya mengunggahnya di cloud sehingga teman-teman saya bisa mengujinya.

Ketika saya terus berkembang, saya punya banyak file dan saya kehilangan jejak file mana yang telah saya edit atau ubah dll. Saya pernah mendengar sesuatu sebagai 'kontrol versi' untuk mengelola semua itu tetapi tidak yakin bagaimana cara kerjanya.

Jadi, pertanyaan saya adalah: Apakah ada cara / layanan / aplikasi yang mudah tersedia bagi saya untuk melacak semua pengeditan / perubahan / file baru dan mengelola file saat saya mengembangkan situs web. Segera setelah saya selesai dengan sebuah modul, saya ingin mengunggahnya di cloud (Saya menggunakan Amazon Cloud Service). Jika terjadi sesuatu pada file baru, saya mungkin ingin kembali ke file lama. Dan mungkin, dalam satu atau dua klik, saya bisa melihat file yang telah saya edit atau ubah sejak yang terakhir saya unggah?


5
Ada banyak saran tentang sistem kontrol versi apa yang digunakan, dan jujur, semuanya lebih baik daripada cara "manual" Anda saat ini.
Johan

Jawaban:


28

Manajemen konfigurasi perangkat lunak , di mana Kontrol Versi menjadi bagiannya, sedikit lebih rumit daripada melacak perubahan pada file, walaupun Anda tentu bisa mulai dengan itu. Tapi baca artikel Wikipedia yang ditautkan di atas bersama dengan tutorial Joel Spolky tentang Mercurial .

Untuk memulai, pilih salah satu Mercurial, GIT, atau Bazaar, dalam urutan itu, dan instal bersama dengan alat untuk IDE dan sistem operasi Anda (saya lebih suka Mercurial dengan HGE untuk Eclipse).

  1. Inisialisasi repositori dari direktori kerja Anda ( hg init dengan Mercurial) ..
  2. Tentukan file dan direktori mana yang ingin Anda lacak dan mana yang tidak. Aturan umum adalah untuk tidak melacak file yang dihasilkan oleh kompiler dan alat lainnya.
  3. Gunakan perintah untuk menambahkan file dan direktori ke repositori ( hg add for Mercurial).
  4. Beri tahu alat tentang pola untuk file yang tidak ingin Anda lacak (edit .hgignore untuk Mercurial).
  5. Lakukan komit untuk melacak versi asli ( hg ci ).
  6. Lakukan komit setelah setiap tonggak logis, bahkan jika itu kecil.
  7. Tambahkan file baru saat Anda membuatnya.
  8. Ulangi dua yang terakhir.
  9. Cadangkan direktori kerja Anda dan repositori sesering mungkin.

Dengan file Anda di repositori, Anda dapat mengetahui perbedaan antara dua versi file atau direktori, atau proyek lengkap ( hg diff ), melihat riwayat perubahan ( hg hist ), dan memutar kembali perubahan ( hg up -r ).

Merupakan ide bagus untuk memberi tag (tag hg ) repositori sebelum menerbitkan kode Anda sehingga ada cara mudah untuk kembali ke apa yang Anda terbitkan untuk amandemen atau perbandingan.

Jika Anda ingin bereksperimen dengan jalur pengembangan yang berbeda, lakukan dalam cabang sederhana dengan mengkloning repositori utama ( klon hg ) dan tidak mendorong kembali sampai eksperimen tersebut konklusif. Semudah memiliki direktori kerja yang berbeda untuk percobaan.

Jika percobaan adalah untuk versi baru, versi yang ditingkatkan kemudian klon dan kemudian cabang ( cabang hg ) sehingga Anda dapat menyimpan semua salinan dari repositori yang diperbarui tanpa satu percobaan mengganggu yang lain.

Linus Torvalds (yang berurusan dengan puluhan ribu file dan jutaan baris kode dalam proyeknya) memberi ceramah di Google tentang mengapa alat itu tidak bisa CVS, SVN, atau salah satu dari banyak yang gratis dan komersial di sekitar ; sangat layak ditonton.


1
Saya lebih suka Mercurial juga. Saya suka dukungan di Netbeans karena saat Anda mengkodekan itu menunjukkan setiap baris yang telah berubah sejak komit terakhir Anda. Itu juga kode warna file baru / diubah / tidak berubah di pohon produk. Yang suara seperti itu akan sangat membantu untuk OP: I lose track of which file I've edited or changed. HGE dapat melakukan ini juga, saya belum menggunakannya.
JD Isaacks

1
+1 untuk menjelaskan proses serta bagian dari cara menggunakan alat untuk melakukannya.
Donal Fellows

Sebagai pertanyaan sampingan, apakah .xcodeprojfile yang Xcode gunakan untuk proyek iOS dianggap sesuatu yang harus diabaikan Mercurial, atau apakah penting untuk menjaga file tetap sinkron?
Kevin Yap

1
@Kevin Saya tidak tahu tentang Xcode, tetapi IDE dan alat terbaru memiliki file konfigurasi terpisah untuk hal-hal proyek secara keseluruhan (bahasa dan versi perpustakaan, aturan pemformatan kode, dependensi, dll.) Dan preferensi pengguna (direktori tempat saya meletakkan barang, panel tata letak, skin, ukuran font, tanda tangan pribadi). Yang pertama dapat dimasukkan dalam repositori jika tim setuju. Yang terakhir tidak boleh dimasukkan, karena pembaruan dari repositori akan menimpa preferensi Anda dengan milik orang lain, dan itu menjadi cepat menjengkelkan dan kontraproduktif.
Apalala

1
@ John: NetBeans melakukan itu untuk setiap VCS yang didukungnya. Pada titik ini, itu hanya fitur dasar dari IDE.
Mike Baranczak

13

Saya akan sangat merekomendasikan Git. Pelajari tentang ini di sini: https://lab.github.com/

Jika Anda tidak menyukai Git, ada solusi kontrol versi lainnya. Anda mungkin memeriksa SVN.


1
Sebagai pengguna Git sehari-hari, saya ingin menambahkan bahwa sangat mudah dan intuitif untuk mengambil perintah penting. Dan dukungannya sangat bagus sehingga Anda tidak akan tersesat saat mencari bantuan. Saya telah menggunakan SVN tetapi itu tidak mudah bagi saya tetapi mungkin tidak apa-apa bagi banyak pengguna.
Muhammad Usman

1
+1 Juga pertimbangkan: orang memilih untuk pindah dari svn (a VCS) ke git (a DVCS - d = didistribusikan) tetapi tidak dari GIT ke SVN (melalui pilihan).
Michael Durrant

7

Apakah hanya Anda ?, gunakan DVCS

Seperti kontra-intuitif seperti kedengarannya, Sistem Kontrol Versi Terdistribusi (mercurial, git, bazaar) lebih baik untuk memulai daripada sistem terpusat (svn, cvs). Mengapa ?, Anda menginstalnya di mesin Anda dan menjalankan repositori Anda secara lokal, dan hanya itu. Pada sistem terpusat seperti svn Anda perlu mengatur klien dan server Anda ... dan kemudian, Anda harus terhubung ke server untuk menyimpan perubahan Anda.

Dengan DVCS, Anda, repositori lokal, dan jika Anda mau, Anda dapat menggunakan layanan seperti bitbucket.org atau github.com.

IMHO, lincah adalah DVCS yang lebih ramah dan berkemampuan sama.

Apakah ada yang lain ?, gunakan DVCS!

Ada banyak keuntungan ketika menggunakan DVCS untuk bekerja dengan tim, yang paling penting berbeda dengan sistem terpusat adalah bahwa tidak ada ras komit dan ini karena, secara teknis, repositori masing-masing individu adalah cabang, dan ketika Anda berbagi perubahan cabang-cabang tersebut digabung untuk Anda dan Anda bahkan tidak menyadarinya, artinya alih-alih memiliki riwayat versi seperti ini, di mana Anda memiliki orang-orang yang menyalurkan pekerjaan mereka pada garis lurus:

masukkan deskripsi gambar di sini

Anda akhirnya memiliki sesuatu seperti ini, di mana semua orang melakukan ad hoc:

masukkan deskripsi gambar di sini

Masing-masing hanya khawatir tentang pekerjaan mereka sendiri saat versi (yaitu tidak berlomba untuk melakukan) dan tidak khawatir tentang koneksi ke server hanya untuk melakukan.

Semoga berhasil


1
+1 Contoh yang sangat bagus! Anda harus mengedit untuk menekankan rasa sakit yang tidak ada di pohon menggabungkan kompleks dengan alat modern.
Apalala

5

Singkatnya, ada banyak alternatif, di antaranya Subversion (SVN) dan Git tampaknya paling populer (sehingga termudah untuk menemukan solusi di web).

Keduanya berbeda. SVN lebih sederhana, tetapi Git tidak mengharuskan Anda untuk memiliki server untuk memulai - Anda dapat mengontrol versi secara lokal.

Dengan asumsi Anda memiliki Linux dan ingin mulai menggunakan Git:

  1. Instal Git
  2. Pergi ke direktori dan jalankan perintah 'git init'
  3. Pelajari cara menambahkan file, meninjau perubahan, mengkomitnya ...
  4. ... dan untuk melakukan hal-hal yang lebih maju (meninjau log, mengembalikan perubahan, mengabaikan file, membuat cabang, menggabungkannya, membuat dan menggunakan remote, menggunakan submodul, menggunakan dukungan SVN dll.).

Semoga ini bisa membantu Anda memulai.


1
SVN tidak memerlukan server, tetapi itu mengharuskan repositori berada di direktori yang berbeda dari yang berfungsi. SVN dan CVS umumnya tidak digunakan lagi karena mendukung alat-alat seperti GIT dan Mercurial yang tidak memerlukan koneksi jaringan untuk pekerjaan sehari-hari dan tidak memerlukan repositori pusat untuk pengembangan perangkat lunak kolaboratif dan terdistribusi.
Apalala

Tidakkah Anda pikir ini sebenarnya identik dengan membuat server repositori SVN di localhost? Yang Anda butuhkan adalah mengonfigurasi repositori pusat dan memeliharanya dan ketika Anda memindahkan file Anda, Anda harus memastikan repositori SVN masih dapat diakses (bahkan tidak berpikir tentang menyalin seluruh repositori pusat setiap kali Anda memindahkan file ke mesin yang berbeda). Juga saya tidak berpikir Subversion sudah usang (saya tidak berbicara tentang CVS) - itu hanya terpusat dan dalam beberapa kasus itu akan menjadi ide yang lebih baik untuk menegakkan sentralisasi.
Tadeck

Apalala, beberapa pertanyaan: bagaimana Mercurial menangani informasi yang diubah oleh pengguna tertentu? Di Git Anda dapat mengubahnya dan melakukan perubahan sebagai orang lain, sehingga membuat beberapa kekacauan (ada beberapa fitur untuk membedakan komiter dari submitter, tetapi tidak cukup jelas). Apakah Mercurial telah memecahkan masalah terkait distribusi-versi-kontrol ini?
Tadeck

2
@Tadeck Bukan itu cara Mercurial dan GIT bekerja dalam pemahaman saya. Dalam hal ini, satu orang bertanggung jawab atas apa yang masuk ke dalam repositori, baik itu dengan komitmen, tarikan, atau tambalan. Dalam repositori yang didistribusikan, jika seseorang memiliki hak istimewa, maka Anda sudah mempercayainya dengan sepenuh hati. Linus Torvalds menjelaskannya dengan baik dalam pembicaraan ini: youtube.com/watch?v=4XpnKHJAok8
Apalala

@Tadeck Mengenai SVN, saya sering menggunakannya, dan akhirnya saya berpikir bahwa itu tidak ada perbaikan terhadap CVS (yang setidaknya memiliki repositori polos-ASCII dan cukup dewasa untuk tidak pernah merusak mereka). Sekali lagi, Torvalds menjelaskannya dengan baik di video yang saya tautkan sebelumnya. Ketidakmampuan untuk melakukan pekerjaan offline, dan ketidakmampuan untuk menggabungkan membuat alat SCM yang lama menjadi usang.
Apalala

2

Seperti yang disarankan Apalala, saya sarankan checkout hginit . Karena Anda baru mengenal kontrol versi, Anda dapat melewati halaman pertama. Itu seharusnya memberi Anda intro yang bagus, setelah itu Anda dapat memposting di SO jika Anda memiliki pertanyaan spesifik.


0

Saya akan menentang opini mayoritas, dan merekomendasikan Subversion. Subversi mudah digunakan, dan melakukan semua hal yang dibutuhkan individu dan tim kecil. Ini adalah produk yang matang, sehingga setiap IDE di luar sana memiliki dukungan yang baik untuk itu. Ya, itu tidak memiliki semua fitur Git. (Saya tidak pernah menggunakan Mercurial, jadi saya tidak akan membicarakannya.) Tetapi kebanyakan pengembang sebenarnya tidak membutuhkan fitur-fitur yang ditambahkan.

Beberapa tempat penyimpanan? Saya yakin ada beberapa kegunaan yang sah untuk itu, tapi saya tidak pernah bertemu dengannya.

Mampu membuat komitmen lokal, tanpa akses jaringan? Itu bagus untuk dimiliki, jika Anda membuat beberapa perubahan terpisah, dan Anda tidak dapat mengakses server repositori - tetapi jujur, seberapa sering hal itu terjadi?

Git memang membuatnya lebih mudah untuk berurusan dengan percabangan dan penggabungan. Tapi untuk tim satu orang, itu bukan masalah besar.

Untuk sesuatu pada skala kernel Linux - ya, gunakan Git. Bagi kita semua, Subversi cukup bagus.


Downvoting. Fitur-fitur Git yang tidak ada dalam SVN (seperti percabangan yang ringan dan penggabungan yang mudah) sangat membantu, mungkin bahkan penting, pada proyek-proyek kecil sebanyak pada yang besar.
Marnen Laibow-Koser

1
@ MarnenLaibow-Koser Ya, itu pendapat saya saat itu, tetapi setelah menggunakan Git secara profesional selama beberapa tahun, saya harus setuju dengan Anda.
Mike Baranczak

Luar biasa! Anda akan berasimilasi. : D
Marnen Laibow-Koser

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.