Kontrol Sumber Berbasis Git di Perusahaan: Alat dan Praktik yang Disarankan?

Saya menggunakan git untuk proyek pribadi dan menurut saya itu hebat. Cepat, fleksibel, kuat, dan berfungsi dengan baik untuk pengembangan jarak jauh.

Tapi sekarang ini diamanatkan di tempat kerja dan, terus terang, kami mengalami masalah.

Di luar kotak, git tampaknya tidak berfungsi dengan baik untuk pengembangan terpusat dalam organisasi besar (20+ pengembang) dengan pengembang dengan berbagai kemampuan dan tingkat kecanggihan git - terutama dibandingkan dengan sistem kontrol sumber lain seperti Perforce atau Subversion, yang ditujukan pada lingkungan seperti itu. (Ya, saya tahu, Linus tidak pernah bermaksud demikian.)

Tetapi - karena alasan politik - kami terjebak dengan git, meskipun itu menyebalkan untuk apa yang kami coba lakukan dengannya.

Berikut beberapa hal yang kami lihat:

• Alat GUI belum matang
• Dengan menggunakan alat baris perintah, jauh lebih mudah untuk mengacaukan penggabungan dan menghapus perubahan orang lain
• Itu tidak menawarkan izin repositori per pengguna di luar hak akses baca-saja atau baca-tulis global
• Jika Anda memiliki izin ke bagian APA PUN dari repositori, Anda dapat melakukan hal yang sama ke SETIAP bagian dari repositori, jadi Anda tidak dapat melakukan sesuatu seperti membuat cabang pelacakan grup kecil di server pusat yang tidak dapat dilakukan orang lain. berurusan dengan.
• Alur kerja selain "apa saja" atau "diktator yang baik hati" sulit untuk didorong, apalagi ditegakkan
• Tidak jelas apakah lebih baik menggunakan satu repositori besar (yang memungkinkan semua orang mengacaukan semuanya) atau banyak repositori per komponen (yang membuat pusing kepala saat mencoba menyinkronkan versi).
• Dengan banyak repositori, juga tidak jelas bagaimana mereplikasi semua sumber yang dimiliki orang lain dengan menarik dari repositori pusat, atau melakukan sesuatu seperti mendapatkan semuanya pada pukul 4:30 sore kemarin.

Namun, saya pernah mendengar bahwa orang berhasil menggunakan git di organisasi pengembangan besar.

Jika Anda berada dalam situasi itu - atau jika Anda umumnya memiliki alat, tip dan trik untuk membuatnya lebih mudah dan lebih produktif untuk menggunakan git di organisasi besar di mana beberapa orang bukan penggemar baris perintah - saya ingin mendengar apa yang Anda miliki menyarankan.

BTW, saya sudah menanyakan versi pertanyaan ini di LinkedIn, dan tidak mendapat jawaban nyata tetapi banyak "astaga, saya juga ingin mengetahuinya!"

UPDATE: Izinkan saya mengklarifikasi ...

Di tempat saya bekerja, kami tidak dapat menggunakan APA PUN selain git . Itu bukan pilihan. Kami terjebak dengan itu. Kami tidak dapat menggunakan mercurial, svn, bitkeeper, Visual Source Safe, ClearCase, PVCS, SCCS, RCS, bazaar, Darcs, monotone, Perforce, Fossil, AccuRev, CVS, atau bahkan Proyektor lama milik Apple yang saya gunakan pada tahun 1987. Jadi meskipun Anda dipersilakan untuk mendiskusikan opsi lain, Anda tidak akan mendapatkan hadiahnya jika Anda tidak mendiskusikan git.

Selain itu, saya sedang mencari tip praktis tentang cara menggunakan git di perusahaan . Saya meletakkan seluruh daftar masalah yang kami alami di bagian atas pertanyaan ini. Sekali lagi, orang dipersilakan untuk membahas teori, tetapi jika Anda ingin mendapatkan hadiah, beri saya solusi.

Berlawanan dengan pendapat umum, menurut saya menggunakan DVCS adalah pilihan ideal dalam lingkungan perusahaan karena memungkinkan alur kerja yang sangat fleksibel. Saya akan berbicara tentang penggunaan DVCS vs. CVCS terlebih dahulu, praktik terbaik dan kemudian tentang git secara khusus.

