Konteks

Tim saya yang terdiri dari 8 insinyur saat ini sedang dalam transisi ke Git (dari Subversion) untuk hal besar berikutnya. Kami memiliki beberapa insinyur 'lebih berpengalaman' yang merasa cukup sulit untuk menjemput Git. Saya mendapat pertanyaan sepele yang sama meskipun telah memberikan buku petunjuk, kegiatan pelatihan, dan sesi papan tulis. Kami memiliki dua konsultan Junior yang mengambil semuanya dalam beberapa hari dan itu benar-benar menyoroti masalah ini. Ini bukan pola yang terbatas pada Git tetapi sudah terlihat sebagai hasilnya.

Pertanyaan

Saya khususnya merasa tidak senang dengan insinyur yang tidak bisa / tidak mau belajar - terutama staf dengan tingkat senioritas yang kami miliki di sini. Namun, saya ingin tim berhasil dan membangun produk yang hebat. Kami menggunakan model Git Flow terpusat dan saya merasa semua terminologi baru membingungkan mereka.

Adakah yang bisa saya lakukan untuk membantu karyawan ini mempelajari Git?

Sourcetree adalah klien yang digunakan oleh seluruh tim.

Beri mereka mainan.

Git itu sulit. Terutama jika Anda sudah melakukan kontrol sumber dalam paradigma yang berbeda. Saya merusak bangunan saat pertama kali saya mencoba bekerja dengan git. Itu membuat saya sangat paranoid sehingga saya tidak ingin check-in sampai semuanya selesai. Saya menyembunyikan versi di folder. Kemudian saya akhirnya menemukan apa yang saya butuhkan untuk melewatinya:

Saya membutuhkan tempat yang aman untuk bermain.

Setelah saya memiliki itu, saya sengaja menyebabkan masalah sehingga saya bisa belajar bagaimana memperbaikinya — semua di tempat yang aman. Saya mengembangkan pola yang bisa saya gunakan bahkan jika terganggu dan masih kembali ke keadaan baik. Tak lama, orang-orang datang kepada saya untuk meminta bantuan dengan git. Semua karena saya meluangkan waktu untuk bermain dengan mainan.

Jika Anda hanya melemparkannya ke ujung yang dalam, Anda akan beruntung jika mereka berhasil mengapung.

Rata-rata dev tidak membutuhkan banyak barang git. Ini adalah sistem kontrol sumber terdistribusi, tetapi sebagian besar tim akan menggunakannya dengan repo kanonik pusat untuk mendorong dan menarik dari.

Perintah inti yang dibutuhkan tim Anda adalah:

• tarik dan gabungkan perubahan dari jarak jauh dan tangani konflik yang terjadi (berpotensi rebasing)
• komit dan tekan komit ke jarak jauh (atau tekan ke repo / cabang pementasan untuk membuat perubahan ditarik ke utama setelah ditinjau)
• Untuk dukungan: perbaiki kekacauan setelah melakukan sesuatu yang salah.

yang dibutuhkan pengguna tingkat lanjut

• menangani komitmen lokal
• mengelola cabang

Untuk orang-orang yang tidak terbiasa dengan git dan mereka yang tidak ingin mempelajarinya, atur beberapa perintah alias cepat untuk melakukannya dan pastikan semuanya benar (tambahkan file baru, hapus file yang dihapus dari repo, dll.)

Pastikan ini didokumentasikan dengan baik dan bukti bodoh.

Ini berada di vokal komik xkcd , hanya menghafal perintah dan berharap hal-hal tidak menjadi kacau, ketika mereka meminta seorang profesional.

Suruh mereka menggunakan Git UI.

Jika mereka memiliki pengalaman dengan TortoiseSVN, TortoiseGit (hanya Windows) bekerja hampir persis sama. Jika tidak, SourceTree (Windows + Mac) luar biasa - kami memiliki beberapa QA non-pengembang yang telah dapat dengan mudah menguasai tugas-tugas kompleks di Git berkat SourceTree.

Jawaban ini mencoba membahas bagaimana membuat pemrogram senior tertarik git, bukan tentang cara mempelajari gitcara tercepat - untuk itu, buku git yang hebat itu hebat, atau tutorial dalam jumlah berapa pun (=> Google). Tautan yang baik untuk menjawab pertanyaan ini adalah Git adalah struktur data yang murni fungsional atau terutama singkatnya Bagaimana git menyimpan data Anda .

Saya khawatir saya memiliki pandangan yang agak suram tentang ini. Saya telah berada di posisi Anda - saya seorang gitkutu buku dan ingin mengubah tim dari svn, mari kita hadapi itu, hasil sangat kecil. Dalam kasus saya itu telah menyebabkan saya secara aktif mengubah persepsi saya sendiri, dan menerima bahwa orang, tidak bisa "dipaksa untuk bahagia". Orang-orang bukan komputer, sungguh sulit memprogram mereka. Saya masih senang karena telah mencoba, itu telah menunjukkan kepada saya dengan cara yang agak lunak apa yang saya lakukan dan apa yang tidak ingin saya lakukan dalam kehidupan profesional saya.

Ada orang-orang yang mulai termotivasi ketika ada hal-hal baru yang terlibat, dan ada orang-orang yang kehilangan motivasi. Ini tidak ada hubungannya dengan git, tetapi untuk gitkhusus Anda selalu memiliki efek "mengapa kita harus menggunakannya sama sekali jika svnbaik-baik saja?", Yang merupakan penghalang psikologis besar.

