Whats alur kerja dengan 2 orang di proyek


18

Saya datang kepada Anda sebagai programmer pemula yang telah mengerjakan proyeknya sendiri (yang mengalami kemajuan dengan baik). Rekan pendiri saya juga telah belajar bagaimana memprogram dan telah mencapai titik di mana ia mungkin dapat mulai memperbaiki beberapa hal dan membuat beberapa hal terjadi.

Dia mengajukan pertanyaan yang sangat bagus, yaitu "bagaimana cara kerjanya". Sesuatu yang saya hanya bisa berteori tentang karena saya tidak pernah diprogram dengan orang lain. Bisakah Anda memberi tahu saya tentang alur kerja terbaik. Kami menggunakan git.

Haruskah kita memiliki bagian spesifik dari sistem? Memeriksa kode? Ulasan kode?

Bagaimana Anda bekerja dengan> 1 dev?


1
Petunjuk terbaik saya adalah dengan melihat ini: nvie.com/posts/a-successful-git-branching-model Ini adalah salah satu (baik) cara untuk mengatur kode dalam tim, dan kami juga menggunakannya

apakah Anda menulis tes?
NARKOZ

... @ NARKOZ - belum. Kami agak melompat masuk. Sesuatu yang ingin saya lakukan, baru saja membeli sebuah buku.

2
@ Geoff Wright: Silakan masuk ke profil Anda dan terima (tekan tombol tanda centang di sebelah) beberapa jawaban yang diberikan orang dengan anggun untuk pertanyaan Anda: stackoverflow.com/users/661241/geoff-wright
iwasrobbed

1
Gunakan bitbucket.com untuk repositori pribadi
Klevis Miho

Jawaban:


23

Saya bekerja di sebuah tim yang menggunakan git, di mana 40+ pengembang bekerja pada beberapa repositori kode (100+) pada titik waktu tertentu. Kami juga memulai dengan sangat sedikit pengembang, mengembangkan ukuran tim dalam rentang beberapa tahun. Pada awalnya, meskipun dengan sedikit orang, Anda bisa lolos hanya dengan mengetahui minimum git. Seiring waktu Anda akan meningkatkan git fu Anda, menemukan fitur-fitur canggih.

  1. Anda akan membutuhkan tempat untuk menyimpan kode Anda. Pertimbangkan untuk menggunakan github atau gitorious . Keduanya bebas untuk digunakan, tetapi repositori Anda akan menjadi publik dan dapat dilihat oleh orang lain. Jika Anda ingin repositori pribadi, Anda dapat meng-hostnya di github secara gratis atau menginstal dan meng-host server gitorious Anda sendiri .
  2. Pada awalnya, lebih baik jangan khawatir tentang alur kerja tingkat lanjut yang melibatkan forking, tarik permintaan. Anda bisa mulai dengan menggunakan git secara terpusat (ngeri!). Perlakukan salinan yang diinangi sebagai salinan resmi kode sumber Anda. Mari kita panggil repositori ini upstream.
  3. Salah satu dari Anda mengkomit semua kode ke repositori git lokal dan mendorongnya ke upstreamrepositori ini .
  4. Anggota tim lain dapat mengkloning repositori ini.
  5. Satu set perintah minimal Anda harus belajar adalah clone, pull, push, add, commit, log, status, diff, branch, stash, apply, reset, format-patch, branch. Pelajari lebih lanjut tentang mereka dari gittutorial .
  6. Anda sekarang dapat mengerjakan bagian mana pun dari kode. Jangan khawatir apa yang terjadi ketika Anda berdua mengedit file yang sama. Git sangat pandai menangani penggabungan dan memperbaiki konflik.
  7. Buat komit atom kecil dan tulis pesan log yang baik . Gunakan present tense untuk log komit. Anda dapat membuat sejumlah komit sesuai keinginan ke salinan lokal Anda karena tidak memengaruhi pekerjaan orang lain.
  8. Ketika Anda berpikir kode Anda siap untuk dibagikan kepada orang lain, publikasikan ke upstreamrepositori. Latihan yang baik adalah selalu menarik sebelum Anda mendorong . Dengan cara ini Anda menjaga repositori Anda tetap sinkron dengan perubahan orang lain.
  9. Ulangi langkah 7dan 8.

