alur kerja tim github - untuk bercabang atau tidak?

Kami adalah tim kecil pengembang web yang saat ini menggunakan subversi tetapi segera kami beralih ke github.

Saya melihat berbagai jenis alur kerja github, dan kami tidak yakin apakah seluruh konsep forking di github untuk setiap pengembang adalah ide yang bagus untuk kami.

Jika kita menggunakan garpu, saya mengerti bahwa setiap pengembang akan memiliki repositori lokal & jarak jauh pribadi. Saya khawatir itu akan membuat mendorong perubahan sulit dan terlalu rumit. Juga, kekhawatiran terbesar saya adalah bahwa hal itu akan memaksa setiap pengembang untuk memiliki 2 remote: origin (yang merupakan fork jarak jauh) dan upstream (yang digunakan untuk "menyinkronkan" perubahan dari repositori utama). Tidak yakin apakah itu cara mudah untuk melakukan sesuatu.

Ini mirip dengan alur kerja yang dijelaskan di sini: https://github.com/usm-data-analysis/usm-data-analysis.github.com/wiki/Git-workflow

Jika kita tidak menggunakan garpu, kita mungkin dapat melakukannya dengan baik dengan menggunakan repo pusat membuat cabang untuk setiap tugas yang sedang kita kerjakan, dan menggabungkannya ke cabang pengembangan pada repositori yang sama. Itu berarti kita tidak akan dapat membatasi penggabungan cabang dan mungkin sedikit berantakan untuk memiliki banyak cabang di repositori pusat.

Adakah saran dari tim yang mencoba kedua alur kerja?

Saya pikir ketakutan Anda akan forking berasal dari penggabungan bintang yang kurang dari SVN - karena bukan forking yang menyebabkan masalah - melainkan penggabungan.

Menyelam - Anda akan menemukan itu benar-benar hebat! Anda tidak perlu membayar terlalu banyak (jangan membayar untuk setiap perubahan di setiap file), tetapi Anda dapat membayar untuk fitur, dan bergabung kembali.

Pikirkan GitHub sebagai beberapa versi yang layak untuk perbaikan pada banyak konsep inti dalam pengendalian sumber.

Konsep cabang "stabil", dan garpu "pengembangan aktif" juga mencakup banyak masalah ini jika Anda ragu untuk melakukan forking. : P

Kami sudah mencoba keduanya, dengan pengembang yang sangat betah di svn. Dan jika Anda adalah sekelompok pengembang yang sudah bekerja bersama dan saling mempercayai dengan hak komitmen, Anda mungkin akan merasa lebih mudah untuk hanya menyimpan satu repo sentral di git dan menambahkan Anda semua sebagai kolaborator repo itu.

Kami masih sesekali melakukan garpu pribadi, tetapi itu biasanya untuk perubahan eksotis atau tes 1 orang yang biasanya tidak diminati, tetapi kami ingin menyimpannya dari jarak jauh.

Saya akan mulai dengan repo tunggal pusat dan hanya bekerja dengan git untuk sementara waktu. Mungkin garpu pribadi akan tumbuh pada Anda, mungkin tidak. Baik baik saja.

Dalam git, garpu sebenarnya hanyalah cabang lain. Dengan alur kerja fork untuk setiap pengembang, Anda secara efektif mengamanatkan bahwa setiap pengembang memiliki cabang (jarak jauh) publik untuk melacak perubahan perkembangan mereka. Ini bermanfaat karena dapat berkolaborasi secara langsung (peer-to-peer) antara pengembang. Anda harus menggabungkan setiap perubahan pengembang ke repo pusat dalam hal apa pun, jadi saya tidak berpikir ada banyak biaya tambahan yang ditambahkan oleh ini.

Untuk tim kecil yang terdiri dari 2-3 pengembang, boleh saja menggunakan percabangan pada repo untuk mengelola perbaikan dan fitur. Masalahnya adalah ketika Anda memiliki lebih banyak pengembang dari itu dan lebih banyak fitur dan perbaikan yang sedang dikembangkan.

Ketika itu terjadi, repo utama Anda di Github akan memiliki ratusan cabang; beberapa akan menjadi tua dan dilupakan dan tidak digoyahkan.

Anda juga akan memiliki masalah dengan kolaborasi di mana seseorang mendorong paksa pada cabang bersama yang ada di repo. Itu berarti tidak ada yang bisa berkolaborasi dengan baik pada cabang itu karena dorongan-kekuatan adalah penulisan ulang sejarah.

Forking a repo memudahkan untuk melacak cabang mana yang sedang dalam proses dan mana yang bagus. Itu membuat pembersih repo utama.

Namun, infrastruktur pengujian Anda mungkin mengandalkan penggunaan repo utama sehingga mungkin lebih sulit untuk menguji perubahan dalam repo bercabang Anda kecuali Anda mendorong cabang ke hulu. Mungkin sulit untuk mengetahui kapan percabangan dan forking adalah yang terbaik tetapi secara umum, ketika tim memiliki lebih dari 4 orang dan ada banyak perbaikan dan fitur, forking adalah pilihan terbaik.