Juga, benar-benar grokking gitmemerlukan minat yang kuat dalam struktur data abstrak. Mungkin terdengar sulit dipercaya, tetapi dalam pengalaman saya ada programmer yang tidak tertarik sama sekali dan yang bosan dan terbebani oleh elemen lebih kompleks daripada array sederhana. Anda dapat berdebat bolak-balik apakah mereka harus melakukan pekerjaan yang mereka lakukan, tetapi memang demikianlah adanya.

Jika orang tidak tertarik, mereka tidak akan memahaminya. Polos dan sederhana. Saya bertaruh bahwa ketidaktertarikan adalah alasan utama buruknya nilai di sekolah, bukan karena kurangnya kecerdasan.

Yang mengatakan, inilah kurikulum yang akan saya terapkan, berdasarkan pengetahuan dari bawah ke atas. Itu tidak berhasil untuk saya, tetapi Anda dapat menganggapnya sebagai inspirasi untuk menggulung Anda sendiri.

GUI

Sedangkan pendekatan berikut tidak selalu membutuhkan dukungan GUI untuk tindakan ( git adddalam repositori dunia halo ...), hal ini membantu sangat untuk memiliki GUI untuk memvisualisasikan repositori, benar dari awal. Jika Anda tidak dapat memutuskan mana yang akan digunakan, maka ambil gitkjalan terakhir. Jika kalian menggunakan editor visual apa pun, cari gitkomponen GUI mereka .

Struktur data (statis) adalah kuncinya

Mulailah dengan menjelaskan tipe data internal (hanya ada tiga-plus-satu di antaranya: gumpalan, pohon, komit, tag beranotasi, yang terakhir tidak menjadi perhatian apa pun pada tahap ini) dan strukturnya. Anda dapat dengan mudah melakukannya di papan tulis / dengan pensil; pohon itu mudah untuk menggambar karena tidak pernah bisa diubah, Anda benar-benar bisa menambahkan barang setiap saat. Anda dapat melakukan sesi bermain di repositori lokal yang baru dibuat dan gunakan git cat-fileuntuk melihat ke objek yang sebenarnya untuk menunjukkan kepada mereka bahwa mereka sebenarnya sepele seperti yang diiklankan.

Jika Anda dapat membantu mereka untuk memahami itu

• ... hanya ada 3 jenis objek dalam sejarah, semuanya sangat sederhana, hampir sepele, dan
• ... sebagian besar gitsub- perintah hanya "memijat" objek-objek itu dengan satu atau lain cara, dengan operasi yang hampir sepele (pada dasarnya, hanya ada satu: tambahkan komit baru di suatu tempat), dan ...
• ... semuanya dapat dilihat tepat di depan Anda dengan lsdan git cat-file...

maka mereka akan memiliki terjemahan mental dari apa yang sebenarnya ada di repositori. Pada titik ini, para senior mungkin ingat bahwa bagian dalam svnadalah sihir misterius (pernah memiliki masalah dengan kunci di dalam repositori svn, atau dengan "reintegrasi" cabang dan semacamnya?), Dan ini mungkin hanya memotivasi mereka sedikit.

Satu masalah, khususnya dengan orang-orang yang terbiasa svn, adalah untuk terbiasa dengan gagasan bahwa satu komit (objek, bukan tindakan) selalu adalah seluruh pohon direktori. Di svn, orang digunakan untuk mengkomit file individual. Ini adalah pendekatan yang sangat berbeda. Oh, dan fakta bahwa istilah "komit" yang sama digunakan untuk objek statis dan tindakan juga tidak membantu.

Masalah lain untuk svnpria adalah yang svnmenggunakan sejarah linier, bukan pohon. Lagi-lagi ini sangat berbeda. Jadi ini adalah waktu untuk menunjukkan perbedaan ini banyak .

Tindakan dijelaskan dalam struktur

Ketika mereka telah memahami bagian gitrepositori apa yang dibuat, sekarang saatnya untuk menunjukkan kepada mereka secara tepat apa yang dilakukan masing-masing gitsub -perintah dalam hal itu.

Saya berbicara tentang add,, commitdalam hubungannya dengan direktori kerja lokal dan panggung (pastikan mereka mengerti bahwa direktori kerja tidak sama dengan area pementasan yang tidak sama dengan repositori).

Ketika mereka telah memahami bahwa perintah-perintah ini hanya menumbuhkan pohon (yang, sekali lagi, pada tahap ini, terdiri dari 3 jenis - gumpalan, pohon, melakukan, tidak hanya melakukan), Anda dapat melakukan yang pertama git pushdan git pull(dalam mode maju cepat! ) untuk menunjukkan kepada mereka bahwa gitsecara harfiah hanya mendorong benda-benda di sekitar, bahwa hash benar - benar hanya hash konten, bahwa Anda dapat dengan mudah menyalin barang-barang ini dengan perintah copy sistem file dan sebagainya.

Jelas, tinggal jauh dari opsi tidak penting dari perintah-perintah itu, kita berbicara di git add hello.txtsini.

Ranting

