Tidak seperti Centralized Version Control Systems (CVCSs), sifat terdistribusi Git memungkinkan Anda untuk menjadi jauh lebih fleksibel dalam bagaimana pengembang berkolaborasi dalam proyek. DI centralized systems, Setiap pengembang adalah node yang bekerja kurang lebih sama pada hub pusat. Di Git, bagaimanapun, Setiap pengembang berpotensi menjadi node dan hub – itulah, Setiap pengembang bisa menyumbang kode ke repositori yang lain dan memelihara repositori umum dimana orang lain dapat mendasarkan pekerjaan mereka dan kemana mereka bisa menyumbangkannya. Ini membuka berbagai kemungkinan alur kerja untuk proyek anda/atau tim anda, Jadi kita akan membahas beberapa paradigma umum yang memanfaatkan fleksibilitas ini. Kita akan membahas kelebihan dan kekurangan masing-masing desain; anda dapat memilih satu untuk digunakan, atau anda bisa mencampur dan mecocokkan fitur dari masing-masing.
Di centralized systems, umumnya ada satu model kolaborasi–alur kerja terpusat. Satu pusat hub, atau repositori, dapat menerima kode, dan setiap orang menyinkronkan pekerjaan mereka ke situ. Sejumlah pengembang adalah node – konsumen dari itu hub – dan menyinkronkan ke satu tempat itu.
Ini berarti bahwa jika dua pengembang mengkloning dari hub dan keduanya melakukan perubahan, pengembang pertama yang push perubahan back up-nya dapat melakukannya tanpa masalah. Pengembang kedua harus bergabung dalam pekerjaan pertama sebelum push perubahan, agar tidak menimpa perubahan pengembang pertama. Konsep ini sama seperti di Git seperti ini juga di Subversion (or any CVCS), dan model ini bekerja dengan baik di git.
Jika anda telah terbiasa dengan alur kerja terpusat di perusahaan anda atau tim anda, anda bisa dengan mudah melanjutkan menggunakan alur kerja itu dengan Git. Cukup atur satu repositori, dan berikan setiap orang di tim anda push akses; Git tidak akan membiarkan pengguna saling menimpa. Katakan John dan Jessica keduanya memulai pekerjaan dalam waktu yang bersamaan. John menyelesaikan perubahannya dan pushes itu ke server. Kemudian Jessica mencoba untuk push perubahannya, tetapi server menolaknya. Dia diberitahu bahwa dia mencoba untuk push tidak-maju-cepat perubahan dan bahwa dia tidak akan dapat melakukannya sampai dia menjemput dan menyatu. Alur kerja ini sangat menarik bagi banyak orang karena ini adalah paradigma yang sudah biasa dan nyaman bagi banyak orang.
Ini juga tidak terbatas pada tim kecil. Dengan model percabangan Git, Ini mungkin bagi ratusan pengembang untuk berhasil mengerjakan proyek tunggal melalui puluhan cabang secara bersamaan.
Karena Git memungkinkan Anda memiliki beberapa repositori jarak jauh, ini memungkinkan untuk memiliki sebuah alur kerja dimana setiap pengembang memiliki akses tulis ke repositori umum mereka sendiri dan membaca akses untuk orang lain. Skenario ini sering dimasukkan sebuah kanonik repositori itu mewakili ``official'' proyek. Untuk berkontribusi pada proyek itu, Anda membuat tiruan publik proyek Anda sendiri dan push perubahan anda untuk itu. Lalu, Anda bisa mengirim permintaan kepada pengelola proyek utama untuk pull di perubahan anda. Pengelola kemudian dapat menambahkan repositori Anda sebagai remote, uji perubahan Anda secara lokal, menggabungkan mereka ke cabangnya, dan push kembali ke repositori mereka. proses pekerjaan sebagai berikut (see Integration-manager workflow.):
-
Pemelihara proyek pushes ke repositori umum mereka.
-
Sebuah klon penyumbang repositori dan membuat perubahan.
-
Penyumbang tersebut pushes salinan publik mereka sendiri.
-
Penyumbang mengirimkan pemelihara sebuah e-mail meminta mereka untuk pull perubahan.
-
Pengelola menambahkan repo kontributor sebagai remote dan bergabung secara lokal.
-
Pengelola pushes perubahan gabungan ke repositori utama.
Ini adalah alur kerja yang sangat umum dengan alat berbasis hub seperti GitHub atau GitLab, dimana mudah untuk mengerjakan proyek dan push perubahan Anda ke garpu Anda untuk dilihat semua orang. Salah satu keuntungan utama dari pendekatan ini adalah Anda dapat terus bekerja, dan pengelola repositori utama dapat menarik perubahan Anda kapan saja. Kontributor tidak perlu menunggu proyek memasukkan perubahan mereka – Masing-masing pihak bisa bekerja dengan kecepatan mereka sendiri.
Ini adalah varian dari alur kerja multi-repositori. Ini umumnya digunakan oleh proyek besar dengan ratusan kolaborator; Salah satu contoh yang terkenal adalah kernel Linux. Berbagai manajer integrasi bertanggung jawab atas bagian-bagian tertentu dari repositori; mereka disebut letnan. Semua letnan memiliki satu manajer integrasi yang dikenal sebagai diktator yang baik hati. Repositori diktator baik hati tersebut berfungsi sebagai repositori referensi dari mana semua kolaborator perlu pull. Proses pekerjaannya seperti ini (see Benevolent dictator workflow.):
-
Pengembang reguler bekerja pada cabang topik mereka sendiri dan mendasarkan ulang pekerjaan mereka di atas dari
master. seorangmastercabang adalah milik diktator. -
Letnan menggabungkan cabang topik pengembang menjadi cabang
mastermereka. -
Diktator menggabungkan cabang letnan 'master` ke cabang
mastersang diktator. -
Diktator pushes
mastermereka ke repositori referensi sehingga pengembang lainnya dapat mendasarkan ulang di atasnya.
Alur kerja seperti ini tidak umum, namun bisa bermanfaat dalam proyek yang sangat besar, atau di lingkungan yang sangat hierarkis. Hal ini memungkinkan pemimpin proyek (the dictator)untuk mendelegasikan sebagian besar pekerjaan dan mengumpulkan himpunan bagian kode yang besar di banyak titik sebelum mengintegrasikannya.
Ini adalah beberapa alur kerja yang umum digunakan yang mungkin dilakukan dengan sistem terdistribusi seperti Git, namun anda dapat melihat Bahwa banyak variasi mungkin sesuai dengan alur kerja dunia nyata Anda. Sekarang Anda bisa (hopefully) menentukan kombinasi alur kerja mana yang sesuai untuk Anda, kami akan membahas beberapa contoh yang lebih Spesifik bagaimana cara mencapai peran utama yang membentuk arus yang berbeda. Di bagian selanjutnya, Anda akan belajar tentang beberapa pola umum untuk berkontribusi dalam sebuah proyek.