Mengelola banyak orang yang mengerjakan proyek dengan GIT

32

Saya sangat baru di GIT / GitHub (seperti baru mulai kemarin). Saya ingin tahu apa cara terbaik untuk mengelola banyak orang yang bekerja pada proyek yang sama dengan Github. Saat ini saya sedang mengelola satu proyek dengan empat pengembang.

  1. Bagaimana cara saya tentang alur kerja dan memastikan semuanya sinkron?

    (Catatan: Semua pengembang akan memiliki satu akun universal.)

  2. Apakah setiap pengembang harus berada di cabang yang berbeda?

  3. Apakah saya dapat menangani 2 orang yang bekerja pada file yang sama?

Silakan kirim jawaban terperinci, saya bukan pembaca yang pemalu. Saya perlu memahami ini dengan baik.

git  github 
— badZoke
sumber
7
Satu akun untuk semua pengembang? Itu mungkin berhasil tetapi kemungkinan besar itu bukan ide yang baik.
— marstato
1
— Brad Thomas
Mungkin layak untuk melihat Pengembangan Berbasis GitFlow dan Trunk . Secara pribadi saya sudah sukses besar dengan yang terakhir
— J Lewis

Jawaban:

29

Jika semua pengembang memiliki akses komit ke repo, Anda tidak perlu melakukan sesuatu yang istimewa. Mereka akan menarik perubahan dari repo, membuat perubahan sendiri, melakukan secara lokal, dan kemudian mendorong kembali ke repo publik ketika mereka memiliki sesuatu yang berfungsi.

Jika di sisi lain Anda memiliki satu (atau beberapa) pengembang yang bertanggung jawab untuk melakukan repo, dan yang lain menyediakan tambalan untuk ini. Mintalah masing-masing dari mereka mengkloning repo ke dalam akun mereka sendiri dan minta mereka mengirim permintaan tarik ketika mereka memiliki perubahan yang mereka inginkan ke dalam repo utama.

Dimungkinkan juga untuk membuat klon khusus untuk mengerjakan fitur tertentu jika diinginkan. Menggunakan alur kerja yang sama dengan tarik-permintaan untuk mendapatkan perubahan ke repo utama ketika fitur selesai.

Jika dengan "Semua pengembang akan memiliki satu akun universal" Anda berarti bahwa semua pengembang akan berbagi satu akun GitHub dan muncul sebagai committer yang sama dalam repo, itu ide yang buruk. Buat akun terpisah dan setel sebagai kolaborator jika Anda ingin semuanya memiliki akses komit.

Adapun pertanyaan spesifik Anda:

  1. Tidak, gunakan cabang untuk fitur, perbaikan dll yang akan membutuhkan lebih dari satu komit. Lebih dari satu pengembang dapat bekerja di cabang yang sama.

  2. Ya, git menangani konflik dengan sangat baik, jadi tidak ada masalah ketika orang bekerja pada file yang sama. Tidak ada masalah kecuali, resolusi konflik tidak selalu sepele jika ada perubahan mendasar pada file yang telah diedit oleh lebih dari satu anggota. Namun ini tidak ada yang tidak bisa diatasi dengan berbicara bersama. Kontrol versi tidak menggantikan komunikasi.

Semoga berhasil!

— Harald
sumber
Beberapa poin yang Anda buat di sana benar-benar membuka mata, membuat saya berpikir ke arah yang berbeda bersama-sama, terima kasih!
— badZoke
Hapy jika itu dapat membantu Anda. Git dan DVCS memerlukan beberapa untuk membiasakan diri, tetapi mereka sangat fleksibel begitu Anda terbiasa dengannya.
— Harald
Terima kasih untuk ini. Saya punya satu pertanyaan spesifik. Jika ada beberapa pengembang yang bekerja di cabang yang sama. Setiap kali salah satu pengembang membuat perubahan dan mendorong ke cabang kerja, apakah sisa pengembang perlu melakukan perubahan (untuk memastikan mereka memiliki kode terbaru secara lokal untuk dikerjakan)?
— Eswar Rajesh Pinapala
Tidak, tidak setiap saat, hanya ketika Anda ingin melakukan sinkronisasi. Pertimbangkan salinan lokal cabang Anda sebagai cabang pribadi Anda, dan cabang hulu sebagai cabang yang ingin Anda gabungkan. Menggunakan sesuatu seperti git fetch upstreamdiikuti oleh git merge upstream/branchakan membuat Anda disinkronkan tanpa menulis ulang riwayat komit lokal Anda. Jika itu bukan masalah, cukup dengan git pull --rebasememindahkan perubahan Anda yang belum dicopot ke bagian atas cabang hulu.
— Harald
@badZoke .... apa yang Anda lakukan untuk menangani pertanyaan 3 (menangani 2 orang yang mengerjakan file yang sama) ...
— Moumit
25