Perhatikan bahwa bercabang sangat sulit bagi svnorang - orang, karena sangat berbeda. The svnmodel jauh lebih mudah untuk memvisualisasikan, karena ada dasarnya apa-apa untuk memvisualisasikan - itu adalah terlihat jelas. The gitModel tidak begitu banyak. Pastikan mereka mengetahui sejak awal bahwa cabang dan tag hanyalah "catatan tempel" yang menunjuk ke suatu tempat, dan tidak benar-benar "ada" dalam hal sejarah statis dan abadi.

Kemudian lakukan contoh demi contoh mudah untuk menunjukkan apa yang sebenarnya dapat Anda lakukan dengan mereka. Karena Anda sendiri sepertinya sudah terbiasa git, Anda seharusnya tidak kesulitan menemukan motivasi di sana. Pastikan mereka selalu melihat ini dalam hal bagaimana pohon itu tumbuh.

Jika mereka memiliki itu, Anda dapat menjelaskan bagaimana git pullsebenarnya git fetch && git merge; bagaimana semua repositori benar-benar berisi objek yang persis sama ( git fetchhampir sama dengan menyalin barang-barang scpdi dalam direktori objek git) dan sebagainya.

Mungkin, jika pada saat ini Anda belum mencapai untuk membangunkan minat mereka, maka Anda bisa menyerah, tetapi jika mereka berhasil mencapai sejauh ini, maka mereka memiliki semua alat mental yang mereka miliki, dan harus ada sedikit ketakutan terlibat lagi. Sisanya (alur kerja git ...) harus menurun kemudian.

Kata-kata terakhir

Ini terdengar seperti banyak usaha, dan memang benar. Jangan menjual ini sebagai "kami membutuhkan ini untuk proyek ini" tetapi "ini membantu Anda secara pribadi untuk mengembangkan dan akan membantu Anda dalam semua interaksi lebih lanjut". Anda perlu banyak waktu untuk ini, dan waktu adalah uang. Jika Anda tidak memiliki penerimaan manajemen atas hal ini, itu mungkin tidak sepadan; Anda mungkin harus membicarakannya dengan bos Anda.

Jika Anda memutuskan ingin berhenti mengajar pengembang yang tampaknya tidak dapat memahami hal itu, tetapi Anda benar-benar harus menggunakannya gitdi masa mendatang, pertimbangkan untuk mengganti semua interaksi dengan gitperintah dengan skrip yang dibuat-buat atau beberapa GUI yang menghilangkan semua gitspesifikasi. Tuang semua kontrol kesalahan, dll. Dalam skrip, dan cobalah membuatnya berfungsi.

Saya ingin merujuk Anda ke entri blog ini oleh Joel Spolsky .

Alasan Anda melihat pengembang junior ini mengambilnya dengan cepat sangat mungkin karena mereka tidak memiliki gagasan yang telah ditentukan mengenai cara kerja kontrol versi pada umumnya, atau setidaknya bukan model mental yang mendarah daging. Karena itu mereka datang dengan yang bersih. Pemrogram Anda yang lebih senior cenderung mencoba menerapkan konsep yang sudah mereka ketahui, dan gagal karena itu.

Selain itu, sebanyak yang saya tidak suka mengatakannya; siapa yang benar-benar membaca manual pengguna? Biasanya mereka sangat buruk dalam menjelaskan penggunaan dasar. Lihat saja halaman git commit dari manual dan pertimbangkan berapa banyak istilah dan frasa baru yang diperkenalkan kepada seseorang yang tidak mampu mempercepat konsep ini. Tanpa perkenalan yang bagus, saya mungkin sudah menyerah untuk menggunakan Git di sana dan kemudian.

Saran pribadi saya adalah mulai menjelaskan perintah:

• git add <file>
• git melakukan
• git tarik
• git push
• status git

Menggabungkan konflik secara logis harus dijelaskan selanjutnya, karena itu pasti akan menjadi masalah pertama Anda begitu orang-orang belajar bagaimana melakukan kode.

Biasanya akan muncul situasi di mana orang perlu menginvestasikan lebih banyak waktu untuk mempelajari hal-hal (reverts, tag, menggabungkan konflik, cabang, rebasing, kait) tetapi mencoba menjelaskan semua ini sebelum diperlukan tidak akan membantu orang-orang yang mengalami kesulitan masuk ke aliran.

Hanya untuk menyelesaikannya: Dari pengalaman pribadi saya, beberapa orang tidak menghabiskan banyak waktu untuk mengeksplorasi teknik, konsep, atau alat baru dan mereka cenderung mengambil hal-hal yang Anda perkenalkan dengan kecepatan yang lebih lambat. Ini tidak berarti mereka adalah programmer yang buruk atau orang jahat, tetapi mereka biasanya memiliki keahlian yang lebih sempit.

Git adalah pemikiran ulang yang utama jika Anda belajar bagaimana melakukan kontrol sumber pada SVN. Banyak kebiasaan yang Anda kembangkan di sana (yang mungkin merupakan praktik terbaik untuk SVN) akan menyesatkan Anda saat menggunakan git. Ini terutama karena model percabangan git pada dasarnya berbeda. Itu tidak memanfaatkan folder untuk cabang, dan juga memungkinkan untuk membuatnya non-linear karena dirancang untuk mendukung kasus penggunaan yang didistribusikan dengan lebih baik. Dibutuhkan waktu untuk menghapus kebiasaan SVN dan memahami bagaimana Anda seharusnya menggunakan git.

