Ini kedengarannya berlawanan dengan intuisi, tapi dengarkan aku:
Dorong mereka untuk mulai bereksperimen dengan git
Salah satu hal menarik tentang git adalah sangat mudah untuk membuat operasi lokal benar-benar aman. Ketika saya pertama kali mulai menggunakan git, salah satu hal yang saya temukan adalah melakukan zip seluruh direktori sebagai cadangan jika saya mengacaukan sesuatu. Saya kemudian menemukan bahwa ini adalah lumpur yang sangat besar dan hampir tidak pernah benar-benar diperlukan untuk melindungi pekerjaan Anda, tetapi memiliki kebajikan menjadi sangat aman dan sangat sederhana, bahkan jika Anda tidak tahu apa yang sedang Anda lakukan dan bagaimana perintah yang ingin Anda coba akan berubah. Satu-satunya hal yang harus Anda hindari ketika Anda melakukan ini adalah push
. Jika Anda tidak mendorong apa pun, ini adalah cara yang 100% aman untuk mencoba apa pun yang Anda inginkan.
Takut mencoba hal-hal adalah salah satu kendala terbesar untuk belajar git. Ini memberi Anda begitu banyak kontrol atas segala sesuatu yang agak menakutkan. Kenyataannya adalah bahwa Anda dapat tetap berpegang pada beberapa operasi yang sangat aman untuk sebagian besar penggunaan sehari-hari Anda, tetapi menemukan perintah mana yang perlu ditelusuri.
Dengan memberi mereka rasa aman , mereka akan jauh lebih bersedia untuk mencoba mencari tahu bagaimana melakukan sesuatu sendiri. Dan mereka akan jauh lebih diberdayakan untuk menemukan aliran pekerjaan pribadi pada mesin lokal mereka yang bekerja untuk mereka. Dan jika tidak semua orang melakukan hal yang sama secara lokal , itu bagus, asalkan mereka mematuhi standar dengan apa yang mereka dorong . Jika perlu ritsleting seluruh repo sebelum melakukan operasi untuk membuat mereka merasa seperti itu, tidak apa-apa; mereka dapat mengambil cara-cara yang lebih baik untuk melakukan sesuatu saat mereka pergi dan saat mereka mencoba hal-hal Apa pun untuk membuat diri Anda mulai mencoba hal-hal dan melihat apa yang dilakukannya.
Ini tidak berarti pelatihan tidak berharga. Sebaliknya, pelatihan dapat membantu memperkenalkan Anda pada fitur dan pola serta norma. Tetapi itu bukan pengganti untuk duduk dan benar - benar melakukan hal - hal dalam pekerjaan sehari-hari Anda. Baik git maupun SVN bukanlah hal-hal yang bisa Anda ikuti di kelas dan Anda tahu semua tentangnya. Anda harus menggunakannya untuk memecahkan masalah Anda agar terbiasa dengan mereka dan fitur mana yang cocok untuk masalah yang mana.
Berhentilah mencegah mereka mempelajari seluk beluk git
Saya sebutkan tidak mendorong apa pun, yang sebenarnya bertentangan dengan salah satu hal yang telah Anda ajarkan kepada mereka: untuk selalu "Berkomitmen & Dorong". Saya percaya Anda harus berhenti menyuruh mereka melakukan ini dan menyuruh mereka mulai melakukan yang sebaliknya. Git pada dasarnya memiliki 5 "tempat" di mana perubahan Anda dapat:
- Di disk, tidak dikomit
- Dipentaskan tetapi tidak dilakukan
- Dalam komit lokal
- Di simpanan lokal
- Repositori jarak jauh (Hanya komit dan tag yang didorong dan ditarik antara berbagai repositori)
Alih-alih mendorong mereka untuk menarik dan mendorong semuanya dalam satu langkah, dorong mereka untuk memanfaatkan 5 tempat berbeda ini. Dorong mereka untuk:
Ini akan mendorong mereka untuk memeriksa pekerjaan mereka sebelum dibuat tersedia untuk umum bagi semua orang, yang berarti mereka akan menangkap kesalahan mereka lebih cepat. Mereka akan melihat komit dan berpikir, "Tunggu, bukan itu yang saya inginkan," dan tidak seperti di SVN, mereka dapat kembali dan mencoba lagi sebelum mereka mendorong.
Setelah mereka terbiasa dengan gagasan untuk memahami di mana perubahannya, maka mereka dapat mulai memutuskan kapan harus melewati langkah-langkah dan menggabungkan operasi tertentu (kapan harus menarik karena Anda sudah tahu Anda ingin mengambil + gabungan atau kapan harus mengklik opsi Komit & Tekan) .
Ini sebenarnya adalah salah satu manfaat luar biasa dari git dibandingkan SVN, dan git dirancang dengan pola penggunaan ini. SVN, sebaliknya, mengasumsikan repositori sentral, jadi tidak mengejutkan jika tooling untuk git tidak dioptimalkan untuk alur kerja yang sama. Di SVN, jika komit Anda salah, satu-satunya jalan nyata Anda adalah komit baru untuk membatalkan kesalahan.
Melakukan ini sebenarnya akan secara alami mengarah ke strategi berikutnya:
Imbaulah mereka untuk menggunakan cabang lokal
Cabang-cabang lokal sebenarnya memudahkan banyak titik sakit bekerja pada file bersama. Saya dapat membuat semua perubahan yang saya inginkan di cabang saya sendiri, dan itu tidak akan mempengaruhi siapa pun karena saya tidak mendorongnya. Kemudian ketika saatnya tiba, saya dapat menggunakan semua strategi merger dan rebase yang sama, hanya lebih mudah:
- Saya dapat rebase cabang lokal saya, yang membuat penggabungannya menjadi sepele master.
- Saya bisa menggunakan gabungan biasa (membuat komit baru) di master untuk membawa perubahan cabang lokal saya ke dalamnya.
- Saya dapat memadukan seluruh cabang lokal saya menjadi satu komit pada master jika saya pikir cabang saya terlalu berantakan untuk diselamatkan.
Menggunakan cabang lokal juga merupakan awal yang baik untuk mencari tahu strategi percabangan yang sistematis. Ini membantu pengguna Anda memahami kebutuhan percabangan mereka sendiri dengan lebih baik, sehingga Anda dapat memilih strategi berdasarkan kebutuhan dan tingkat pemahaman / keterampilan tim saat ini dan tidak hanya menjatuhkan Gitflow karena semua orang telah mendengarnya.
Ringkasan
Singkatnya, git bukan SVN dan tidak bisa diperlakukan seperti itu. Kamu butuh:
- Hilangkan rasa takut dengan mendorong eksperimen yang aman.
- Bantu mereka memahami perbedaan git sehingga mereka dapat melihat bagaimana itu mengubah alur kerja normal mereka.
- Bantu mereka memahami fitur yang tersedia untuk membantu mereka memecahkan masalah mereka dengan lebih mudah.
Ini semua akan membantu Anda secara bertahap mengadopsi penggunaan git yang lebih baik, sampai Anda mencapai titik di mana Anda dapat mulai menerapkan serangkaian standar.
Fitur spesifik
Dalam jangka waktu dekat, ide-ide berikut mungkin membantu.
Rebase
Anda menyebutkan rebase dan bahwa Anda tidak benar-benar memahaminya dalam pertanyaan Anda. Jadi, inilah saran saya: coba apa yang baru saja saya jelaskan. Buat beberapa perubahan secara lokal sementara orang lain mendorong beberapa perubahan. Komit perubahan Anda secara lokal . Zip up direktori repositori Anda sebagai cadangan. Ambil perubahan orang lain. Sekarang coba jalankan perintah rebase dan lihat apa yang terjadi pada komit Anda! Anda dapat membaca posting blog yang tak ada habisnya atau menerima pelatihan tentang rebase dan bagaimana Anda harus atau tidak menggunakannya, tetapi tidak ada yang menggantikan untuk melihatnya langsung dalam tindakan. Jadi cobalah .
merge.ff=only
Yang ini akan menjadi masalah selera pribadi, tapi saya akan merekomendasikan setidaknya untuk sementara karena Anda telah menyebutkan bahwa Anda sudah memiliki masalah dengan penanganan konflik. Saya merekomendasikan pengaturan merge.ff
keonly
:
git config --global merge.ff only
"ff" adalah singkatan dari "fast forward." Penggabungan maju cepat adalah ketika git tidak perlu menggabungkan perubahan dari komit yang berbeda. Itu hanya memindahkan pointer cabang ke komit baru sepanjang garis lurus dalam grafik.
Apa yang dilakukan dalam praktik ini adalah mencegah git untuk secara otomatis mencoba membuat komit gabungan. Jadi jika saya melakukan sesuatu secara lokal dan kemudian menarik perubahan orang lain, alih-alih mencoba membuat komit gabungan (dan berpotensi memaksa pengguna untuk menangani konflik), gabungan tersebut akan gagal. Akibatnya, git hanya akan melakukan a fetch
. Ketika Anda tidak memiliki komit lokal, penggabungan berlangsung secara normal.
Ini memberi pengguna kesempatan untuk meninjau berbagai komitmen sebelum mencoba menggabungkan mereka dan memaksa mereka untuk membuat keputusan tentang cara terbaik menangani penggabungan mereka. Saya dapat rebase, lanjutkan dengan penggabungan (menggunakan git merge --no-ff
untuk memotong konfigurasi), atau saya bahkan dapat menunda menggabungkan perubahan saya untuk saat ini dan menanganinya nanti. Saya pikir kecepatan kecil ini akan membantu tim Anda menghindari membuat keputusan yang salah tentang penggabungan. Anda dapat membiarkan tim Anda mematikannya setelah mereka menjadi lebih baik dalam menangani penggabungan.