DVCS vs. CVCS dalam konteks perusahaan:

Saya tidak akan berbicara tentang pro / kontra umum di sini, melainkan fokus pada konteks Anda. Ini adalah konsep umum, bahwa menggunakan DVCS membutuhkan tim yang lebih disiplin daripada menggunakan sistem terpusat. Ini karena sistem terpusat memberi Anda cara mudah untuk menegakkan alur kerja Anda, menggunakan sistem terdesentralisasi membutuhkan lebih banyak komunikasi dan disiplin untuk tetap berpegang pada konvensi yang ditetapkan. Meskipun ini mungkin tampak seperti menimbulkan overhead, saya melihat manfaat dalam peningkatan komunikasi yang diperlukan untuk membuatnya menjadi proses yang baik. Tim Anda perlu berkomunikasi tentang kode, tentang perubahan, dan tentang status proyek secara umum.

Dimensi lain dalam konteks disiplin mendorong percabangan dan eksperimen. Berikut adalah kutipan dari entri terbaru Martin Fowler bliki tentang Alat Kontrol Versi , dia telah menemukan deskripsi yang sangat ringkas untuk fenomena ini.

DVCS mendorong percabangan cepat untuk eksperimen. Anda dapat membuat cabang di Subversion, tetapi fakta bahwa mereka terlihat oleh semua membuat orang enggan membuka cabang untuk pekerjaan eksperimental. Demikian pula, DVCS mendorong check-pointing pekerjaan: melakukan perubahan yang tidak lengkap, yang bahkan mungkin tidak mengkompilasi atau lulus tes, ke repositori lokal Anda. Sekali lagi Anda dapat melakukan ini di cabang pengembang di Subversion, tetapi fakta bahwa cabang tersebut berada di ruang bersama membuat orang cenderung untuk melakukannya.

DVCS memungkinkan alur kerja yang fleksibel karena menyediakan pelacakan perubahan melalui pengenal unik global dalam grafik asiklik terarah (DAG) alih-alih perbedaan tekstual sederhana. Hal ini memungkinkan mereka untuk secara transparan melacak asal dan sejarah kumpulan perubahan, yang bisa jadi sangat penting.

Alur kerja:

Larry Osterman (pengembang Microsoft yang bekerja di tim Windows) memiliki entri blog yang bagus tentang alur kerja yang mereka terapkan di tim Windows. Terutama mereka memiliki:

• Batang hanya kode yang bersih dan berkualitas tinggi (master repo)
• Semua pengembangan terjadi di cabang fitur
• Tim fitur memiliki repositori tim
• Mereka secara teratur menggabungkan perubahan trunk terbaru ke dalam cabang fitur mereka ( Teruskan Integrasi )
• Fitur lengkap harus melewati beberapa gerbang kualitas misalnya review, cakupan tes, Q&A (repo sendiri)
• Jika sebuah fitur dilengkapi dan memiliki kualitas yang dapat diterima, fitur itu digabungkan ke dalam trunk ( Reverse Integrate )

Seperti yang Anda lihat, dengan setiap repositori ini hidup sendiri, Anda dapat memisahkan tim yang berbeda yang maju dengan kecepatan yang berbeda. Juga kemungkinan untuk menerapkan sistem gerbang kualitas yang fleksibel membedakan DVCS dari CVCS. Anda juga dapat menyelesaikan masalah izin Anda di level ini. Hanya segelintir orang yang diperbolehkan mengakses master repo. Untuk setiap level hierachy, miliki repo terpisah dengan kebijakan akses yang sesuai. Memang, pendekatan ini bisa sangat fleksibel di tingkat tim. Anda harus menyerahkan kepada masing-masing tim untuk memutuskan apakah mereka ingin membagikan repo tim mereka di antara mereka sendiri atau apakah mereka menginginkan pendekatan yang lebih hierakis di mana hanya pemimpin tim yang dapat berkomitmen untuk repo tim.

(Gambar itu dicuri dari hginit.com Joel Spolsky .)

Satu hal yang masih harus mengatakan pada saat ini meskipun: - meskipun DVCS menyediakan kemampuan penggabungan besar, ini adalah tidak pernah pengganti menggunakan Continuous Integration. Bahkan pada saat itu Anda memiliki banyak fleksibilitas: CI untuk repo trunk, CI untuk repo tim, repo Q&A, dll.