Mulai dari yang sederhana

Anda mengatakan Anda telah memilih Gitflow sebagai standar untuk manajemen cabang. Ini menurut saya sebagai kesalahan terbesar Anda.

Mengutip Gitflow Dianggap Berbahaya :

Semua cabang ini yang digunakan memaksa GitFlow untuk memiliki seperangkat aturan rumit yang menggambarkan bagaimana mereka berinteraksi. Aturan-aturan ini, ditambah dengan sejarah tidak berwujud, membuat penggunaan GitFlow setiap hari sangat sulit bagi pengembang.

Bisakah Anda menebak apa yang terjadi setiap kali Anda membuat web aturan yang rumit seperti itu? Itu benar - orang membuat kesalahan dan melanggarnya secara tidak sengaja. Dalam kasus GitFlow, ini terjadi setiap saat. Berikut ini adalah daftar singkat, dari daftar kesalahan paling umum yang pernah saya amati. Ini diulang terus-menerus, kadang-kadang setiap hari, sering berulang-ulang oleh pengembang yang sama - yang, dalam banyak kasus, sangat kompeten di bidang perangkat lunak lain.

Pengembang Anda mungkin kewalahan oleh kerumitan standar ini. Saya pribadi tidak berpikir itu ada manfaatnya, dan artikel di atas membuat argumen yang sama. Tapi itu diskusi terpisah. Namun, secara objektif, ini adalah standar yang cukup berat dengan banyak manajemen manual, dan itu membutuhkan banyak upaya kognitif.

Anda harus mulai lebih sederhana. Jangan khawatir tentang standar percabangan sekarang. Fokus untuk membuat mereka terbiasa menggunakan git terlebih dahulu. Anda hanya perlu beberapa operasi untuk memulai:

• klon
• Tarik
• cabang
• menggabungkan
• melakukan
• Dorong
• pengetahuan tentang cara .gitignorekerjanya
• mungkin tag

Ya, sejarah Anda mungkin terlihat sedikit berantakan pada awalnya. Ini tidak apa-apa Jangan khawatir tentang itu sekarang. Dapatkan mereka menggunakan git .

Tingkatkan pengetahuan secara bertahap

Dari sini, Anda dapat secara bertahap mendidik mereka tentang penggunaan yang sedikit lebih maju.

• Ajari mereka perintah simpanan epik
• Ajari mereka cara menggunakan reset ketika mereka ingin membuang komit lokal yang baru saja mereka buat
• Ajari mereka cara mengubah
• Ajari mereka cara rebase untuk menghindari komitmen gabungan yang tidak perlu
• Ajari mereka bagaimana rebase secara interaktif untuk mengatur komitmen mereka sebelum mereka mendorong
• Ajari mereka bagaimana mereka bisa keluar dari hash, tag, atau cabang apa pun

Terutama pastikan Anda memanfaatkan peluang untuk menunjukkan kepada mereka cara yang lebih bersih untuk memasukkan kode mereka ke dalam repositori, tetapi juga ajarkan hal ini dalam kegiatan pelatihan dan apa pun yang Anda miliki. Memiliki satu atau dua guru yang bisa didekati orang ketika mereka tidak yakin apa yang harus dilakukan akan banyak membantu juga. Jika Anda memiliki sesuatu seperti Slack, buat saluran khusus dan dorong orang untuk bertanya dan menjawab pertanyaan di sana.

Kemudian pilih standar percabangan

Setelah Anda memiliki sebagian besar perusahaan yang kompeten dalam menggunakan git, maka Anda dapat melihat standar percabangan. Memilih satu di muka adalah ide yang sangat buruk karena berbagai alasan:

• Mereka tidak memiliki cukup pengetahuan tentang alat untuk memberi tahu Anda apakah standar berfungsi dengan baik untuk kasus penggunaan perusahaan
• Mereka tidak akan dapat menawarkan standar alternatif
• Mereka harus mempelajari alat dan standar secara bersamaan
• Beberapa orang akan menganggap standar yang Anda pilih adalah satu-satunya cara mereka dapat menggunakan git
• Mereka tidak akan dapat mengidentifikasi kasus tepi langka di mana standar melakukan lebih banyak ruginya daripada kebaikan

Anda tidak harus menyerahkan alur kerja Git dari gunung. Tim Anda perlu memiliki masukan tentang hal itu dan dapat memberi Anda umpan balik tentang apakah itu berjalan baik atau tidak. Mereka tidak bisa melakukan ini jika mereka bahkan belum memahami fundamentalnya. Anda tidak perlu setiap pengembang untuk memiliki pengetahuan mendalam seperti ini, tetapi Anda pasti membutuhkan beberapa yang benar-benar mendapatkannya. Dan Anda perlu sebagian besar untuk setidaknya kompeten dalam git sehingga mereka cukup tahu untuk tetap berada di jalur.

Berikut adalah beberapa alternatif untuk Gitflow yang dapat dipertimbangkan oleh tim Anda:

• OneFlow
• Alur kerja cabang fitur
• Alur kerja terpusat

Lihatlah mereka dan Gitflow, timbang terhadap kasing Anda, dan pilih yang cocok.

