Apa yang bisa saya lakukan untuk pengembang yang tidak bisa belajar Git? [Tutup]


68

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.


1
Komentar bukan untuk diskusi panjang; percakapan ini telah dipindahkan ke obrolan .
maple_shaft

3
Logika biner sederhana dari api vs tetap dapat bekerja untuk komputer, tidak untuk orang-orang. Anda mungkin ingin memeriksa workplace.stackexchange.com untuk pertanyaan Anda begitu Anda merasa siap untuk mengatasinya di luar aspek Git.
Frank

Tunjukkan bahwa Git terlihat bagus di CV ;-)
Mawg

1
Ini benar-benar masalah manusia / psikologi, bukan masalah rekayasa perangkat lunak.
Jesper

@Jesper, ya dan tidak. Saya akan meletakkannya di tempat kerja tetapi melihat potensi untuk beberapa saran khusus Git (yang saya terima!) Yang mungkin langsung berlaku.
Gusdor

Jawaban:


148

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.


36
Saya suka jawaban ini, tetapi menurut saya itu menimbulkan pertanyaan lain: bagaimana Anda memotivasi mereka untuk bermain dengan mainan itu ketika mereka "terlalu sibuk melakukan pekerjaan nyata"?
David Arno

18
Beri mereka kredit untuk melakukannya jika Anda harus. Bagikan sertifikat "Git terkualifikasi" jika Anda pikir Anda dapat menjualnya. Tapi serius, jika ini tidak menarik bagi mereka secara alami Anda memiliki masalah lebih besar maka Git. Semua pengembang harus dapat menggunakan alat pengembang.
candied_orange

48
@ Davidvido Beritahu semua orang untuk menghabiskan satu jam per hari untuk itu, terlepas dari pekerjaan lain. Atau bahkan dua jam. Mampu menggunakan kontrol sumber dengan benar sangat penting untuk sebuah proyek. Mempelajari alat-alat itu adalah "pekerjaan nyata".
coinbird

16
'bagaimana Anda memotivasi mereka untuk bermain dengan mainan itu ketika mereka "terlalu sibuk melakukan pekerjaan nyata"? '- Ini adalah pekerjaan nyata.
David

18
Saya bingung. Tidak ada yang menyebutkan xkcd wajib !
GnP

32

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.


8
Dia menggunakan alur kerja gitflow sehingga mengelola cabang tidak boleh dianggap sebagai topik lanjutan - itu adalah bagian dari perintah inti yang perlu dipahami pengembangnya. Git secara umum memperlakukan manajemen cabang sebagai sesuatu yang mendasar daripada canggih.
slebetman

5
@slebetman: Memberi nama tidak menjadikannya tidak terlalu rumit atau sulit.
Robert Harvey

3
Anda menyebutkan "menangani komit lokal" sebagai sesuatu yang dibutuhkan oleh pengguna yang lebih mahir. Secara teoritis mengelola versi di komputer Anda sendiri harus lebih rendah dalam skala kesulitan yang mengelola versi dalam repo jarak jauh, dibagi dengan coders lain.
Tulains Córdova

Mungkin jika Anda bekerja di suatu tempat yang memiliki manajer rilis penuh waktu maka Anda tidak perlu khawatir tentang cabang, tetapi di mana pun dev harus mendorong fitur ke cabang pengujian setiap siklus, menggabungkan perbaikan prioritas tinggi dari cabang pengujian ke cabang pengembangan cabang, dan melakukan rilis untuk produksi dari cabang pengujian.
Brian Gordon

@RobertHarvey: Bercabang tidak rumit atau sulit. Ini dasar. Alur kerja gitflow rumit dalam kasus sudut seperti rilis bugfix tetapi kasus penggunaan umum sederhana.
slebetman

28

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.


4
+1 untuk SoruceTree. Untuk proyek kuliah yang terdiri dari ~ 30 siswa, saya memimpin transisi dari Subversion ke Git menggunakan SourceTree. Orang-orang beradaptasi dengan cepat setelah mereka mempelajari dasar-dasarnya, dan kami memiliki banyak tautan ke dokumentasi. Saya juga mendorong untuk bereksperimen di cabang uji. Saya akan mengatakan sekitar 75% orang merasa nyaman menggunakannya pada akhir semester, dan beberapa bahkan sudah mulai menggunakan baris perintah.
Dewick47