Git dalam konteks perusahaan:

Git mungkin bukan solusi ideal untuk konteks perusahaan seperti yang telah Anda tunjukkan. Mengulangi beberapa kekhawatiran Anda, saya pikir yang paling penting adalah:

• Masih dukungan yang agak belum matang di Windows (tolong perbaiki saya jika itu berubah baru-baru ini) Sekarang windows memiliki klien windows github , tortoisegit , SourceTree dari atlassian
• Kurangnya alat GUI yang matang, tidak ada integrasi alat vdiff / penggabungan warga kelas satu
• Antarmuka yang tidak konsisten dengan tingkat abstraksi yang sangat rendah di atas cara kerja dalamnya
• Kurva pembelajaran yang sangat curam bagi pengguna svn
• Git sangat kuat dan memudahkan untuk mengubah riwayat, sangat berbahaya jika Anda tidak tahu apa yang Anda lakukan (dan terkadang Anda akan tahu meskipun Anda mengira sudah mengetahuinya)
• Tidak ada opsi dukungan komersial yang tersedia

Saya tidak ingin memulai git vs. hg flamewar di sini, Anda telah melakukan langkah yang benar dengan beralih ke DVCS. Mercurial membahas beberapa poin di atas dan saya pikir itu lebih cocok dalam konteks perusahaan:

• Semua bentuk plat yang menjalankan python didukung
• Alat GUI yang hebat di semua bentuk perangkat utama (win / linux / OS X), integrasi alat penggabungan / vdiff kelas satu
• Antarmuka yang sangat konsisten, transisi yang mudah bagi pengguna svn
• Dapat melakukan sebagian besar hal yang dapat dilakukan git juga, tetapi menyediakan abstraksi yang lebih bersih. Operasi berbahaya selalu eksplisit. Fitur lanjutan disediakan melalui ekstensi yang harus diaktifkan secara eksplisit.
• Dukungan komersial tersedia dari selenic.

Singkatnya, saat menggunakan DVCS di perusahaan, menurut saya, penting untuk memilih alat yang paling sedikit menimbulkan gesekan. Agar transisi berhasil, sangat penting untuk mempertimbangkan keterampilan yang berbeda-beda di antara pengembang (dalam hal VCS).

Mengurangi gesekan:

Oke, karena Anda tampaknya benar-benar terjebak dengan situasi tersebut, ada dua opsi tersisa IMHO. Tidak ada alat untuk membuat git lebih mudah; git itu rumit. Entah Anda menghadapi ini atau mengatasi git: -

1. Dapatkan kursus pengantar git untuk seluruh tim. Ini harus mencakup hanya dasar-dasar dan beberapa latihan (penting!).
2. Ubah master repo menjadi svn dan biarkan "young-stars" git-svn . Hal ini memberi sebagian besar pengembang antarmuka yang mudah digunakan dan dapat mengimbangi kurangnya disiplin dalam tim Anda, sementara bintang muda dapat terus menggunakan git untuk repositori mereka sendiri.

Sejujurnya, saya pikir Anda benar-benar memiliki masalah orang daripada masalah alat. Apa yang dapat dilakukan untuk memperbaiki situasi ini?

• Anda harus menjelaskan bahwa menurut Anda proses Anda saat ini akan berakhir dengan basis kode yang dapat dipelihara.
• Investasikan waktu untuk Integrasi Berkelanjutan. Seperti yang saya jelaskan di atas, apa pun jenis VCS yang Anda gunakan, tidak pernah ada pengganti untuk CI. Anda menyatakan bahwa ada orang yang memasukkan omong kosong ke dalam repo master: Minta mereka memperbaiki omong kosong mereka sementara peringatan merah berbunyi dan menyalahkan mereka karena melanggar build (atau tidak memenuhi metrik kualitas atau apa pun).

Saya insinyur SCM untuk organisasi pengembangan yang cukup besar, dan kami beralih ke git dari svn selama kurang lebih setahun terakhir. Kami menggunakannya secara terpusat.