Kami bekerja dengan 2 pengembang dan kami menggunakan alur kerja ini:

  • Di Github kami memiliki cabang master dan cabang dev
  • Cabang master sama dengan produksi atau berisi kode siap penyebaran
  • Cabang dev di depan master dan berisi semua kode baru yang sedang dikerjakan
  • Secara lokal kami berdua bekerja di cabang dev dan mendorong ke github ketika ada sesuatu yang siap
  • Dev lainnya mengambil perubahan baru dari cabang dev sebelum mendorong kode barunya
  • Ketika cabang dev bagus, kami bergabung dengan cabang master
  • Secara lokal kami memiliki beberapa cabang fitur cabang masalah dll.
— John
sumber
1
Bagus dan sederhana, terima kasih banyak! Saya akan mulai dengan ini, sebelum saya pindah ke hal-hal yang rumit;)
— badZoke
Bagaimana jika, ketika dev lain mengambil perubahan baru, sebelum mendorong kodenya, perubahan baru mengubah kode yang sudah dia ubah?
— wayofthefuture
+1, ini memang yang paling sederhana untuk memulai, dan berfungsi dengan sangat baik. Apa yang Anda gunakan disebut gitflow sederhana: marcgg.com/assets/blog/git-flow-before.jpg
— Jelle
5

Saya hanya melihat jawaban teks di sini, jadi saya pikir saya akan memposting gambar gitflow yang bagus untuk memulai. Gambar menggambarkan lebih dari seribu kata:

Gitflow Sederhana

  • Alur ini juga berfungsi baik dengan Penyebaran Berkelanjutan.
  • Cabang utama Anda berisi kode yang saat ini berjalan di server produksi Anda.
  • Cabang berkembang Anda berisi kode yang saat ini berjalan di server staging / pengujian.
— Jelle
sumber
+1, git flow, atau yang serupa mungkin jawaban yang tepat untuk pertanyaan ini.
— Maybe_Factor
0

Saya bekerja dengan 3 pengembang lain, dan kami berjuang dengan ini sedikit. Pengembang terkadang akan mendorong komit ke dalam produksi yang benar-benar belum siap untuk prime-time karena mereka akan menarik komit lain ke dalam perubahan mereka dan kemudian mendorong ke dalam produksi. Cabang versi tampaknya berfungsi baik untuk kita. Jadi, jika versi 1.0 adalah versi stabil saat ini, kami akan membuat cabang untuk pengembangan v1.1. Pengembang akan membuat perubahan di cabang ini. Server pengujian kami memeriksa cabang ini dan melakukan perubahan seperlunya. Ketika semua fitur untuk v1.1 siap digunakan dan pengujian selesai, kami akan menggabungkan v1.1 dengan master dan push. Dengan cabang, tim pengembang A dapat bekerja pada v1.1 dan tim pengembang B dapat bekerja v1.2. Kedua tim dapat bekerja tanpa saling mempengaruhi. Jika tim A mengembangkan sesuatu yang B dapat digunakan,

Kami juga menggunakan cabang perbaikan terbaru yang digunakan untuk perubahan langsung.

Berikut ini tautan ke gambar seperti apa ini. http://nvie.com/img/git-model@2x.png

— Greg
sumber
Itu tidak terdengar bagi saya seperti Anda benar-benar menerapkan aliran git seperti yang dimaksudkan - yaitu untuk membagi setiap fitur independen atau memperbaiki ke cabang sendiri, bukan hanya setiap rilis
— Brad Thomas
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.