Saya menemukan stackoverflow sangat membantu ketika saya pertama kali mengambil terminologi Git. Pertanyaan-pertanyaan seperti ini benar-benar berguna bagi saya (kebanyakan karena keringkasannya) dan saya membiarkannya terbuka selama beberapa minggu pertama saya menggunakannya. Mungkin mencetak beberapa jawaban dengan huruf tebal? Terutama diagram yang pertama.

Apa perbedaan antara "git commit" dan "git push"?

Apa perbedaan antara 'git pull' dan 'git fetch'?

Saya juga menemukan representasi visual dari trunk menjadi sangat berguna tetapi Anda sudah membahasnya dengan SourceTree.

_{Selain itu, bit ini mungkin termasuk dalam komentar tetapi saya tidak memiliki perwakilan: Saya salah satu konsultan junior yang disebutkan dalam pertanyaan. Sebelum saya mulai, saya mempunyai ide tentang apa itu sistem kontrol sumber dan saya sudah menyodok SVN dua kali, Gusdor memberi saya lebih banyak kredit daripada yang layak saya terima. Seluruh tim memiliki pelatihan Git khusus berkualitas tinggi, mainan dan waktu untuk bermain. Masalahnya bukan dengan instruksi Gusdor. Saya harap ada solusi alternatif yang baik untuk ini sehingga saya dapat mem-bookmark-nya dengan keras dan belajar lebih banyak.}

Beli mereka buku

Jujur, saya jatuh tepat di kamp yang Anda gambarkan. Saya berasal dari latar belakang SourceSafe dan ClearCase. Pada awalnya, Git benar-benar tidak dapat dipahami oleh saya, meskipun bos saya berjalan melewatinya beberapa kali.

Yang membantu saya adalah sebuah buku yang dengan jelas menggambarkan apa yang sedang terjadi, tetapi yang lebih penting, bagaimana Git secara fundamental berbeda dari sistem kontrol sumber apa pun yang pernah saya gunakan sebelumnya. Sekarang, saya lebih suka Git daripada pilihan lain.

Sayangnya, saya tidak dapat mengingat buku mana yang telah saya baca pada saat itu, tetapi, pastikan buku mana yang Anda dapatkan (atau arahkan ke mereka) yang berfokus pada bagaimana itu berbeda dan bagaimana ia membutuhkan pola pikir yang berbeda.

Tebakan terbaik untuk rekomendasi buku adalah:

Pro Git oleh Scott Chacon (tautan Amazon untuk kemudahan ... beli dari siapa pun yang Anda inginkan: https://www.amazon.com/dp/1484200772/ref=cm_sw_r_cp_dp_T1_BNruzbBQ8G9A6 )

Catatan : Jangan tidak membeli buku referensi untuk Git. Itu tidak akan membantu sama sekali.

Dari pengalaman saya, beberapa orang bisa merasa nyaman menggunakan git tanpa memahaminya. Mereka menemukan tutorial dasar, mengambil perintah-perintah dasar dan mereka siap untuk digunakan. Itu mungkin di mana Anda cocok untuk konsultan junior. Saya tidak percaya bahwa Anda benar-benar dapat belajar git dalam beberapa hari!

Orang lain, tidak bisa melakukannya, mereka perlu memahami apa yang sedang dilakukan git, dan itu membutuhkan waktu lebih lama. Saya termasuk dalam kategori itu; Saya merasa sangat terbantu untuk bermain-main dengan isi .gitdirektori, saat itulah segalanya mulai mengklik untuk saya. Juga sesi satu lawan satu dengan pimpinan teknologi kami membantu.

Anda dapat melakukan tutorial satu-satu karena orang-orang belajar secara berbeda dan dapat benar-benar bingung tentang bagian-bagian yang berbeda, dalam sesi satu lawan satu lebih mudah dilihat, dan diselesaikan. Jika mereka benar-benar terganggu oleh fakta bahwa mereka tidak mengerti bagaimana git melacak cabang, menunjukkan kepada mereka isi .gitdirektori, dan seterusnya ...

Saya bermain-main dengan memperkenalkan keberadaan gitsaya (dari TFS) sehingga pertanyaan Anda tepat waktu untuk saya, terutama karena saya juga mendapat dorongan balik ketika memulai pembicaraan tentang subjek.

Dalam Peopleware , tesis yang mendasari seluruh buku adalah:

Masalah utama dari pekerjaan kami tidak begitu banyak teknologi seperti sosiologis di alam .

Saya mengemukakan ini karena masalah kita bukan masalah teknis. git, meski agak tumpul, mungkin tidak di luar kemampuan Anda atau pengembang senior saya, kecuali mereka sangat bodoh *.

Mari kita lihat dari sudut pandang devs Anda, sebagai orang, bukan mesin teknis:

Anda meminta mereka untuk berhenti menggunakan sistem kontrol sumber yang mereka miliki (kemungkinan) penguasaannya, untuk yang tidak mereka miliki. Ini seperti meminta seorang gitahli untuk berhenti menggunakan gitdan pindah ke svnbukan? Saya rasa ahli git akan kesal, dan mungkin tidak berusaha keras svnkarena gitberfungsi dengan baik dan ada bagian yang sangat dia sukai yang sangat sulit dilakukan svn.

Mungkin itulah sebabnya yunior melakukannya dengan lebih baik - mungkin mereka belum memahami svndan gitmerupakan kesempatan mereka untuk membuangnya ^.

Para lansia waspada dengan biaya peluang - jika mereka belajar git, maka mereka tidak:

• Belajar Bereaksi / Sudut / Cepat / Blockchain / Kotlin (beberapa hal lain yang menurut mereka harus dipelajari).
• Melakukan DIY / meraut / berlayar / puisi / glockenspiel / apa pun yang sebenarnya ingin mereka lakukan.
• Menghabiskan waktu dengan anak-anak / kerabat / teman / orang lain yang signifikan.

• Memberikan "hal baru yang besar" ini - ada tenggat waktu, anggaran, dll. Mereka mungkin khawatir tentang hal itu.

  "Saya perlu melakukan semua hal di atas, mengapa saya harus menggunakan git ketika kita sudah memiliki kontrol sumber?"

Alasan apa yang telah Anda berikan kepada mereka untuk beralih dari satu hal yang mereka kuasai, ke hal lain yang terus terang canggung ketika Anda baru mengenalnya, dan membutuhkan pemikiran ulang sepenuhnya tentang bagaimana Anda melakukan dev? Sudahkah Anda menjelaskan manfaat gitfitur?

Tarik-permintaan? Checkin berbutir halus? Sumber terdistribusi? Garpu?

Apakah mereka memasukkan alasan-alasan ini? Ini adalah perubahan struktural besar-besaran jika Anda berada dalam pola pikir kontrol sumber terpusat - bukan hanya perubahan teknis tetapi juga budaya, dan kami tahu betapa sulitnya mengubah budaya.

Jadi pada dasarnya, pikirkan apa yang Anda minta pengembang Anda lakukan dan pastikan itu untuk alasan yang tepat. Jika Anda hanya ingin melakukannya karena svnbodoh dan tua dan tidak ada yang menggunakan lagi maka tidak apa-apa, tetapi itu lebih sulit untuk dijual kepada orang lain yang tidak berpikir seperti Anda dan hanya ingin melanjutkan hari mereka. Anda perlu menyatakan manfaat dalam hal yang masuk akal bagi tim Anda dan proyek. Jika Anda bisa membuat mereka setuju bahwa gititu sepadan dengan rasa sakitnya, maka Anda tidak perlu khawatir tentang mereka mempelajari teknologi, hanya menyetujui alur kerja apa pun yang telah Anda buat.

Semoga berhasil.

Saya pikir ini kurang dari pertanyaan rekayasa perangkat lunak dan lebih dari pertanyaan psikologi. Saya ingin merujuk Algorithms to Live By: The Computer Science of Humand Decisions. Di dalamnya penulis masuk ke topik tradeoff mengeksplorasi / mengeksploitasi. Manusia biasanya melalui fase eksplorasi dan kemudian melalui fase mengeksploitasi (menggunakan) apa yang telah mereka eksplorasi. Ada beberapa teori matematika yang kuat di balik mengapa hal ini terjadi untuk mendapatkan penggunaan yang optimal dari sesuatu dalam interval tertentu.

Ini juga meluas ke usia dan pengalaman. Manusia melihat hidup mereka sendiri sebagai suatu interval, dan setelah fase eksplorasi tertentu itu optimal untuk mulai menggunakan pengetahuan Anda. Mereka mengutip sebuah penelitian di mana peserta yang lebih tua ditanya apakah mereka ingin bertemu seseorang yang terkenal yang mereka sukai atau lebih tepatnya anggota keluarga. Mereka biasanya memilih anggota keluarga, sedangkan yang lebih muda memilih orang terkenal lebih mungkin. Namun ketika ditanya untuk membayangkan bagaimana mereka akan memutuskan apakah mereka 20 tahun lebih muda, orang tua secara rutin juga memilih orang yang terkenal. Yang menunjukkan bahwa orang berhenti membangun jejaring sosial mereka ketika mereka percaya bahwa mereka memiliki lebih sedikit dari eksplorasi daripada mengeksploitasi apa yang sudah mereka ketahui.

Insinyur senior Anda mungkin lebih tua, mereka mungkin telah melalui beberapa sistem kontrol versi. SVNmungkin yang terbaik yang mereka gunakan sampai sekarang (setidaknya melihat sistem versi lama yang saya gunakan, SVN mengalahkan semuanya).

Strategi optimal mereka adalah mengeksploitasi SVN, karena mereka telah melakukan penjelajahan dan menemukan ini yang terbaik, yang mereka eksploitasi sekarang.

Ini adalah psikologi dasar manusia, dan ratusan ribu tahun optimisasi evolusioner yang Anda lawan.

Anda harus menunjukkan kepada mereka a) berapa lama karier yang mereka miliki di depan mereka, untuk membuat mereka berpikir dari sudut pandang yang berbeda tentang interval waktu yang mereka lihat dan b) bertanya kepada mereka apa yang menurut mereka hebat dan apa yang mereka pikirkan. hilang dalam SVN. Anda dapat memberikan ratusan manfaat git, tetapi mereka sudah memiliki ide yang jelas mengapa SVNyang terbaik, setelah semua yang mereka alami mungkin 5 sistem kontrol versi sebelumnya. Anda perlu menemukan celah dalam baju besi argumen itu, dan kemudian melihat apakah gitdapat memecahkan masalah ini, maka mereka akan meyakinkan diri mereka sendiri.