Setelah Anda merasa nyaman dengan alur kerja ini, Anda dapat maju ke hal-hal yang lebih maju seperti - cabang topikal, forking, tarik permintaan, penggabungan, komitmen interaktif rebasing dll.

Jika Anda benar-benar ingin ulasan kode, itu bisa dilakukan dengan git dan email saja. Ketika ukuran tim Anda melebihi 10+, ini idealnya dilakukan lebih baik dengan beberapa jenis alat online. Jadi dalam praktiknya ada banyak cara untuk melakukan ini, dan ini hanya satu cara sederhana:

  1. Buat satu set komitmen untuk ditinjau git format-patch. Ini akan menghasilkan satu set file tambalan. Email tambalan ini ke reviewer.
  2. Peninjau dapat menerapkan tambalan dengan git apply. Ini berlaku tambalan tetapi tidak membuat komit.
  3. Tinjau kode dan email kembali dengan saran.
  4. Ulangi 1-2-3 sampai memuaskan.
  5. Peninjau mengkonfirmasi bahwa tambalan dapat didorong upstream.

Saya juga ingin menambahkan git rebase ke daftar ini.
alock27

1
Saya tidak setuju itu stash, apply, format-patchadalah bagian dari pengetahuan minimum. Saya biasanya menunggu beberapa bulan sebelum mengajarkan hal-hal itu. Saya kira> 50% dari dev tidak simpanan.
Michael Durrant

1
Panggil upstream origindan itu akan membantu membuat contoh lain (yang biasanya digunakan origin) lebih mudah diikuti.
Michael Durrant

2

Saya menggunakan github dan semua fungsinya untuk ini. lihat di http://www.github.com/ Jadi Anda dapat menggunakan cabang, garpu, masalah, tarik permintaan untuk bekerja dengan pasangan Anda.


0

Hal pertama yang akan saya lakukan adalah melihat ke dalam repositori kode pusat sehingga perubahan dapat digabungkan dan disimpan dalam sinkronisasi antara dua proyek Anda. SVN adalah yang mudah dan mudah yang telah saya gunakan di masa lalu dan sudah ada cukup lama sehingga SVN cukup matang .

Setelah itu saya akan mengidentifikasi di antara kalian berdua peran yang akan kalian mainkan yaitu

  1. Apakah Anda akan menulis fungsionalitas kode dalam tandom atau satu orang akan melakukan perbaikan bug sementara yang lain melanjutkan dengan fitur.
  2. Apakah Anda ingin membuat satu set standar pengkodean dasar yaitu posisi penjepit, penamaan variabel anggota pribadi, variabel dan konvensi penamaan metode (CamelCase dll)
  3. Seberapa sering Anda perlu check-in. Saya sarankan setidaknya sekali sehari untuk memastikan Anda berdua melihat apa yang dilakukan pihak lain terutama sejak dini. Meskipun selalu memastikan sebelum checkin kode dapat dibangun.
  4. Dia bos, tetapi apakah Anda akan menjadi pemimpin pemrograman?

Semoga berhasil!


1
SVN adalah pilihan yang layak (dan saat ini saya menggunakannya di tempat kerja) ... tapi Git dan Hg saya temukan sedikit lebih baik karena saya dapat melakukan secara lokal (dan kembali ketika saya melakukan sesuatu yang bodoh) tanpa memaksa orang lain untuk berurusan (jika mereka memperbarui) dengan kode saya yang mungkin tidak berfungsi. Jujur saya mulai menggunakan Git di kantor karena alasan ini, tetapi saya masih bisa mempublikasikan perubahan saya kembali ke SVN menggunakan git-svn
Ken Henderson
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.