Sebagai pengembang tunggal (untuk saat ini), bagaimana saya harus menggunakan Git? [Tutup]


60

Saya punya banyak proyek di Git yang akhirnya ingin saya bawa ke orang lain. Namun, sekarang ini hanya saya dan saya menggunakan Git dan GitHub dengan sangat sederhana: tidak ada cabang dan pada dasarnya hanya menggunakan komit sebagai cadangan untuk file lokal saya. Kadang-kadang saya akan kembali dan melihat versi sebelumnya dari file saya untuk referensi, tetapi saya tidak perlu melakukan rollback ke titik ini, meskipun saya menghargai opsi yang harus saya butuhkan di masa depan.

Sebagai pengembang tunggal, fitur Git atau GitHub apa yang dapat saya manfaatkan yang akan bermanfaat bagi saya saat ini? Seperti apa seharusnya alur kerja saya?

Juga, apakah ada praktik tertentu yang perlu saya mulai lakukan dalam mengantisipasi penambahan orang lain ke proyek saya di masa depan?


3
Seperti yang dijelaskan orang lain, Git memberi Anda banyak kekuatan. Namun, sebagai pengembang tunggal, hal besar yang akan Anda hargai nanti adalah jika memberi Anda catatan tentang perubahan apa yang Anda buat (mengelompokkan perubahan dalam beberapa file menjadi satu set), saat Anda membuatnya dan mengapa! Ini juga latihan yang bagus untuk ketika Anda menjadi bagian dari tim.
Leading Geek

1
Tertutup karena menarik. :)

@ user93458 seperti biasa! Topik tertutup biasanya tepat seperti yang saya cari.
Miroslav Popov

pertanyaan luar biasa yang seharusnya tidak pernah ditutup.
volume satu

Jawaban:


64

Juga, apakah ada praktik tertentu yang perlu saya mulai lakukan dalam mengantisipasi penambahan orang lain ke proyek saya di masa depan?

Tentu saja. Ada praktik bagus dan sederhana yang dapat Anda gunakan bahkan jika Anda tidak memiliki tim saat ini: buat cabang terpisah untuk pengembangan. Idenya adalah bahwa cabang utama hanya akan berisi versi kode yang dirilis atau perubahan besar. Ini dapat diadopsi dengan mudah oleh pengembang baru yang bergabung dengan proyek Anda.

Selain itu, percabangan berguna bahkan jika Anda bekerja sendiri. Misalnya, Anda menemukan bug saat dalam proses pengkodean fitur baru. Jika Anda tidak menggunakan cabang, Anda harus melakukan keduanya: menambahkan fitur baru dan memperbaiki bug di cabang yang sama. Ini tidak baik: P Di sisi lain, jika Anda telah membuat cabang baru untuk membuat fitur baru Anda, Anda bisa checkout cabang pengembangan, memperbaiki bug, dan checkout kembali cabang fitur baru.

Ini hanyalah contoh singkat dari apa yang dapat Anda lakukan sebagai programmer tunggal. Saya yakin pasti ada lebih banyak praktik baik.

Saya sangat merekomendasikan Anda artikel ini: Model percabangan Git yang sukses


+1 - Itu masuk akal. Saya akan melihat lebih dekat pada artikel itu juga, itu terlihat sangat berguna.
VirtuosiMedia

Saya bukan spesialis git, kebanyakan pengguna Mercurial. Apakah nasihat cabang dev ini masih berlaku dalam kasus Mercurial? Sepertinya tidak, tapi mungkin beberapa perbedaan membuatnya bukan ide yang baik dalam kasus ini?
Klaim

2
Ya, itu cukup berlaku untuk semua kontrol sumber. Saya benar-benar melakukannya mundur dengan SVN; trunk "utama" adalah untuk pengembangan terbaru, yang berlangsung setiap hari atau bahkan lebih sering. Ketika sebuah rilis dipanggil, kodenya dibekukan dan dipotong cabang. Cabang itu hanya mendapat pembaruan kecil untuk memperbaiki masalah rilis utama, dan kemudian didistribusikan dapat dibuat dari itu. Dengan begitu, saya memiliki cabang kode sumber di belakang setiap versi yang dirilis. Ini lebih baik daripada hanya menandai atau memberi label b / c jika komit masuk setelah label tetapi sebelum rilis, Anda tidak tahu apakah mereka benar-benar dikecualikan.
KeithS

+1 untuk artikel; @Klaim - yup, berfungsi juga untuk hg. benar-benar harus disebut "model percabangan DCVS yang sukses"
Wyatt Barnett

Terima kasih +1 untuk tautannya, itu mengubah cara saya akan bekerja dengan git, tidak dengan banyak pikiran tetapi seperti yang mereka katakan, setiap sedikit membantu!
Newtopian

14

Saya persis dalam situasi ini, tetapi saya memang memilih alur kerja yang sedikit lebih kompleks meskipun tidak harus lebih rumit dengan Git.

Tujuan awalnya adalah mempelajari cara git jadi saya melakukan sejumlah penjelajahan. lalu kembali ke cukup banyak alur kerja yang Anda gambarkan.

Setelah beberapa saat ini menjadi sulit untuk dikerjakan karena beberapa situasi muncul juga memberi saya kebiasaan buruk yang akan sulit untuk dihancurkan begitu saya bergabung dengan tim.

jadi saya memilih yang berikut:

  • Repositori lokal untuk bekerja.
  • Cabang induk sebagai batang stabil untuk aplikasi
  • Satu cabang untuk setiap fitur / refactor, pada dasarnya satu cabang untuk setiap perubahan yang cukup besar yang akan dilakukan.
  • Gabungkan kembali ke bagasi ketika cabang stabil dan semua tes lulus.