Jangan beri mereka alat atau GUI untuk menggunakan Git. Itu hanya akan membingungkan hal-hal. Git dikandung untuk dijalankan pada baris perintah sehingga mungkin harus menjadi tempat itu dipelajari. Setiap GUI dapat datang dengan ketentuan dan kekhasan sendiri, tetap dengan apa yang sederhana.

Berikutnya adalah untuk melihat beberapa masalah yang dilakukan Git lebih baik dari SVN. Untuk membuat tim Anda mempelajarinya, Anda perlu memotivasi mereka untuk melihat mengapa git lebih baik.

• Kemampuan untuk melakukan sementara tidak terhubung ke jaringan
• Kemampuan untuk membuat dan bermain dengan cabang mereka sendiri
• Tambalan yang bisa dikirim antara satu sama lain dan masih menggabungkan trek
• memetik ceri tanpa rasa sakit.
• perubahan rebasing
• menemukan bug dengan splice git

Saya yakin SVN telah pindah dalam beberapa tahun terakhir, tetapi itu dulu adalah hal-hal yang akan menyebabkan dunia kesakitan. Jika para devs melihat bahwa alat baru ini bukan hanya sesuatu yang mewah tetapi memiliki kelebihan yang solid untuk pekerjaan mereka, mereka mungkin akan mendapatkan lebih dari itu.

Ini adalah hal baru untuk dipelajari dan ada cukup banyak kesamaan yang bisa membingungkan, tetapi sebenarnya pada tahun 2017 DCVS merupakan keterampilan yang sangat penting bagi setiap pengembang.

Katakan pada mereka untuk tidak khawatir

Di Git, begitu pekerjaan dilakukan, hampir tidak mungkin hilang. Satu-satunya pekerjaan yang bisa dengan mudah Anda hilangkan adalah pekerjaan yang belum berkomitmen.

Tunjukkan pada mereka cara git reflogkerjanya. Mereka tidak harus tahu cara menggunakannya; mereka hanya perlu tahu itu ada di sana, sehingga mereka bisa mendapatkan bantuan untuk mendapatkan pekerjaan mereka kembali jika ada masalah.

Kemudian kesan kepada mereka satu aturan sederhana ini: Ketika ragu, komit. Mereka selalu dapat mencadangkan komit nanti (bahkan dari jarak jauh!).

Jangan gunakan GUI

GUI akan memberi mereka awal yang lebih cepat, tetapi mereka tidak akan pernah benar-benar mengerti Git. Selain itu, saya telah menemukan bahwa itu tidak "hampir tidak mungkin untuk kehilangan" pekerjaan berkomitmen ketika menggunakan Git GUI. Saya telah melihat GUI melakukan hal-hal mengerikan seperti menyajikan daftar periksa pada penggabungan dan kemudian, jika pengguna menghapus centang item, hapus file itu dari sejarah tanpa peringatan dan tidak ada catatan tentang itu. GUI jauh lebih buruk daripada hanya belajar Git baris perintah.

Kode program pasangan berkomitmen

Belajar git add -Adiikuti git committidak boleh terlalu sulit, tetapi terutama ketika menggabungkan (atau rebasing) dengan remote, mereka akan membutuhkan bantuan. Jelaskan bahwa siapa pun boleh meminta bantuan kapan saja. Bersiap saat mereka mengetik perintah dan mencatat. Seiring waktu mereka akan secara bertahap meningkatkan jumlah situasi yang dapat mereka tangani tanpa bantuan.

Git sudah aman

Seseorang di atas berbicara tentang memiliki "tempat yang aman untuk bermain." Tapi Git adalah tempat aman itu. Hanya ada dua kasus sehari-hari yang normal di mana mudah kehilangan pekerjaan:

• Kode tidak dikomit
• Menggunakan GUI

Pastikan mereka melakukan awal dan sering, dan bahwa mereka tidak memulai jalan yang salah dengan GUI, dan mereka akan segera melihat bahwa mereka dapat mempercayai Git dengan kode mereka bahkan lebih dari sistem kontrol sumber lain di masa lalu.

Saya akan menyarankan melihat Gitless . Ini adalah pembungkus git yang menyederhanakan banyak alur kerja dasar (tidak perlu khawatir tentang area pementasan, cabang menyimpan salinan kerja file mereka sendiri, penggunaan yang lebih sederhana git rebaseditangani dengan gl fuse, dll.) Sambil mempertahankan repositori git yang mendasari untuk kolaborasi atau jika Anda perlu melakukan sesuatu yang tidak biasa. Juga, pesannya sedikit lebih ramah-pemula. Dan perintahnya cukup dekat sehingga git dapat bertindak sebagai batu loncatan jika mereka perlu menggunakan sistem tanpa gitless di atasnya untuk alasan apa pun.

Saya mencoba mendokumentasikan dasar-dasar cara menggunakan baris perintah git. Itu masih membingungkan - baik untuk saya sendiri (yang memiliki pengalaman menggunakan Perforce dan Source Safe), dan untuk programmer yang lebih suka paradigma lama "hanya zip folder yang relevan". Itu mengkhawatirkan memiliki alat buram memodifikasi isi direktori kerja saya, dan sering harus berdebat dengan alat untuk memasukkan perubahan tertentu ke dalam direktori kerja saya.