5
Memberitahu dia untuk menggunakan GUI dia sudah mengatakan dia menggunakan tidak menjawab pertanyaan.
WGroleau

9
Posting asli diedit untuk memasukkan SourceTree yang digunakan setelah jawaban ini diposting.
Dewick47

7
Saya juga akan menyarankan GitKraken. Itu yang saya gunakan untuk memperkenalkan beberapa mitra proyek batu penjuru CS saya ke Git. Mereka mengambilnya dalam waktu 15 menit - sangat sederhana, dan memiliki antarmuka yang indah dan intuitif. Dan tidak, saya tidak dengan pemasaran GitKraken.
Chris Cirefice

2
git guidan gitkdatang dengan git sendiri, dan saya menemukan mereka jauh lebih mudah dipelajari daripada alat-alat baris perintah. Jika Anda secara alami berorientasi pada baris perintah, maka GUI sederhana sangat bagus untuk dasar-dasarnya, dan Anda dapat git rebasedan hal-hal yang lebih kompleks dari baris perintah.
Peter Cordes

25

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.


11
Mungkin benar, tetapi masalah dengan pendekatan ini adalah bahwa kebanyakan programmer tidak ingin menghabiskan waktu berhari-hari untuk memahami detail dari kontrol kode sumber mereka. Mereka hanya ingin itu berfungsi, sederhana. . IMO, git gagal dalam hal ini. Cukup sulit memahami bagaimana kode Anda yang sebenarnya bekerja mengkhawatirkan gumpalan.
user949300

1
Komentar Anda 100% benar, @ user949300, maka gurauan saya pada akhirnya tentang penggantian gitdengan beberapa porselen super untuk tidak digunakan git, secara efektif. OP perlu mengadopsinya (termasuk waktu yang terlibat) yang sesuai untuk bisnis mereka. Seperti yang saya tulis, saya tidak berhasil dengan pendekatan (atau lainnya) ini, untuk membuat semua orang "terlibat", tetapi tetap saja, jika saya (terpaksa) mencoba lagi, ini akan menjadi pendekatan saya lagi.
AnoE

1
Terus terang saya pikir Anda bisa mendapatkan cukup jauh dalam menggunakan git tanpa benar-benar mengerti cara kerjanya. Jika Anda tahu bercabang, tambahkan, dorong, dan tarik ada seperti 95% dari apa yang orang biasa akan gunakan.
Casey

6
@ user949300 "Days" tidak cocok dengan pengalaman saya dengan mempelajari Git sama sekali. Git memiliki beberapa dokumentasi terbaik yang pernah saya lihat di proyek apa pun. Anda dapat mengambil semua dasar-dasarnya dari menghabiskan satu jam membaca 3 bab pertama Pro Git , yang ditulis dalam format yang sangat mudah diakses dengan banyak diagram. "Bagaimana saya ___ dalam Git" yang cepat di Google hampir selalu menyediakan sisanya - biasanya dari jawaban Stackexchange.
Jon Bentley

1
@Gusdor et al, perlu diingat bahwa jawaban ini khusus untuk pertanyaan ini - bagaimana membuat pemrogram senior tertarik untuk belajar tentang git. Jelas, semua sumber daya lainnya (dokumentasi git yang sangat baik, tutorial, dll.) Juga berlaku. Gusdor, jika Anda ingin tahu lebih banyak, google "objek git" atau "struktur data git" dan Anda akan segera menemukan banyak informasi. Saya telah menambahkan beberapa tautan dalam jawabannya. Anda bahkan mungkin meminta salah satu senior untuk membuat sesi brownbag tentang hal itu. ;)
AnoE

14

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.


1
"Siapa yang benar-benar membaca manual pengguna?" Saya merasa seperti ini mungkin merupakan ekspektasi yang masuk akal dari pengembang junior terbaru, tapi saya pikir salah satu keterampilan yang harus dipelajari pengembang dari waktu ke waktu adalah membaca dokumentasi. Ini adalah keterampilan yang harus dikembangkan, karena bahasa dokumentasi tidak sama dengan bahasa tutorial atau lebih banyak konten teknis biasa, dan karena tidak selalu jelas bagaimana berbagai bagian dokumentasi berinteraksi satu sama lain. Ini seharusnya tidak menjadi masalah dengan "beberapa insinyur 'lebih berpengalaman'".
Joshua Taylor