Saya juga mengatur akun hub git tempat saya menyinkronkan trunk. Ini memungkinkan saya untuk dengan mudah mulai bekerja pada komputer yang berbeda. Itu karena kebutuhan tetapi memungkinkan saya untuk menemukan bug yang terkait dengan lingkungan saya di mana tidak tersedia di komputer lain. Jadi sekarang saya biasakan untuk mencoba proyek pada sistem "perawan" yang berbeda setidaknya sekali. Menghemat banyak sakit kepala ketika tiba saatnya untuk menyebar ke pelanggan.

  • Saya menandai setiap versi yang membuatnya menjadi github sebagai versi yang dapat dirilis.
  • Jika dirilis ke pelanggan saya akan cabang dari versi ini untuk membuat trunk stabil kedua untuk perbaikan bug yang dinyatakan oleh pelanggan.

Cabang-cabang ganda pada awalnya tampak seperti berlebihan tetapi itu BENAR-BENAR banyak membantu. Saya dapat memulai sebuah ide di cabang, mengerjakannya sebentar dan ketika saya mulai menjalankan lingkaran saya menyerah dan memulai cabang lain untuk mengerjakan sesuatu yang lain. Kemudian sebuah ide muncul dimana saya akan kembali ke cabang setengah matang dan mengeksplorasi ide ini. keseluruhan ini membuat saya JAUH lebih produktif karena saya bisa bertindak cepat dan ide sangat cepat dan melihat apakah itu berhasil. Biaya beralih cabang dengan GIT sangat rendah membuat saya sangat gesit dengan basis kode saya. Yang mengatakan saya masih harus menguasai konsep rebase untuk membersihkan sejarah saya, tetapi karena saya sendirian saya ragu saya benar-benar perlu. Mendorongnya sebagai "senang belajar".

Ketika semua percabangan menjadi rumit maka saya menjelajahi opsi log untuk menggambar pohon perubahan dan melihat cabang mana yang ada.

Singkat cerita, git tidak seperti SVN, CVS, atau (brrr) TFS. Bercabang sangat murah dan membuat kesalahan yang akan menghapus pekerjaan sebenarnya cukup sulit. Hanya sekali saya kehilangan beberapa pekerjaan dan itu karena saya membuat komitmen saya terlalu besar (lihat kebiasaan buruk di atas). Jika Anda sering melakukan, dengan git kecil git pasti akan menjadi sekutu terbaik Anda.

Bagi saya git membuka pikiran saya tentang apa sebenarnya kontrol sumber. Yang lain sebelumnya hanyalah upaya untuk mendapatkannya, git adalah yang pertama, yang ada di pikiran saya, mengerti. Yang mengatakan, saya tidak mencoba DVCS lain, sangat mungkin pernyataan ini bisa melebar ke seluruh keluarga.

Satu saran terakhir, baris perintah adalah teman Anda. Bukan untuk mengatakan bahwa alat grafis tidak baik, justru sebaliknya tetapi saya benar-benar groked git ketika saya turun ke baris perintah dan mencobanya sendiri. Ini sebenarnya dibuat dengan sangat baik, mudah diikuti dengan sistem bantuan yang sangat komprehensif. Masalah terbesar saya adalah terikat pada konsol jelek di windows sampai saya menemukan alternatif.

Sekarang saya menggunakan keduanya, Eclipse integrasi dengan Git untuk melihat apa yang terjadi secara real time dan melakukan beberapa operasi seperti diffs, menjelajahi sejarah file, dll. Dan baris perintah untuk percabangan, penggabungan, mendorong, mendapatkan dan pohon log yang lebih kompleks . beberapa scripting dasar dan saya tidak pernah begitu produktif dalam hal kontrol sumber dan saya tidak pernah memiliki begitu banyak kendali atas sumber saya.

Semoga berhasil, semoga ini membantu.


4

Saya berpengalaman dalam beberapa model percabangan yang canggih, dan menggunakannya di tempat kerja. Namun, ketika saya bekerja sendirian di proyek, saya melakukan persis apa yang Anda lakukan sekarang. Saya selalu dapat membuat cabang setelah fakta jika saya membutuhkannya, tetapi saya hampir tidak pernah melakukannya. Bekerja sendiri, saya jarang memiliki perbaikan bug yang tidak bisa menunggu sampai tugas saya saat ini selesai. Saran saya adalah membiasakan diri dengan beberapa model percabangan, tetapi tidak ada hal-hal rumit yang perlu Anda lakukan.


4

Untuk model yang lebih sederhana, Anda dapat melihat apa yang dilakukan GitHub. "Aliran GitHub" sangat sederhana, dan ada panduan yang sangat bagus di sini: https://guides.github.com/introduction/flow/index.html

Ringkasan (dari blog Scott Chacon ):

Jadi, apa itu GitHub Flow?

  • Apa pun di cabang master dapat digunakan
  • Untuk mengerjakan sesuatu yang baru, buat cabang off of master yang dinamai secara deskriptif (yaitu: new-oauth2-scopes)
  • Berkomitmen untuk cabang itu secara lokal dan secara teratur mendorong pekerjaan Anda ke cabang bernama yang sama di server
  • Saat Anda membutuhkan umpan balik atau bantuan, atau Anda pikir cabang siap untuk digabung, buka permintaan tarik
  • Setelah orang lain meninjau dan menandatangani fitur, Anda dapat menggabungkannya menjadi master
  • Setelah digabung dan didorong ke 'master', Anda bisa dan harus segera menyebar
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.