Sebaliknya, saya menggunakan dua jenis tipuan.

• Saya menggunakan GitKraken untuk memberikan sejarah visual cabang saya, dan GUI yang menyembunyikan pernyataan baris perintah. GitKraken menangani interaksi antara repositori jarak jauh "asal" dan apa yang git pikirkan adalah direktori kerja lokal saya.

• Saya juga menyimpan direktori kerja lokal "nyata" yang terpisah dari apa yang menurut git adalah direktori kerja lokal saya. Saya menyinkronkan dua direktori kerja ini secara manual, yang memungkinkan saya menjadi jauh lebih nyaman bahwa setiap perubahan dalam direktori kerja saya adalah apa yang saya inginkan.

Adakah yang bisa saya lakukan untuk membantu karyawan ini mempelajari Git?

Apakah Anda yakin masalahnya adalah Git dan bukan yang lain? Apa yang saya dapatkan dari komentar adalah bahwa manajemen memutuskan untuk mengubah sesuatu tanpa menerima dukungan dari kontributor senior dan menugaskan seseorang junior kepada mereka untuk mendorong perubahan. Itu tampaknya titik awal yang baik untuk kegagalan, apa pun perubahannya. Kompleksitas Git bukan masalah, masalahnya adalah bahwa perubahan yang mereka rasa tidak perlu dipaksakan pada mereka.

Jadi jangan fokus pada cara mengajari mereka Git, asalkan mereka tidak melihat manfaat untuk peralihan, mereka akan menyeret kaki mereka. Tunjukkan pada mereka bagaimana Git adalah solusi untuk masalah yang mereka miliki sekarang. Bukan bagaimana Git dapat memberikan mereka hal-hal yang mereka rasa belum butuhkan, bukan bagaimana Git memberikan solusi untuk masalah orang lain, bagaimana Git menyelesaikan masalah yang mereka lawan sekarang. Maka mengajari mereka Git tidak akan menjadi masalah.

Seringkali Git mulai digunakan di perusahaan untuk menyelesaikan masalah dengan cabang. Ya itu lebih baik di cabang daripada Subversion, tetapi tidak melakukan sihir apa pun.

Sangat mungkin bahwa pengembang yang berpengalaman memiliki pekerjaan di banyak perusahaan yang memilikinya.

• Menciptakan cabang sebagai manajemen tidak mau memutuskan antara tuntutan yang saling bertentangan
• Telah menggunakan cabang untuk setiap pelanggan alih-alih sakelar konfigurasi.
• Harus memiliki cabang perbaikan bug untuk setiap pelanggan karena manajemen tidak mau membuat semua pelanggan meng-upgrade ke versi perangkat lunak yang sama
• Dll

Karena itu segera setelah beberapa orang memberi tahu saya bahwa alat itu bagus dalam hal percabangan, kata saya kepada saya.

Manajemen tidak ingin memutuskan apa yang akan dilakukan perusahaan, dan lebih suka bahwa saya membuang-buang hidup harus menggabungkan pekerjaan saya ke 101 cabang yang berbeda, bersama dengan harus menguji 101 rilis perangkat lunak yang berbeda.

Juga konsep bahwa dua orang akan mengerjakan file yang sama pada saat yang sama adalah "baik", tidak dapat diterima oleh seseorang yang telah mengalami proyek yang dikelola dengan baik, oleh karena itu mempromosikan Git sebagai alat untuk melakukannya, tidak mungkin untuk berpengalaman pengembang menyukai Anda.

Setiap kali saya melihat sejarah di Git, sangat sulit untuk melihat mengapa kode diubah, karena 50% atau lebih dari sejarah adalah penggabungan yang secara logis seharusnya tidak pernah publik dan mereka menjadi tidak berarti segera setelah kode meninggalkan pengembang. mesin.

Tetapi saya ingin bekerja di suatu tempat di mana:

• Tidak ada kode masuk ke sistem pusat sampai telah dikompilasi dan unit diuji pada server kepercayaan.
• Ada cara mudah untuk melacak ulasan kode
• Di mana setiap kali saya melakukan "get", kode selalu mengkompilasi dan berfungsi
• Di mana saya dapat mendorong perubahan saya tanpa harus berpacu dengan orang lain, atau harus menyimpang di kantor untuk melihat apakah saya telah merusak bangunan.

Jadi, selesaikan masalah yang sebenarnya dan jika Git adalah bagian dari solusi yang akan dibeli oleh pengembang berpengalaman Anda, tetapi jangan berharap mereka menyukai Git hanya karena itu adalah mainan keren yang dapat melakukan "penggabungan ajaib".

Oleh karena itu di mana saja yang memungkinkan pengembang mendorong dari Git lokal mereka ke Git pusat melakukan kesalahan, proses otomatis terkontrol harus mengambil perubahan dari pengembang dan setelah menguji mereka dll, dan memeriksa merger ok memperbarui Git pusat membuang semua cabang dll yang tidak menarik untuk jangka panjang.

Saya berharap Kiln ( http://www.fogcreek.com/fogbugz/devhub ) atau bahkan GitHub menggunakan alur kerja "tarik permintaan" akan membuat pengembang yang berpengalaman senang, mis. Jangan mulai dengan take level rendah, mulai dengan peningkatan proses.