git untuk proyek pribadi (satu orang). Berlebihan?


84

Saya tahu, dan menggunakan, dua sistem kontrol versi: Subversi dan git. Subversion, seperti yang sekarang, digunakan untuk proyek-proyek pribadi di mana saya satu-satunya pengembang dan git digunakan untuk proyek-proyek sumber terbuka dan proyek-proyek di mana saya percaya orang lain juga akan bekerja pada proyek tersebut. Ini sebagian besar karena kemampuan forking dan penggabungan git yang luar biasa, di mana setiap orang dapat bekerja di cabang mereka sendiri; sangat berguna.

Sekarang, saya menggunakan Subversion untuk proyek pribadi, karena saya pikir git tidak masuk akal di sana. Tampaknya sedikit berlebihan. Tidak masalah bagi saya jika itu terpusat (di server rumah saya, biasanya) ketika saya adalah satu-satunya pengembang; Saya mengambil backup secara teratur. Saya tidak perlu kemampuan untuk membuat cabang saya sendiri, cabang utama adalah cabang saya. Ya, SVN memiliki dukungan sederhana untuk percabangan, tetapi dukungan yang jauh lebih kuat untuk itu tidak masuk akal, saya pikir. Penggabungan bisa menyebalkan, atau setidaknya dari pengalaman kecil saya.

Apakah ada alasan bagus bagi saya untuk menggunakan git pada proyek-proyek pribadi, atau hanya berlebihan?


61
Tidak, saya menggunakan git dan hg untuk proyek pribadi. Memiliki kontrol revisi lokal adalah anugerah.
wkl

7
Git dalam banyak hal lebih baik untuk semua proyek, apakah mereka memiliki banyak kontributor atau tidak: git memampatkan banyak hal, jauh lebih efisien daripada svn (dan urutan besarnya lebih cepat!), Git membuat cadangan sepele, dan git tidak akan menjadi penghalang jika orang lain ingin berkontribusi.
Artefact2

4
Saya menggunakan kontrol versi untuk mendorong kode saya ke github atau bitbucket, ini server sebagai cadangan untuk saya, dan mungkin suatu hari nanti saya akan benar-benar menulis sesuatu yang orang benar-benar akan tertarik.
Mahmoud Hossam

8
"Aku tidak butuh kemampuan untuk membuat cabang sendiri, cabang utama adalah cabang saya." Banyak orang mengatakan hal yang sama tentang undoketika itu merupakan fitur yang relatif baru dalam aplikasi. Sekarang semua orang menyadari bahwa mereka membutuhkannya selama ini. Anda perlu bercabang, Anda tidak tahu itu.
Dan Rosenstark

1
@ petugas ya, Anda bisa melakukan itu, tapi saya sebenarnya lebih suka lincah, meskipun saya lebih suka github daripada bitbucket.
Mahmoud Hossam

Jawaban:


155

Itu tidak berlebihan. Alasan utama mengapa saya mulai menggunakan Git dan Mercurial over Subversion untuk proyek pribadi adalah bahwa memulai repositori jauh lebih mudah.

Ingin memulai proyek baru?

> git init

BAM! Tidak perlu menyiapkan server repositori atau memeriksa struktur folder untuk mendukung percabangan dan tag ke repositori subversi.

Berbagi proyek Anda nanti hanyalah masalah: git push(selain memiliki repositori jarak jauh). Cobalah melakukannya dengan cepat dengan subversi!


24
Diterima Saya tidak bisa dibuktikan lebih salah tentang git menjadi berlebihan daripada ini;)
Anto

7
Steve341: Saya biasanya menyimpan semua proyek kode sumber dalam folder bernama "proyek". Di situlah saya menyimpan semua repositori, satu untuk setiap proyek kode sumber. Saya tidak pernah perlu melacak beberapa proyek bersama dalam satu dan VCS repositori yang sama; itulah gunanya sistem manajemen ketergantungan seperti Ivy atau Maven.
Spoike

3
@ Steve341 Bagaimana sulitnya melacak hal ini? Anda hanya memiliki satu folder yang berisi semua repo Anda. Tidak ada bedanya dengan sistem Anda, selain dari kenyataan bahwa sistem Anda adalah praktik yang sangat buruk ketika menggunakan git ...
alternatif

2
@ Steve314:echo 'for dir in projects/*; do cd "$dir"; git push; cd ..; done' > update_all; chmod +x update_all
André Paramés

2
git initdan bam! Oh ya dan kemudian cp ../the-other-project/.gitignore .sebelum komit awal. Bam!
Dan Rosenstark

46