2
Tautan entri blog Anda memberi saya video YouTube yang tidak terkait.
WGroleau

2
Saya menemukan git statussangat penting, selain empat perintah yang Anda catat.
user949300

1
@ JoshuaTaylor Saya tidak bermaksud mengatakan bahwa manual itu buruk, mereka sebenarnya hebat. Namun, bayangkan merujuk seseorang ke man git dan hanya mengatakan; ayolah, mudah dipelajari, cukup baca halaman manual. Maksud saya bukan bahwa dokumentasi itu tidak bagus, banyak yang ditulis tanpa cela dan bermanfaat bagi orang-orang yang mengetahui domain tempat ditulisnya, tetapi itu biasanya tidak berguna bagi seseorang yang mencari penggunaan dasar. EDIT : Dan poin terakhir itu tampaknya adalah masalah yang dimiliki OP.
Robzor

@ user949300 Bagus, saya sangat setuju.
Robzor

11

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:

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


2
+1 untuk menyebutkan alternatif Gitflow. Dalam pengalaman saya, banyak penderitaan datang dari toko-toko dev mencoba mengadopsinya ketika itu berlebihan untuk kebutuhan mereka dan / atau tidak menggunakannya dengan benar. Model yang lebih sederhana hampir selalu lebih baik dalam kasus-kasus itu dan memiliki manfaat tambahan membuat Git jauh lebih mudah dipelajari.
Thunderforge

5
@Thunderforge, saya tidak setuju dengan menyebutnya "berlebihan," karena ini menunjukkan itu entah bagaimana lebih kuat atau fleksibel atau dalam beberapa cara menguntungkan. Saya benar-benar tidak percaya bahwa Gitflow memiliki kelebihan. Tampaknya menjadi langkah mundur: mencoba mengambil alur kerja kompleks yang diperlukan dalam alat kontrol versi lain seperti SVN dan hanya menggunakan Git dengan cara yang sama. Git memiliki fleksibilitas untuk memungkinkan alur kerja yang lebih sederhana. Saya pikir daya tariknya adalah memberikan ilusi karena harus berpikir lebih sedikit (aturan dan instruksi) tanpa memberikannya. Tapi maksud Anda diambil. Terima kasih.
jpmc26

4
Saya setuju dengan pendekatan Anda. Kami mengonversikan ke Git dari SVN belum lama ini. Kami memberikan daftar perintah yang harus mereka gunakan, daftar perintah yang TIDAK HARUS mereka gunakan tanpa bantuan, dan daftar perintah yang TIDAK AKAN PERNAH mereka gunakan (setidaknya bukan tanpa bantuan dari pakar Git setempat). Kami memberikan beberapa pelatihan tentang dasar-dasar cara kerja Git dan cara menggunakannya. Selama beberapa bulan, tim kami perlahan mulai terbiasa. Sekarang kami hanya memiliki masalah sesekali dengan devs yang bingung.
Kyle A

1
@ Goddor Pertanyaan Anda mengatakan "sedang transisi." Apa artinya? Juga, jika Anda tidak membeli, Gitflow tidak mungkin berhasil karena beratnya sangat, apakah Anda pikir itu memiliki kelebihan atau tidak.
jpmc26

2
@ Goddor Nasihat saya kepada Anda adalah bahwa Anda mungkin perlu mengembangkan keterampilan mengajar Anda. Anda perlu menjadi lebih baik dalam mengidentifikasi akar penyebab dari kesalahpahaman atau informasi yang hilang. Anda harus bisa mencari tahu di mana alasan seseorang salah. Untuk menulis dokumentasi, Anda tidak hanya perlu bisa menarik keluar dari seseorang, Anda juga harus dapat mengantisipasi di mana orang akan bingung atau apa yang akan membuat mereka menyerah ketika mencoba menggunakannya.
jpmc26

11

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.


Tautan yang bagus. Saya akan mencuri gambar Data Flow itu!
Gusdor

9

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.


6
Pro Git jelas merupakan salah satu yang akan digunakan untuk IMO. Anda bisa mendapatkannya gratis dari situs web Git . Tidak perlu membayar untuk itu kecuali Anda benar-benar menginginkan salinannya.
Jon Bentley