Kami menggunakan gitosis untuk menghosting repositori. Kami memecah repositori svn monolitik kami menjadi banyak repositori git yang lebih kecil karena unit percabangan git pada dasarnya adalah repositori. (Ada beberapa cara untuk mengatasinya, tapi itu aneh.) Jika Anda menginginkan jenis kontrol akses per cabang, gitolite mungkin merupakan pendekatan yang lebih baik. Ada juga versi GitHub di dalam firewall jika Anda ingin menghabiskan uang. Untuk tujuan kami, gitosis baik-baik saja karena kami memiliki izin yang cukup terbuka di repositori kami. (Kami memiliki sekelompok orang yang memiliki akses tulis ke grup repositori, dan setiap orang memiliki akses baca ke semua repositori.) Kami menggunakan gitweb untuk antarmuka web.

Adapun beberapa kekhawatiran khusus Anda:

• penggabungan: Anda dapat menggunakan alat penggabung visual pilihan Anda; ada petunjuk di berbagai tempat tentang cara menyiapkannya. Fakta bahwa Anda dapat melakukan penggabungan dan memeriksa validitasnya secara total di repo lokal Anda, menurut pendapat saya, merupakan nilai tambah utama untuk git; Anda dapat memverifikasi penggabungan sebelum Anda mendorong apa pun.
• GUI: Kami memiliki beberapa orang yang menggunakan TortoiseGit tetapi saya tidak terlalu merekomendasikannya; tampaknya berinteraksi dengan cara yang aneh dengan baris perintah. Saya harus setuju bahwa ini adalah bidang yang perlu diperbaiki. (Karena itu, saya bukan penggemar GUI untuk kontrol versi secara umum.)
• cabang pelacakan kelompok kecil: Jika Anda menggunakan sesuatu yang menyediakan ACL yang lebih baik seperti gitolite, cukup mudah untuk melakukannya, tetapi Anda juga dapat membuat cabang bersama dengan menghubungkan berbagai repositori lokal pengembang - repo git dapat memiliki banyak remote.

Kami beralih ke git karena kami memiliki banyak pengembang jarak jauh, dan karena kami memiliki banyak masalah dengan Subversion. Kami masih bereksperimen dengan alur kerja, tetapi saat ini kami pada dasarnya menggunakannya dengan cara yang sama seperti dulu kami menggunakan Subversion. Hal lain yang kami sukai adalah ia membuka alur kerja lain yang memungkinkan, seperti penggunaan repositori pementasan untuk peninjauan kode dan berbagi kode di antara grup kecil. Ini juga mendorong banyak orang untuk mulai melacak skrip pribadi mereka dan sebagainya karena sangat mudah membuat repositori.

Ya, saya tahu, Linus tidak pernah bermaksud demikian.

Sebenarnya, Linus berpendapat bahwa sistem terpusat tidak bisa berfungsi.

Dan, apa yang salah dengan alur kerja diktator-dan-letnan?

Ingat, git adalah sistem terdistribusi ; jangan mencoba menggunakannya seperti yang terpusat.

(diperbarui)

Sebagian besar masalah Anda akan hilang jika Anda tidak mencoba menggunakan git seolah-olah itu adalah "svn on steroid" (karena tidak).

Alih-alih menggunakan repositori kosong sebagai server pusat di mana setiap orang dapat mendorong (dan berpotensi mengacaukan), siapkan beberapa manajer integrasi yang menangani penggabungan, sehingga hanya mereka yang dapat mendorong ke repositori kosong.

Biasanya orang-orang ini harus menjadi pemimpin tim: setiap pemimpin mengintegrasikan pekerjaan timnya sendiri dan mendorongnya ke gudang yang diberkati.

Bahkan lebih baik, orang lain (yaitu diktator) menarik dari pemimpin tim dan mengintegrasikan perubahan mereka ke dalam gudang yang diberkati.

Tidak ada yang salah dengan alur kerja itu, tetapi kami adalah startup yang terlalu banyak bekerja dan membutuhkan alat kami untuk menggantikan waktu dan perhatian manusia; tidak ada yang memiliki bandwidth untuk melakukan review kode, apalagi menjadi diktator yang baik hati.

Jika integrator tidak punya waktu untuk meninjau kode, tidak masalah, tetapi Anda masih perlu memiliki orang yang mengintegrasikan gabungan dari semua orang.