Saya berpendapat bahwa menggunakan Subversion untuk proyek pribadi lokal adalah berlebihan, sedangkan Git jelas tidak. Git akan mengambil lebih sedikit ruang (karena konsep "revisi" SVN yang tidak efisien versus snapshot objek Git), memerlukan lebih sedikit pengaturan ( git initversus selusin svnadminperintah dan pengaturan izin dan sebagainya), lebih mudah untuk membuat cadangan ( git clone --bare[atau git push originjika Anda menggunakan Github atau serupa] dan Anda selesai), dan memiliki alat yang lebih baik untuk mengelola kode Anda (percabangan gratis, dan menggabungkan lebih mudah dan lebih bersih). Hanya karena tidak ada orang lain yang memiliki tiruan dari repositori Anda tidak berarti bahwa manfaat dari DVCS adalah "berlebihan."

Lebih jauh, saya akan mengatakan dukungan percabangan Git kurang kompleks daripada SVN, dengan hadiah yang lebih besar.


Saya kira saya seharusnya menggunakan "kuat" alih-alih "kompleks"
Anto

3
@Anto: Tidak masalah. Saya masih akan mengatakan hal yang sama: percabangan superior Git tidak memiliki kerugian, dibandingkan dengan SVN.
greyfade

3
Git juga tidak akan "mencemari" pohon sumber Anda dengan melacak file di setiap subdirektori.
WarrenT

4
@ WarrenT pohon sumber "polusi" tidak terjadi di svn versi 1.7 dan yang lebih baru.
plve

4
Membuat repositori filesystem di Subversion adalah satu perintah ( svnadmin create, ditambah satu untuk melakukan checkout awal atau impor), tidak perlu mengatur izin dan sebagainya. Saya tidak menyangkal bahwa Git seringkali merupakan alat yang lebih baik, tetapi ketidakakuratan tentang Subversion tidak membantu.
Josh Kelley

34

Untuk berpikir bahwa Anda tidak akan pernah melakukan percabangan kode Anda sendiri adalah pandangan pendek. Saya sudah beberapa kali melakukan percabangan kode saya sendiri, terutama ketika saya sedang bereksperimen dengan pendekatan baru yang belum sepenuhnya saya yakini. Anda akhirnya akan menginginkan fitur tersebut.

Ini berasal dari pengguna Subversion yang lama. Konsolidasi pada satu alat dapat sangat membantu membuat hidup Anda lebih mudah.


2
Ya saya percaya ini adalah titik cabang, eksperimen. Itu reservasi pertama saya ketika membaca pertanyaan Op. Jika Anda tidak bercabang di repositori Anda, Anda "bercabang" di kepala Anda dan ini tidak masuk akal ketika Anda memiliki kontrol versi di tempat.
Chris

3
Anda dapat bercabang dengan subversi. Dan bergabung. Semacam. Sebenarnya, satu-satunya waktu saya mencoba saya berakhir dengan repositori yang korup yang saya tidak bisa bekerja lagi, dan pulih dari cadangan (dengan cabang sudah diterapkan) tidak membantu, jadi saya akhirnya kehilangan semua sejarah dan memulai repositori baru ... tapi saya menyalahkan itu pada transisi dari 1.4.? ke 1,5 (saya pikir - beberapa tahun yang lalu sekarang). Mungkin bercabang dan menggabungkan karya, sungguh. Jika Anda cukup berani untuk mencobanya. Jika saya tahu tentang svn dump saat itu, saya bisa memperbaiki masalah dengan usaha, tentu saja.
Steve314

@ Chris, saya ingin memiliki versi yang dapat saya gunakan kapan saja. Tentu Anda bisa mencapainya dengan tag, tetapi ada kalanya cabang masuk akal. Jangan lupa manfaat lain dari git / mercurial.
Berin Loritsch

9

Overkill dicadangkan ketika ada kerusakan jaminan yang disebabkan oleh "solusi". Menggunakan senjata untuk membunuh lalat berarti ada kerusakan yang disebabkan oleh peluru yang pergi ke tempat lain. Itu berlebihan. Menggunakan sesuatu yang lebih kuat dari yang diperlukan yang tidak menyebabkan masalah tidak berlebihan dan bisa menjadi hal yang baik jika itu membantu Anda merampingkan proses pengembangan Anda. Itu tidak menyebabkan kerusakan dan memungkinkan Anda hanya perlu memperbarui satu set perangkat lunak, bukan dua. Jadi mengapa repot dengan dua sistem, bukan satu?


Mungkin berlebihan (ya, dengan definisi itu) jika sistem masuk ke jalan Anda. Saya bertanya-tanya apakah itu ide yang baik untuk menggunakan git untuk proyek pribadi. Bisakah Anda memberi tahu saya apa keunggulan spesifiknya ? Jawaban ini tidak membahas itu. Saya melihat git sebagai sistem yang lebih kuat, dan terlalu kuat untuk proyek pribadi. Tidak harus ada bahaya dalam hal itu, asalkan tidak menghalangi jalan Anda. Bisakah Anda memperluas jawaban Anda?
Anto