4

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 ...


4

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 sangat merekomendasikan orang-orang mengingat bahwa kebanyakan pengembang tidak bodoh dalam hal teknis. Buang saja itu sebagai alasan sampai tidak ada penjelasan lain.

^ dan menjadi lebih mudah dipekerjakan, yang merupakan sesuatu yang mungkin tidak dipikirkan oleh para lansia, terutama mengingat usia yang lazim di industri kita.


3

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.


2

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.


1
+1 Lainnya bahwa topik-topik yang sangat maju seperti memetik dan reberi ceri (ilmu roket untuk saya), belajar dengan baris perintah adalah saran yang benar-benar masuk akal. Ini satu-satunya cara untuk benar-benar belajar Git. Anda pertama kali belajar HTML sebelum menggunakan Dreamweaver, kan? Saya akan membuat beberapa alias ke perintah paling umum di depan bisa pergi. Misalnya perintah Log adalah Bizantium dan Arcane, cukup buat alias untuk mereka yang mencetak riwayat yang bagus.
Tulains Córdova

7
Saya sangat tidak setuju. Pandangan DAG sejauh ini merupakan alat yang paling penting untuk memahami apa yang terjadi. Tampilan yang hanya akan datang dari GUI.
Esben Skov Pedersen

1
git log --graph --abbrev-commit --decorate --date=relative --all
Jeremy French

1
git guidan gitkdatang dengan paket git utama, dan jangan mencoba membuat git terlihat seperti yang lainnya. Mereka sangat baik, terutama gitk --alluntuk melihat semua cabang, dan untuk mengatur ulang cabang saat ini untuk menunjuk ke komitmen lain, atau hal-hal seperti itu. Di gitk, "cherry-pick" adalah salah satu opsi yang Anda dapatkan saat mengklik kanan komit. Ini menggunakan terminologi yang sama dengan alat baris perintah.
Peter Cordes

3
@JeremyFrench ASCII art bukan cara yang sangat berguna untuk melihat grafik serumit git repo.
jpmc26

2

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.


1

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.


1
Ini adalah ide yang sangat menarik, tetapi saya harus bertanya-tanya - jika Gitless tidak benar-benar sederhana (dan apa itu?), Maka investasi untuk mempelajarinya mungkin membuang-buang waktu. Anda mungkin juga melakukan sedikit usaha ekstra untuk belajar git, yang akan menjadi keterampilan yang lebih fleksibel dan berharga. Mungkin jika kita bisa meyakinkan Torvalds, Hamano, dkk. untuk mengintegrasikan antarmuka Gitless, maka kita akan benar-benar memiliki sesuatu.
Cody Grey

Yah, sesederhana yang akan Anda dapatkan dalam lingkup porselen yang kompatibel dengan Git. Semua perintah yang biasa adalah operasi tunggal dengan nama yang berbeda dan tidak ada argumen yang diperlukan.
David Heyman

0

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.


0

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.


0

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.


1
Alasan untuk beralih ke Git adalah: 1. Saran dan dokumentasi komunitas 2. Kompatibilitas alat yang luas 3. Tidak ada kunci vendor. Kami telah membangun pipa perkakas (sebagian besar jira> bitbucket> bambu) yang memberlakukan peninjauan kode dan pengujian unit sebelum reintegrasi. Apa yang memberi Anda pandangan bahwa kami adalah koboi?
Gusdor

@Gdor karena GIT dibuat untuk organisasi tanpa kendali pusat, misalnya koboi .....
Ian

Dari badan pertanyaan: "Kami menggunakan model Git Flow terpusat ..."
Gusdor

1
Itu poin yang menarik. Ketika saya pertama kali dipekerjakan, VCS meledak dan saya diminta pendapat saya tentang penggantian. Saya memilih SVN karena saya berasumsi GIT tidak dapat digunakan secara terpusat. Tidak yakin banyak dari orang kami yang menelusuri SO: O
Gusdor

1
@Ian Dengan alasan ini, semua pengguna internet memajukan kepentingan militer AS karena proto-Internet pada awalnya dibuat oleh dan untuk militer (DARPA). Juga siapa pun yang memakai sepatu tali velcro jelas adalah NASA karena velcro diciptakan untuk aplikasi zero-G.
maple_shaft
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.