Melakukan git pull tidak membutuhkan banyak waktu.

git pull A
git pull B
git pull C

git memang menggantikan waktu dan perhatian manusia; itulah mengapa itu ditulis di tempat pertama.

• Alat GUI belum matang

Alat gui dapat menangani hal-hal dasar dengan cukup baik.

Operasi lanjutan memerlukan pola pikir pembuat kode / kutu buku (misalnya, saya merasa nyaman bekerja dari baris perintah). Butuh sedikit waktu untuk memahami konsepnya, tetapi tidak terlalu sulit.

• Dengan menggunakan alat baris perintah, jauh lebih mudah untuk mengacaukan penggabungan dan menghapus perubahan orang lain

Ini tidak akan menjadi masalah kecuali Anda memiliki banyak pengembang tidak kompeten dengan akses tulis penuh ke "repositori pusat".

Tetapi, jika Anda mengatur alur kerja Anda sehingga hanya beberapa orang (integrator) yang menulis ke repositori "diberkati", itu tidak akan menjadi masalah.

Git tidak membuatnya mudah untuk mengacaukan penggabungan.

Ketika ada konflik penggabungan, git akan menandai dengan jelas baris yang berkonflik sehingga Anda tahu perubahan mana yang menjadi milik Anda dan mana yang bukan.

Ini juga mudah untuk menghapus kode orang lain dengan svn atau alat (non-dsitributed) lainnya. Faktanya, ini jauh lebih mudah dengan alat-alat lain ini karena Anda cenderung untuk "menunggu perubahan" untuk waktu yang lama dan pada titik tertentu penggabungan bisa menjadi sangat sulit.

Dan karena alat ini tidak tahu cara menggabungkan, Anda akhirnya harus selalu menggabungkan semuanya secara manual. Misalnya, segera setelah seseorang membuat komit ke file yang Anda edit secara lokal, itu akan ditandai sebagai konflik yang perlu diselesaikan secara manual; sekarang itu adalah mimpi buruk pemeliharaan.

Dengan git, seringkali tidak akan ada konflik penggabungan karena git sebenarnya bisa digabungkan. Jika konflik benar-benar terjadi, git akan menandai baris tersebut dengan jelas untuk Anda sehingga Anda tahu persis perubahan mana yang menjadi milik Anda dan perubahan mana yang berasal dari orang lain.

Jika seseorang melenyapkan perubahan orang lain saat menyelesaikan konflik gabungan, itu tidak akan terjadi secara keliru: itu baik karena itu diperlukan untuk resolusi konflik, atau karena mereka tidak tahu apa yang mereka lakukan.

• Itu tidak menawarkan izin repositori per pengguna di luar hak akses baca-saja atau baca-tulis global

• Jika Anda memiliki izin ke bagian APA PUN dari repositori, Anda dapat melakukan hal yang sama ke SETIAP bagian dari repositori, jadi Anda tidak dapat melakukan sesuatu seperti membuat cabang pelacakan grup kecil di server pusat yang tidak dapat dilakukan orang lain. berurusan dengan.

• Alur kerja selain "apa saja" atau "diktator yang baik hati" sulit untuk didorong, apalagi ditegakkan

Masalah ini akan hilang jika Anda berhenti mencoba menggunakan git seolah-olah itu adalah sistem terpusat.

• Tidak jelas apakah lebih baik menggunakan satu repositori besar (yang memungkinkan semua orang mengacaukan semuanya) atau banyak repositori per komponen (yang membuat pusing kepala saat mencoba menyinkronkan versi).

Panggilan penghakiman.

Jenis proyek apa yang Anda miliki?

Sebagai contoh: apakah versi xy dari proyek A bergantung pada persis versi wz dari proyek B sedemikian rupa sehingga setiap kali Anda memeriksa xy dari proyek A Anda juga harus membayar wz proyek B, jika tidak maka tidak akan membangun? Jika demikian, saya akan menempatkan proyek A dan proyek B dalam repositori yang sama, karena keduanya jelas merupakan dua bagian dari satu proyek.

Praktik terbaik di sini adalah menggunakan otak Anda

• Dengan banyak repositori, juga tidak jelas bagaimana mereplikasi semua sumber yang dimiliki orang lain dengan menarik dari repositori pusat, atau melakukan sesuatu seperti mendapatkan semuanya pada pukul 4:30 sore kemarin.