1
Overkill juga digunakan ketika upaya yang digunakan untuk menerapkan solusi di luar proporsi. Boleh dibilang, jika Anda sudah menggunakan subversi untuk proyek-proyek lokal, upaya yang diperlukan untuk mempelajari Git atau apa pun itu berlebihan. Atau mungkin pelajaran yang berguna untuk mengembangkan keterampilan yang bisa ditransfer, tentu saja. Secara pribadi, saya masih menggunakan subversi - ini menggigit saya beberapa kali, tetapi hanya meninggalkan bekas luka kecil. Saya tertarik mempelajari Git, tetapi setiap kali saya mencari, tutorial yang saya temukan samar atau saya tidak bisa mendapatkan alat yang stabil untuk Windows atau ada hambatan lain yang membuat semuanya tampak seperti, yah, berlebihan.
Steve314

7

Saya menggunakan Git untuk proyek one-man saya dan saya menyukainya. Saya sebelumnya menggunakan Subversion dan saya belum melihat kelemahan menggunakan Git. Ini lebih kuat tetapi tidak dengan cara yang membuat hal-hal sederhana menjadi lebih rumit. Membuat hal-hal sederhana yang tidak perlu rumit / mahal / lambat / dll. adalah IMHO kondisi yang diperlukan untuk memanggil sesuatu yang berlebihan. Juga, di Github saya telah bercabang proyek orang sebelumnya satu orang untuk menambahkan fitur yang saya inginkan dan kemudian mengirim mereka permintaan menarik. Saya akan merasa cukup keren jika seseorang yang tertarik dengan proyek saya melakukan hal yang sama.


7

Saya tidak pernah menggunakan kontrol sumber pada proyek pribadi sebelum DVCS, jadi agak aneh membayangkan seseorang mengambil pandangan sebaliknya. Beberapa alasan saya adalah:

  • Mudah diatur dan diruntuhkan. Sebagai contoh, seorang kolega memberi saya teka-teki pemrograman minggu lalu yang saya selesaikan dalam beberapa langkah kecil. Saya membuat repo git yang berlangsung selama 45 menit untuk menahan pekerjaan saya, dan kemudian hilang. Saya tidak tahu betapa mudahnya hal seperti itu dalam subversi, tetapi saya belum pernah mendengar ada yang melakukannya.
  • Terputus. Bagi saya, dapat bekerja secara offline jauh lebih bermanfaat bagi proyek hobi daripada pekerjaan. Saya tidak perlu membuat lubang di firewall rumah saya atau menjadi tuan rumah proyek secara publik. Saya dapat sementara meletakkan repo di thumb drive atau laptop, dan masih menyimpan semuanya dalam sinkronisasi.
  • Semuanya ada. Memiliki repo dan pohon kerja bersama membuat proyek-proyek kecil lebih mudah untuk melacak selama hal-hal seperti peningkatan OS.
  • Fitur hebat. Tentu, saya tidak membutuhkan daya sepanjang waktu, tetapi ada di sana ketika saya membutuhkannya, dan tidak mengkonsumsi sumber daya apa pun ketika saya tidak.

6

Saya telah diberitahu bahwa git-bisectsangat bagus untuk menemukan komit yang memperkenalkan perilaku tertentu, dengan menavigasi bolak-balik dalam komit tergantung pada input Anda.

Anda akan harus melakukan beberapa hari untuk hal-hal Anda tidak tahu apa yang telah terjadi.


EDIT: Juga, kemampuan untuk bercabang sangat penting ketika Anda harus melakukan perbaikan bug di versi lama yang digunakan pelanggan. Anda harus dapat mengelola "perbaiki hal kecil ini tetapi saya tidak ingin versi terbarunya karena saya tidak ingin mengujinya lagi sekarang".


2

Itu tergantung pada seberapa serius Anda ingin mendapatkan versi kode Anda sendiri. Jika yang Anda bangun misalnya perpustakaan sederhana yang hanya akan memiliki versi saat ini (atau selama itu benar), saya pribadi hanya akan menggunakan opsi cadangan dasar seperti Dropbox. Jika Anda kehilangan semua kode, Anda dapat memulihkannya dari web, dan Dropbox memiliki cadangan versi 30 hari jika Anda benar-benar melakukan sesuatu yang bodoh.

Namun jika Anda misalnya perlu mempertahankan cabang-cabang Production dan Dev, maka git benar-benar alat yang hebat - dan cara yang jauh lebih cepat daripada svn. Pikirkan risiko kegagalan hard drive jika Anda hanya menyimpan data secara lokal.


1
Ya saya menggunakan DropBox untuk proyek pribadi. Versi ini sama sekali tidak secanggih VCS sejati, tetapi tidak masalah untuk proyek-proyek kecil yang saya lakukan di waktu luang, dan tidak memerlukan perhatian sama sekali (mis. Tidak ada komitmen, file hanya diperbarui saat Anda mengerjakannya.)
jhocking