Saya tidak yakin apa yang Anda maksud.

Saya sangat merekomendasikan http://code.google.com/p/gerrit/ untuk pekerjaan perusahaan. Ini memberi Anda kontrol akses plus alur kerja berbasis tinjauan bawaan. Ini mengotentikasi terhadap sistem LDAP apa pun. Anda dapat menghubungkannya ke Hudson dengan http://wiki.hudson-ci.org/display/HUDSON/Gerrit+Plugin , memungkinkan Anda membuat dan menguji perubahan saat masih dalam peninjauan; ini adalah pengaturan yang sangat mengesankan.

Jika Anda memutuskan untuk menggunakan gerrit, saya sarankan untuk mencoba menyimpan riwayat yang cukup linier, bukan riwayat bercabang seperti yang disukai beberapa orang open source. Gerrit mengatakan ini sebagai "izinkan perubahan maju cepat saja". Kemudian Anda dapat menggunakan percabangan dan penggabungan lebih banyak seperti yang biasa Anda lakukan, untuk rilis dan lainnya.

Saya menjawab pertanyaan ini berdasarkan pengalaman saya sebagai manajer pengembang di sebuah perusahaan telekomunikasi besar, tempat kami mengadopsi Git pada tahun 2010

Anda memiliki serangkaian masalah yang sangat berbeda di sini:

• alur kerja
• alat klien
• kontrol dan integrasi akses server

Alur kerja

Kami berhasil mengadopsi mode repositori pusat: apa yang kami miliki dalam proyek perusahaan kami (portal besar untuk 5 juta basis pengguna) adalah repositori pusat de-facto yang menghasilkan build resmi kemudian diambil melalui proses pengiriman (yang, dalam kasus, terdiri dari tiga tingkat pengujian dan dua penerapan). Setiap pengembang mengelola reponya sendiri, dan kami bekerja berdasarkan cabang-per-fitur.

Alat klien

Sekarang ada beberapa pilihan yang tersedia, sekarang area ini sangat ramai. Banyak developer yang berhasil menggunakan IntelliJ Idea dan Eclipse dengan plugin Git , tanpa hal lain. Juga sebagian besar pengembang Linux menggunakan klien git CLI, tanpa masalah. Beberapa pengembang Mac berhasil menggunakan Tower Git . Harap dicatat bahwa tidak ada dari klien ini yang dapat mencegah pengguna untuk "mengacaukan" dengan repositori pusat: diperlukan mekanisme kontrol sisi server

Kontrol dan integrasi akses server

Jika Anda ingin menghindari pengembang "mengacaukan" repositori Git Anda, Anda benar-benar perlu memilih solusi yang:

• memperlihatkan antarmuka admin web yang layak untuk melakukan setiap operasi
• memungkinkan Anda untuk menerapkan identitas pengguna (menggunakan repositori Git "telanjang" sangat mudah dilakukan atas nama orang lain)
• memberi Anda keamanan yang sangat baik (sehingga misalnya Anda dapat mencegah FORCE-PUSH dan mengatur beberapa cabang agar hanya dibaca untuk beberapa pengembang / grup)
• terintegrasi dengan sistem otentikasi perusahaan Anda (yaitu LDAP, Windows ActiveDirectory)
• memberi Anda audit penuh (kepatuhan SOX terkadang sangat penting untuk perusahaan besar)

Tidak banyak solusi sisi server siap pakai yang dapat membantu ini, saya sarankan Anda memeriksa salah satunya:

• Gitorious : ini dapat memberikan keamanan tingkat akses dasar, tetapi tidak memiliki kontrol izin yang sangat baik, jadi Anda mungkin harus melakukan beberapa pengkodean untuk menangani skenario seperti izin tingkat cabang. Ini juga tidak memiliki integrasi dengan mekanisme otentikasi perusahaan yang ada
• GitHub Enterprise: baru-baru ini diterbitkan oleh GitHub, ini menampilkan GitHub di perusahaan Anda. Ini tidak memiliki kepatuhan SOX dan keamanan yang sangat baik
• Gerrit : dapat memberikan keamanan tingkat akses graind halus dan integrasi dengan sistem otentikasi perusahaan tetapi tidak memiliki kepatuhan SOX dan SSO. Juga beberapa operasi hanya dapat dilakukan melalui SSH melalui CLI
• GitEnterprise : memberikan izin tingkat cabang, SSO, kepatuhan SOX, administrasi berbasis web lengkap. Baru-baru ini juga terintegrasi dengan Gerrit, sehingga itu juga memberi Anda contoh Gerrit penuh