oh dan kebetulan karena saya mengembangkan game, proyek saya cenderung memiliki banyak file biner (file gambar, klip audio, dll.) dan sebagian besar sistem kontrol versi benar-benar hanya ditujukan untuk kode sumber.
jhocking

Git bekerja dengan baik dengan file biner, perbedaannya hanya kurang menarik. Untungnya perbedaan dalam git tidak sepenuhnya terkunci - jika Anda dapat menemukan alat diff biner yang Anda sukai, Anda dapat menggunakannya dengan git dengan mudah (dari baris perintah)
Chris Moschini

Saya diberitahu bahwa Git membuang banyak file biner versi ruang, tetapi apa yang saya katakan mungkin salah. Pada dasarnya, saya diberitahu bahwa sebagian besar aset biner (saya kira tidak semua file biner, tetapi gambar dan suara yang masuk ke permainan) harus diselamatkan seluruhnya setiap versi sehingga Git mengisi hard drive Anda dengan repositori lokal.
jhocking

Ini hanya boros jika Anda tidak bermaksud membuat versi file biner. Jika Anda perlu membuat versi mereka, maka sejarah versi tidak sia-sia. Saya pikir mereka secara tidak sengaja menyiratkan git gembung sejarah versinya ketika melacak biner - itu tidak benar. git.wiki.kernel.org/index.php/GitSvnComparsion
Chris Moschini

2

Saya selalu, selalu, selalu menggunakan sistem kontrol versi untuk segala jenis proyek pengembangan. Besar, atau kecil benar-benar tidak masalah. Apakah saya bermain di rumah dengan semacam teknologi baru, menulis sedikit pembantu untuk memudahkan hidup saya atau berkembang secara profesional dalam tim yang besar dan terdistribusi - saya selalu ingin sistem kontrol versi mendukung saya.

Tentu, sebagian besar waktu untuk proyek pribadi kecil Anda tidak akan menggunakan sebagian besar fitur, tetapi menyiapkan repositori git (atau bahkan repositori Subversion lokal) bukan masalah besar, jadi lakukanlah! Dan sebelum Anda menyadarinya, Anda pasti ingin tahu "sial, apa isi file X Jumat lalu?". Tanpa kontrol versi - semoga berhasil ;-)

Jadi, itu benar-benar tidak masalah jika Anda menggunakan git atau SVN - secara pribadi saya mulai bermigrasi semakin banyak barang dari SVN ke git tetapi yang utama adalah menggunakan kontrol versi sama sekali - bahkan untuk hal-hal kecil.


1

Hanya karena tidak ada yang menyebutkannya: untuk proyek pribadi, darcs benar-benar bagus, dan kurang terlibat daripada git untuk melakukan kontrol versi secara langsung. Ini tidak secepat untuk proyek yang lebih besar, tetapi kemudian, Subversion juga tidak!


1
Kedengarannya agak terkait dengan seberapa baik Anda tahu darcs. Saya tidak pernah menggunakannya tetapi banyak menggunakan git. Bagi saya, git sangat lurus ke depan, tetapi saya yakin saya akan menggaruk-garuk kepala jika saya ingin menggunakan darcs.
Sam

1
Jika Anda sudah menguasai ui git yang gila, darcs akan menjadi cakewalk.
wlangstroth

1
dapatkah Anda menjelaskan mengapa darcs lebih baik untuk proyek kecil daripada git?
shabunc

0

Ini bisa menjadi perubahan paradigma mental yang kuat untuk memahami bahwa apa yang kita lakukan adalah eksperimen. Memiliki alat yang murah / mudah untuk mendukung ini, meningkatkan kemampuan Anda untuk bergerak maju, sebagian karena hal itu meningkatkan kemampuan Anda untuk mundur dari eksperimen apa pun ketika hasilnya buruk.

Banyak pengembang berkata, Yah saya hanya membuat salinan kode saya. Tetapi salinan ini menjadi sulit untuk dikelola dan berakhir sebagai kekacauan. Anda memiliki banyak salinan dan tidak dapat mengingat salinan mana untuk apa, dan kemudian mencoba mencari tahu kapan aman untuk menghapusnya.

Semua ini menjadi lebih berharga ketika percobaan memerlukan perubahan terkoordinasi di beberapa file. Dan ketika itu adalah proyek solo menggunakan Git menjadi lebih sederhana.

Alih-alih bertanya-tanya apakah saya harus menggunakannya pada proyek solo, saya sekarang berpikir betapa memalukannya saya belum menemukan ini lebih cepat.


Untuk pandangan desainer tentang ini, tonton Linus on Git di YouTube (~ 70 mnt)
WarrenT
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.