Semoga ini membantu!

Sepertinya masalah Anda adalah Anda belum memutuskan atau menerapkan alur kerja. Git cukup fleksibel untuk digunakan seperti svn atau VCS lainnya, tetapi sangat kuat sehingga jika Anda tidak menetapkan aturan yang harus diikuti semua orang maka Anda akan berakhir dengan kekacauan. Saya akan merekomendasikan alur kerja diktator-letnan yang disebutkan seseorang di atas, tetapi dikombinasikan dengan model percabangan yang dijelaskan oleh Vincent Driessen . Untuk info lebih lanjut lihat screencast ini oleh David Bock , dan yang ini oleh Mark Derricutt .

Pada perangkatnya , pengguna MacOS-X menganggap GitX (http://gitx.frim.nl/) sangat sederhana dan efektif. Kekurangannya adalah tidak mendukung hook Klien Git (yang di bawah $ GIT_ROOT / .git / hooks).

Secara keseluruhan, saya sangat memilih alat yang mendukung kontrol akses terperinci di: - cabang (untuk memisahkan cabang rilis stabil dengan keamanan ketat dari cabang topik yang membutuhkan lebih banyak kelincahan dan fleksibilitas) - penegakan identitas (penulis / pelaku ). Ini adalah KUNCI untuk SOX - pembatasan perintah git - audit-trail. Ini adalah KUNCI untuk SOX

Yang berhasil saya gunakan dengan fitur tersebut adalah:

1. Tinjauan Kode Gerrit (http://code.google.com/p/gerrit/)
2. GitEnterprise (http://gitenterprise.com)
3. CollabNet TeamForge (http://www.collab.net/gotgit), menggunakan Gerrit 2.1.8 di belakang layar

PS Jangan meremehkan kepatuhan SOX dan CMMI : sering kali terdapat serangkaian pilihan terbatas yang Anda miliki yang ditentukan oleh Kebijakan Perusahaan Perusahaan tentang Keamanan.

Semoga ini membantu.

Luca.

Kami baru saja beralih dari svn ke git. Karena git-daemon tidak berfungsi dengan msysgit, kami memilih pendekatan repositori sentral pada server Linux dengan gitosis.

Untuk menghilangkan kemungkinan mengacaukan master, kami cukup menghapusnya. Sebagai gantinya, kami menyiapkan semua rilis dengan menggabungkan cabang yang dipilih untuk pengujian dan menandai penggabungan. Jika lolos tes, komit diberi tag dengan versi dan dimasukkan ke dalam produksi.

Untuk menangani ini, kami memiliki peran bergilir sebagai manajer rilis. Manajer rilis bertanggung jawab untuk meninjau setiap cabang sebelum siap untuk diuji. Kemudian ketika pemilik produk memutuskan sudah waktunya untuk menggabungkan cabang yang disetujui bersama-sama untuk rilis tes baru, manajer rilis melakukan penggabungan.

Kami juga memiliki peran bergilir dari meja bantuan tingkat 2 dan setidaknya bagi kami beban kerjanya sedemikian rupa sehingga memungkinkan untuk memiliki kedua peran tersebut pada saat yang bersamaan.

Sebagai keuntungan dari tidak adanya master, tidak mungkin menambahkan kode apa pun ke proyek tanpa melalui manajer rilis, jadi kami menemukan secara langsung berapa banyak kode yang ditambahkan secara diam-diam ke proyek sebelumnya.

Proses tinjauan dimulai dengan pemilik cabang mengirimkan diff ke papan tinjauan dan memasang post-it hijau di papan tulis dengan nama cabang (kami memiliki alur kerja berbasis Kanban) di bawah "untuk ditinjau", atau jika itu bagian dari pengguna yang sudah selesai cerita, pindahkan seluruh kartu cerita ke "untuk ditinjau" dan letakkan postingan di atasnya. Manajer relase adalah orang yang memindahkan kartu dan memasukkannya ke "siap untuk diuji" dan kemudian pemilik produk dapat memilih mana yang akan disertakan dalam rilis tes berikutnya.

Saat melakukan penggabungan, manajer rilis juga memastikan bahwa komit gabungan memiliki pesan komit yang masuk akal yang dapat digunakan di log perubahan untuk pemilik produk.

Ketika rilis telah dimasukkan ke dalam produksi, tag digunakan sebagai basis baru untuk cabang dan semua cabang yang ada digabungkan dengannya. Dengan cara ini semua cabang memiliki induk yang sama yang membuatnya lebih mudah untuk menangani penggabungan.

Saya akan menambahkan postingan "apakah Anda sudah mempertimbangkannya" juga.

Salah satu hal hebat tentang Bazaar adalah fleksibilitasnya. Di sinilah ia mengalahkan semua sistem terdistribusi lainnya. Anda dapat mengoperasikan Bazaar dalam mode terpusat, mode terdistribusi, atau mendapatkan ini: keduanya (artinya pengembang dapat memilih model mana yang mereka sukai atau mana yang paling sesuai untuk grup kerja mereka). Anda juga dapat memutuskan repositori terpusat saat Anda dalam perjalanan dan menghubungkannya kembali saat Anda kembali.

Selain itu, dokumentasi yang sangat baik dan sesuatu yang akan membuat perusahaan Anda senang: dukungan komersial tersedia.

• Instal antarmuka web yang layak, seperti Github FI
• Tetap berpegang pada model yang relatif terpusat (awalnya) untuk membuat orang tetap nyaman.
• Jalankan build Continuous Integration untuk setiap cabang bersama.
• Bagikan serangkaian opsi konfigurasi git global yang bagus.
• Integrasikan git ke shell Anda, dengan penyelesaian bash, dan prompt dengan cabang saat ini.
• Coba Integrasi Git IntelliJ sebagai alat penggabung.
• Pastikan Anda .gitignore sebagaimana mestinya.

Mengenai poin 3 & 4 (per pengguna, per-bagian, izin per-cabang), lihat gitolite (tercakup dalam buku Pro Git: http://progit.org/book/ch4-8.html ).

Politik atau tidak, Git adalah pilihan DCVS yang bagus. Seperti alat canggih lainnya, ada baiknya meluangkan sedikit waktu di depan untuk memahami bagaimana alat tersebut dirancang untuk bekerja, dan, untuk tujuan ini, saya sangat merekomendasikan buku Pro Git. Beberapa jam yang dihabiskan dengannya akan menghemat banyak frustrasi dalam jangka panjang.

GUI: Saat ini, TortoiseGit v1.7.6 seharusnya baik-baik saja untuk sebagian besar operasi harian. Log, Commit, Push, Pull, Fetch, Diff, Merge, Branch, Cherry-pick, Rebase, Tag, Export, Stash, Add submodule, dll ... Mendukung x64 secara native juga

Untuk menggunakan git secara efisien dalam tim pengembangan dengan banyak pengembang, diperlukan sistem CI yang membangun dan menguji secara terus menerus. Jenkins menyediakan kendaraan seperti itu dan saya sangat merekomendasikannya. Bagian integrasi harus dilakukan apa pun yang terjadi dan jauh lebih murah melakukannya lebih awal dan lebih sering.

Lebih cocok untuk pengembangan kolabratif daripada gitosis atau gitolite tetapi open-source adalah Gitorious . Ini adalah aplikasi Ruby on Rails yang menangani manajemen repositori dan penggabungan. Ini harus menyelesaikan banyak masalah Anda.

Git memungkinkan untuk membuat cabang pribadi. Ini mendorong pengembang untuk sering berkomitmen untuk memecah modifikasi menjadi komitmen kecil. Saat pengembang siap untuk mempublikasikan perubahannya, dia mendorong ke server pusat. Dia dapat menggunakan skrip pra-komit untuk memverifikasi kodenya jika diperlukan.

NXP mengelola Git dan Subversion dengan satu platform umum (pada skala perusahaan), mengintegrasikan pengembangan seluler Android dengan proyek perangkat lunak tradisional: http://www.youtube.com/watch?v=QX5wn0igv7Q