Bagaimana saya bisa meminimalkan sakit git ketika semua orang bekerja pada master?


123

Tim dokumentasi kami yang terdiri atas sepuluh orang baru-baru ini pindah dari SVN ke Git. Di SVN, semua orang bekerja pada master - model yang selalu saya benci, tapi saya tidak bisa membawa perubahan itu. Sebagai bagian dari perpindahan ke Git kami telah sepakat untuk memperbaikinya, tetapi kami belum bisa melakukannya dulu (menunggu perubahan build yang akan memungkinkan build dari cabang yang berubah-ubah). Sementara itu, semua orang bekerja pada master. Ya saya tahu ini mengerikan, percayalah.

Kami melihat lebih banyak cegukan sekarang daripada ketika kami menggunakan SVN, beberapa di antaranya disebabkan oleh model dua tahap Git (lokal dan jarak jauh). Kadang-kadang orang berkomitmen tetapi gagal mendorong, atau mereka menarik dan mendapatkan konflik dengan perubahan lokal mereka yang tertunda. Kemarin ada yang mengalami perubahan baru-baru ini - entah bagaimana - dengan penggabungan yang salah, yang saya pikir merupakan penggabungan yang dilakukan Git ketika Anda menarik dan memiliki perubahan yang luar biasa. (Dia belum bisa memberitahuku dengan tepat apa yang dia lakukan, dan karena dia menggunakan GUI, aku tidak bisa hanya memeriksa riwayat cangkangnya.)

Sebagai pengguna Git yang paling mahir (baca: Saya pernah menggunakannya sebelumnya, meskipun bukan untuk hal yang sangat rumit), saya adalah orang yang menetapkan kebijakan, mengajarkan alat, dan membersihkan kekacauan. Perubahan apa yang dapat saya lakukan untuk bagaimana kami menggunakan alat untuk membuat master yang aktif dan bersama lebih sedikit rawan kesalahan hingga kami dapat beralih untuk melakukan pengembangan di cabang?

Tim ini menggunakan Tortoise Git di Windows. Kami menggunakan Tortoise Git karena kami menggunakan Tortoise SVN sebelumnya. ( Saya pribadi menggunakan baris perintah di bawah Cygwin untuk beberapa operasi, tetapi tim telah menjelaskan mereka membutuhkan GUI dan kami akan menggunakan yang ini.) Jawaban harus bekerja dengan alat ini, bukan mengusulkan penggantian.

Tortoise Git memiliki "Komit & Dorong" tersedia sebagai operasi tunggal dan saya telah mengatakan kepada mereka untuk selalu melakukan itu. Namun, itu bukan atomik - bisa terjadi bahwa komit (yang setelah semua adalah lokal) berfungsi dengan baik tetapi dorongan tidak (katakanlah, karena konflik, atau masalah jaringan). Ketika itu terjadi, mereka mendapatkan kesalahan yang ambigu; Saya sudah mengatakan kepada mereka untuk memeriksa BitBucket log komit jika mereka memiliki setiap keraguan tentang baru-baru ini melakukan dan, jika mereka tidak melihatnya, untuk mendorong. (Dan untuk menyelesaikan konflik jika itu masalahnya, atau meminta bantuan jika mereka tidak tahu harus berbuat apa.)

Tim sudah memiliki kebiasaan baik "tarik lebih awal dan sering". Namun, tampaknya tarikan dapat menyebabkan konflik, yang saya pikir baru? Jika tidak baru, jauh lebih sering daripada di SVN. Saya pernah mendengar bahwa saya dapat mengubah cara Git menarik (rebase bukan penggabungan), tetapi saya tidak memiliki pemahaman yang baik tentang pertukaran di sana (atau bagaimana melakukannya di lingkungan kita).

Servernya adalah BitBucket (bukan Github). Saya memiliki kontrol administratif penuh atas repositori kami tetapi tidak ada di server yang lebih umum. Tidak ada yang bisa diubah.

File sumber adalah XML. Ada juga file grafik, yang semua orang tahu Anda tidak dapat menggabungkan, tetapi kami juga hampir tidak pernah memiliki tabrakan di sana. Konflik gabungan berasal dari file XML, bukan grafik.

Perubahan apa yang dapat saya lakukan pada penggunaan Git untuk membuat master berbagi berjalan lebih lancar bagi tim hingga kami dapat beralih menggunakan cabang fitur dengan permintaan tarik yang ditinjau, divalidasi uji?


52
Jangan gunakan kura-kura, gunakan Git Extensions. Tortoise mencoba menyembunyikan bahwa Git bukan SVN dan menghancurkan sebagian besar kehebatan git. Saya telah melewati transisi SVN-> Git dua kali, dan Git Extension adalah alat yang hebat untuk membuat orang berpikir dengan cara git.
Wilbert

91
Git bukan SVN. Jika Anda mencoba untuk mereplikasi SVN dengan Git, Anda hanya mendapatkan semua poin rasa sakit dari SVN dengan semua poin rasa sakit dari Git digabungkan, dengan tidak ada manfaat dari keduanya, itu tidak akan pernah berhasil. Masalah terbesar yang Anda miliki adalah masalah sosial, Anda memiliki anggota tim yang menolak untuk mempelajari konsep baru. Anda tidak dapat menyelesaikannya dengan solusi teknis, Anda harus mulai dengan membeli pembelian dari anggota tim Anda untuk mempelajari konsep Git daripada mencoba meyakinkan mereka bahwa itu seperti SVN.
Lie Ryan

10
Saya tahu Anda mengatakan tidak akan merekomendasikan aplikasi lain, tetapi @Wilbert benar. TortoiseGit mencoba menyembunyikan sesuatu, yang sebenarnya membuatnya lebih menyakitkan dalam pengalaman saya. Jika UI diinginkan, saya telah menemukan transisi termudah (baca: Saya melatih tim perangkat lunak non-tradisional pada tooling dan DevOps) telah melalui SourceTree dari Atlassian (tentu saja dengan pelatihan yang tepat). Saya juga menggunakan GitFlow untuk membantu mereka memahami model Git (meskipun, ini tidak cocok untuk semua tim).
JasCav

28
Saya agak terkejut semua orang poo-pooing bekerja pada master, yang merupakan prinsip utama dari Integrasi Berkelanjutan . Selama Anda memiliki rangkaian uji yang kuat dan semua orang sadar ketika bangunan rusak, bekerja dari master dapat menguntungkan untuk kolaborasi tim. Percabangan fitur (yang cukup banyak bergantung pada semua alur kerja lainnya) dapat sama-sama merusak tanpa perlindungan di tempat. Anda mungkin memiliki beberapa masalah root yang lebih dalam di sini.
DanK

14
@DanK, saya juga berpikir op salah mengidentifikasi akar masalah. Jika Anda memiliki orang-orang yang melakukan perubahan pada master dan Anda beralih ke cabang, Anda akan memiliki orang-orang yang melakukan perubahan pada cabang. Jika Anda pindah ke cabang individu, Anda akan memiliki orang-orang yang memiliki masalah penggabungan di cabang mereka (atau yang berkembang di cabang mereka tanpa bergabung selama berbulan-bulan di akhir).
user3067860

Jawaban:


11

Sejauh ini SourceTree adalah IDE terbaik untuk mempelajari konsep-konsepnya, karena ia memperlihatkan semua dialog dan opsi yang relevan yang Anda miliki di setiap tahap, opsi default biasanya baik-baik saja, jangan dipusingkan dengan rebase, dll. Cukup ikuti aliran normal:

  • Tarik dari master, hanya untuk memastikan Anda up to date
  • Ubah file Anda
  • Komit perubahan Anda (itu hanya lokal)
  • Tarik lagi dari master (ini akan menyebabkan konflik muncul)
  • Edit semua file sampai konflik terselesaikan, artinya file tersebut dalam status layak yang ingin Anda komit (tidak <<<<< KEPALA dan >>>> pesan utama dalam file mentah)
  • Melakukan perubahan gabungan
  • Dorong

Jika semua orang mengikuti resep ini, mereka akan baik-baik saja.

Setiap kali seseorang melakukan perubahan yang lebih besar atau terpusat, beri tahu pengguna lain untuk melakukan secara lokal dan menarik dari master, sehingga mereka tidak mendapatkan terlalu banyak konflik di kemudian hari dan orang pertama masih ada untuk menyelesaikan konflik bersama dengan mereka.

Investasikan banyak waktu untuk membuat semua orang memahami alurnya, jika tidak mereka akan berkeliling sebentar dan kemudian merasa nyaman dengannya benar-benar mengacaukan cabang utama, misalnya "menggunakan file saya alih-alih jarak jauh" untuk menyelesaikan konflik hanya akan menendang keluar semua perubahan yang dilakukan oleh orang lain.

Git adalah sistem yang sulit dipelajari, terutama jika Anda tumbuh dengan Svn, bersabar dan beri mereka waktu untuk mempelajarinya dengan baik, dengan pengguna baru Anda kadang-kadang dapat menghabiskan satu hari membersihkan kekacauan, itu normal. ;)


9
nitpick: SourceTree bukan Lingkungan Pengembangan Terpadu ...
Mathieu Guindon

Saya punya seseorang (selain saya) yang sedang menguji alur kerja ini sekarang (dengan Tortoise Git, maksud saya) untuk menghilangkan kejutan / masalah. Dengan asumsi tidak ada, saya berencana untuk meluncurkan ini ke tim dalam beberapa hari.
Monica Cellio

Saya tahu bahwa jawaban yang sangat penting ini mencakup banyak wilayah yang sama dengan yang ini, tetapi tidak sampai saya melihat resep yang dijabarkan selangkah demi selangkah dalam jawaban ini sehingga saya benar-benar mengerti bagaimana cara menerapkannya, jadi saya Saya menerima yang ini (untuk resep, bukan IDE :-)). Kami telah mengikuti proses ini selama beberapa hari sekarang tanpa masalah lebih lanjut. Kami juga akan lebih fokus mengeksplorasi dan memahami "cara git".
Monica Cellio

99

Ada tiga hal utama yang perlu diingat ketika Anda bekerja di cabang yang sama dengan orang lain:

  • Jangan pernah gunakan --forcekecuali Anda benar - benar tahu apa yang Anda lakukan.
  • Entah commitatau stashpekerjaan Anda sedang berlangsung sebelum setiap pull.
  • Biasanya berjalan lebih mudah jika Anda pulltepat sebelum a push.

Selain itu, saya akan menunjukkan bahwa dengan kontrol versi terdistribusi tidak masalah apakah repo "resmi" Anda menggunakan cabang atau tidak. Itu tidak ada kaitannya dengan apa yang dilakukan pengguna individu di repo lokal mereka. Saya dulu menggunakan git untuk mendapatkan cabang lokal ketika perusahaan saya menggunakan VCS pusat yang sama sekali berbeda. Jika mereka membuat cabang lokal untuk fitur mereka dan membuat kesalahan penggabungan ke lokal mereka master, itu jauh lebih mudah untuk diperbaiki tanpa masuk ke reflog atau sihir lainnya.


51
Selalu pullsebelumnya pushadalah nasihat yang bagus, tetapi saya akan melangkah lebih jauh dan menyarankan agar Anda mempertimbangkan apakah Anda bisa melakukannya pull --rebaseketika Anda melakukannya.
anaximander

20
@anaximander, saya akan merekomendasikan bahwa semua orang menggunakan --rebase atau tidak ada ...
keuleJ

12
@TemporalWolf Itulah yang mereka katakan tentang kue itu juga ...
BlackVegetable

15
@anaximander "maka Anda tidak menyelesaikan konflik, dan Anda Melakukannya Salah. Dalam kasus ini, mereka tidak dapat dipercaya dengan rebase". Jadi Anda mengatakan Anda tidak pernah sekalipun, mengacaukan konflik gabungan? Harus bagus bekerja pada basis kode yang cukup sederhana sehingga Anda dapat membuat generalisasi itu. Inilah pendapat Linus tentang rebase, yang menurut saya pribadi cukup menyenangkan daripada pendekatan hitam putih mana pun.
Voo

10
"Jangan pernah gunakan --forcekecuali kamu benar-benar tahu apa yang kamu lakukan." Saya akan melangkah lebih jauh. Larang penulisan ulang riwayat dalam repositori "utama" dari semua orang kecuali orang yang paling tepercaya. Apakah Anda dapat melakukan itu setidaknya sebagian tergantung pada hosting Anda, tetapi BitBucket memiliki opsi.
jpmc26

68

Apakah mungkin untuk mengambil satu hari bagi semua orang untuk belajar git?

Para profesional yang menggunakan komputer harus benar-benar diharapkan untuk mempelajari alat baru dan walaupun dimungkinkan untuk membuat banyak kesalahan dalam VCS apa pun, mereka harus menggunakan alat tersebut karena dirancang untuk digunakan.

Cara terbaik untuk memperkenalkan ini adalah dengan membuat setiap orang bekerja di cabang mereka sendiri ketika mereka membuat perubahan (sesingkat mungkin) dan rebase kemudian bergabung kembali menjadi master ketika mereka selesai. Ini tidak terlalu jauh dari cara kerja saat ini dan memperkenalkan alur kerja sederhana yang dapat mereka gunakan sampai mereka merasa cukup percaya diri untuk melakukan operasi yang lebih rumit.

Saya tidak menggunakan windows tetapi jika Tortoise pada dasarnya menyembunyikan git dari mereka dan berpura-pura itu SVN maka mungkin Tortoise adalah alat yang salah.


37
"Jika Tortoise pada dasarnya menyembunyikan git dari mereka dan berpura-pura itu SVN, maka mungkin Tortoise adalah alat yang salah." ini. Saya tahu OP mengatakan untuk tidak mengganti alat tetapi jika itu mengaburkan cara kerja git dengan cara apa pun maka itu merugikan pertumbuhan pribadi pengembang Anda dan efisiensi operasional Anda. Tim Anda akan terus menyalahgunakan VCS Anda jika mereka tidak memahaminya.
2rs2ts

3
Sumber belajar git lain yang bermanfaat adalah Learn Git Branching . Ini menunjukkan pohon visual dan juga memiliki kotak pasir sehingga Anda dapat mengejek sekelompok perintah dan melihat seperti apa hasil pohon.
TemporalWolf

4
Butuh waktu lebih lama daripada sehari bagi semua orang di tim dev untuk belajar git (dan mereka tidak redup atau malas), jadi saya berasumsi itu juga berlaku untuk tim dokter. Saya akan melihat situs-situs yang disebutkan di sini dalam komentar (mungkin mereka seharusnya ada di jawaban ini atau yang lain?).
Monica Cellio

3
Anda tidak akan belajar git sampai Anda melakukan semua kesalahan dan mengalami kesusahan dari penggabungan dan rebound yang saling bertentangan, mereka hanya perlu mempelajari aliran singkat di atas dari membuat cabang, memundurkan cabang itu untuk memasukkan perubahan apa pun dari master dan menggabungkan cabang mereka kembali menjadi master. Pembelajaran lain yang dapat mereka lakukan ketika mereka mencoba untuk menyelesaikan rasa sakit yang mereka hadapi dalam aliran ini (akan ada beberapa). Setidaknya tim dokter tidak memiliki masalah melanggar basis kode.
MarkJL

1
@ 2rs2ts Tortoise Git adalah git gui yang luar biasa. Saya menginstalnya di semua kotak windows saya dan saya sangat akrab dengan baris perintah git. Mergetool adalah salah satu yang terbaik yang pernah saya gunakan. Saya telah memperkenalkan banyak pengguna pemula untuk git menggunakan Tortoise Git. Masalah terbesarnya adalah memaparkan beberapa opsi git canggih hanya dengan kotak centang sederhana. Jadi opsi seperti - push paksa bisa dilakukan dengan hanya mencentang kotak di push gui. Ini mungkin apa yang dilakukan sehingga kehilangan pekerjaan. Saya tidak menggunakan banyak Tortoise tetapi ada beberapa hal yang membuatnya lebih sederhana.
gnash117

26

Terkadang, apa yang Anda lakukan harus berubah.

Masalah terbesar adalah bahwa setiap orang yang bekerja pada master. Ini bukan tipikal untuk pengembangan kode, dan bisa jadi model yang salah dalam kasus Anda juga. Jika Anda dapat mengubahnya, dengan meminta / mengharuskan perubahan dilakukan pada cabang terpisah, Anda akan berada dalam kondisi yang jauh lebih baik. Dengan cabang, Anda bisa mendapatkan yang berikut:

  • Menegakkan bahwa tidak ada dorongan langsung masterdiizinkan.
  • Terapkan melalui Bitbucket yang menarik permintaan dibuat dan memiliki setidaknya satu persetujuan sebelum penggabungan . Ini memastikan seseorang melihat perubahan, dan juga membuat penggabungan itu sendiri tidak terlalu menyakitkan, karena UI akan menunjukkan konflik terhadap versi kode yang jauh, bukan apa pun yang pengguna miliki di desktop. Ini mencegah skenario komit-berhasil-tapi-tekan-gagal.
  • Jalankan "builds" terhadap repo Anda sebelum bergabung. Saya menyadari ini adalah dokumen repo, tapi mungkin ada pemeriksaan ejaan, pengikisan legal, atau bahkan terjemahan otomatis (ekspor STRING_DEF hal ke file csv) yang dapat dibangun dari bangunan ini. Atau mungkin tidak, tergantung pada pekerjaan Anda.
  • Biarkan orang lain mengerjakan banyak hal berbeda secara lebih mudah. Ya ini bisa dilakukan dengan simpanan juga, tapi agak berantakan dan ada sesuatu yang memberitahu saya bahwa Anda juga tidak menggunakannya.

Jika Anda tidak dapat menggunakan percabangan, Anda dapat mempertimbangkan untuk menulis merge-and-pushskrip yang dapat mengotomatiskan beberapa titik sakit. Mungkin itu akan memeriksa bahwa pengguna tidak ketinggalan pada master, lakukan mengambil dan menarik, dan kemudian mencoba menggabungkan ( mungkin dengan--no-commit --no-ff ), dan seterusnya.


3
Kami akan pindah ke percabangan, untuk semua alasan yang Anda sebutkan (tetapi terutama PR yang terkontrol dan kemampuan untuk mengamanatkan bahwa konflik diselesaikan di cabang sebelum bergabung). Bisakah Anda mengatakan lebih banyak tentang cara menyerang skrip gabungan dan tekan?
Monica Cellio

6
Saya tidak setuju dengan saran ini. Cabang fitur yang berjalan lama bisa jauh lebih menghancurkan daripada bekerja dari master (yang jika Anda tidak memiliki alur kerja yang baik di tempat adalah apa yang akan terjadi). Martin Fowler memiliki artikel yang bagus tentang topik ini. Pada akhir hari itu, tim OPs memiliki masalah kolaborasi alur kerja bukan masalah Git .. Saya berpendapat bahwa lebih banyak cabang hanya akan menambah masalah ini.
DanK

6
Cabang fitur yang sudah berjalan lama bukan yang saya advokasi (atau disebutkan). Saya setuju mereka buruk untuk pengembangan "biasa", dan tidak akan lebih baik di sini. Cabang reguler, "ravioli" dengan sejumlah kecil perubahan yang dapat ditinjau / diuji sebelum penggabungan sangat berguna, dan akan sangat bermanfaat di sini hanya karena itu adalah repo dokumentasi untuk semua alasan yang dijabarkan dalam jawaban.
Dan1701

3
Tentu, saya mengerti apa yang Anda katakan dan saya tidak setuju secara teori tetapi dengan masalah kolaborasi saat ini sedang dijelaskan di sini, bahkan dengan niat terbaik, saya pikir cabang tim OP semua akan secara tidak sengaja berubah menjadi cabang yang sudah berjalan lama. Pada akhirnya, bekerja pada cabang arus utama vs. fitur bukanlah masalah utama di sini. Masalahnya adalah kurangnya pemahaman tentang seluk beluk VCS yang didistribusikan dan kurangnya kolaborasi / kohesi di antara para pengembang. Fitur percabangan dengan sendirinya tidak akan memperbaikinya tetapi IMO memperburuknya.
DanK

2
Kami hampir perlu memindahkan ini untuk mengobrol, tetapi, jika Anda selalu menggunakan cabang fitur maka Anda tidak menyelesaikan pekerjaan Anda. Mereka harus digabung ke cabang yang dikirim (atau diterbitkan, dalam kasus ini). Ini memungkinkan pengenalan pemeriksaan otomatis dan perlindungan di sekitar masalah yang dialami tim mereka. Cabang fitur sepenuhnya berbeda dari bekerja pada master di sebagian besar alat (setidaknya Bitbucket) disusun untuk memungkinkan permintaan tarik dengan persetujuan yang diperlukan dan pra-penggabungan bangunan sebagai bagian dari model percabangan, yang bukan sesuatu yang terjadi ketika hanya bekerja pada master.
Dan1701

12

Tekankan bahwa Anda dapat mengulang penggabungan

Mungkin sudah jelas bagi Anda, tetapi mantan pengguna SVN mungkin tidak sadar bahwa mereka dapat mencoba memecahkan penggabungan beberapa kali. Ini mungkin mengurangi jumlah bendera bantuan yang Anda terima.

Di SVN saat bekerja trunkAnda akan memiliki perubahan tanpa komitmen duduk-duduk. Maka Anda akan melakukan svn update. Pada titik mana perubahan Anda akan bercampur dengan perubahan orang lain selamanya. Tidak ada cara untuk membatalkannya (afaik), jadi Anda tidak punya pilihan selain memeriksa semuanya secara manual dan berharap repo dalam keadaan baik. Ketika Anda benar-benar akan jauh lebih nyaman hanya mengulangi penggabungan.

Orang-orang akan memiliki mentalitas yang sama bahkan ketika kami pindah ke git. Menyebabkan banyak kesalahan yang tidak disengaja.

Untungnya dengan git ada jalan kembali, khususnya karena Anda dapat membuat komitmen lokal. (Saya jelaskan nanti bagaimana ini diekspresikan dalam commandline)

Padahal cara ini dilakukan akan berbeda-beda berdasarkan tooling. Saya menemukan mengulangi tarikan bukanlah sesuatu yang terbuka di banyak GUI sebagai satu tombol tetapi mungkin saja. Saya suka Anda menggunakan cygwin. Rekan kerja saya menggunakan sourcetree. Karena Anda menggunakan BitBucket, masuk akal untuk menggunakannya sebagai GUI Anda karena dikelola oleh perusahaan yang sama: Atlassian. Saya menduga ada beberapa integrasi yang lebih ketat.

Mengenai tarikan

Saya pikir Anda benar bahwa penggabungan pulladalah apa yang mengacaukan orang. A pullsebenarnya git fetchyang mengambil perubahan dari server, diikuti oleh git merge origin/<branchname>* yang menggabungkan perubahan jarak jauh ke cabang lokal Anda. ( https://git-scm.com/docs/git-pull )

Hasilnya adalah semua perintah gabungan standar berfungsi dengan tarikan. Jika gabungan itu memiliki konflik, Anda dapat membatalkan git merge --abort. Yang seharusnya membawa Anda kembali ke sebelum bergabung. Kemudian Anda dapat mencoba lagi dengan salah satu git pullatau git merge origin/<branchname>.

Jika Anda entah bagaimana bisa belajar bagaimana melakukan hal di atas menggunakan alat pilihan GUI rekan kerja Anda, saya pikir itu akan menyelesaikan sebagian besar masalah Anda. Maaf saya tidak bisa lebih spesifik.

* Saya mengerti bahwa asal tidak selalu terjadi di sini.

Gunakan git refloguntuk mendiagnosis masalah

Saya, seperti Anda, harus mendiagnosis masalah yang sebagian besar disebabkan oleh penyalahgunaan alat GUI. Saya menemukan bahwa git reflogkadang-kadang bisa membantu karena itu adalah jejak tindakan yang cukup konsisten pada repositori. Meskipun terkadang sulit dibaca.

Sebuah alternatif

Karena situasi Anda bersifat sementara , Anda bisa kembali ke SVN sampai Anda memiliki proses untuk memulai. Saya akan ragu untuk melakukan ini karena banyak tempat akan mengatakan 'Kami mencoba git sekali tetapi tidak berhasil ...' dan tidak pernah benar-benar mengambilnya kembali.

Beberapa masalah transisi umum lainnya

  • Orang-orang sering menghapus dan membatalkan repo mereka, karena yakin repo mereka berada dalam kondisi yang tidak dapat digunakan. Biasanya ini disebabkan oleh kehilangan jejak perbedaan lokal dan jarak jauh. Baik alat GUI dan CLI gagal menunjukkan ini dengan baik. Di CLI saya menemukan git log --decoratecara termudah untuk melihat perbedaan. Tetapi jika semuanya menjadi terlalu berbulu pada master (misalnya) Anda bisagit reset --hard origin/master

2
Pada poin terakhir Anda: Untuk gambaran struktural yang cepat dan nyata, saya menemukan yang git log --oneline --decorate --graphideal. Begitu banyak, bahwa saya telah menetapkan alias shell untuk kombinasi yang tepat.
cmaster

1
+1 untuk jawaban Anda, saya hanya menemukan alternatif yang disarankan buruk, karena alasan yang Anda sebutkan. Anda akan merasakan sakit bahkan jika Anda kembali ke SVN dan kemudian di masa depan pergi ke git. Orang-orang dalam tim hanya akan mempelajari alat baru, berbeda, dan menyakitkan jika mereka tidak memiliki pilihan lain. Hanya setelah penggunaan dan melakukan kesalahan bodoh mereka akan mulai menghargai apa yang bisa dilakukan git.
CodeMonkey

8

Salah satu mekanisme yang mungkin, yang telah diadopsi oleh banyak tim sumber terbuka, adalah dengan menggunakan model forking - https://www.atlassian.com/git/tutorials/comparing-workflows (pastikan untuk mengucapkan dengan jelas saat membahas alur kerja forking git) ) .

Dalam hal ini, setiap pengembang atau sub-tim memiliki garpu repositori yang mereka periksa sendiri dari BitBucket memang menyediakan mekanisme untuk ini , menetapkan asal "upstream" selain remote default - mereka harus ingat untuk "mengambil upstream "dan" gabungkan remote / hulu / master "secara teratur.

Ini mungkin akan menyelesaikan masalah mekanisme build Anda karena tool build mungkin akan diarahkan ke master pada proyek yang berbeda, yaitu fork.

Anda kemudian dapat menghapus dari kebanyakan orang kemampuan untuk mendorong langsung ke proyek master dan menjadikannya tim yang lebih kecil dari orang-orang dengan ulasan & menyetujui peran. Lihat https://www.atlassian.com/git/tutorials/making-a-pull-request

Tempat untuk membaca untuk memastikan bahwa hampir semua pemeriksaan yang diinginkan dilakukan sebelum dorongan ada di bagian buku git pada kait - https://git-scm.com/book/gr/v2/Customizing-Git-Git-Hooks - Anda dapat menggunakan kait pra-komitmen dan pra-dorong untuk melakukan hal-hal seperti menjalankan beberapa tes pada komit yang diusulkan untuk memastikan bahwa pekerjaan itu valid, dll. - satu-satunya masalah dengan kait sisi klien adalah bahwa pengembang dapat menonaktifkannya atau gagal mengaktifkan mereka.

Baik pengambilan / penggabungan hulu & kait tersedia di TortoiseGit.


Bukan ide yang buruk, sungguh. Sepertinya tim ini akan mendapat manfaat dari Merge Master sampai mereka merasa lebih nyaman. +1
Greg Burghardt

2
BitBucket memiliki fitur sinkronisasi garpu yang secara otomatis memajukan garpu fork bila memungkinkan. Sangat mudah untuk bercabang hari ini dan menarik dari asalnya minggu depan tanpa pernah khawatir tentang hulu.
piedar

3

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:

  • Ambil perubahan sebelum melakukan apa pun.
  • Buat keputusan bagaimana menangani perubahan yang diambil. Pilihannya adalah:

    • Komit perubahan lokal mereka, lalu rebase di atas perubahan yang diambil.
    • Komit perubahan lokal mereka dan kemudian lakukan penggabungan dengan perubahan yang diambil.
    • Simpan perubahan mereka, gabungkan, lalu lepaskan dan selesaikan konflik apa pun.

      Ada hal-hal lain, tetapi saya tidak akan membahasnya di sini. Perhatikan bahwa tarikan secara harfiah hanya mengambil dan menggabungkan. Itu tidak seperti mereka; itu adalah mereka. (Melewati --rebaseperubahan menarik dari fetch + merge ke fetch + rebase.)

  • Tahap perubahan mereka dan kemudian tinjau.
  • Komit perubahan bertahap mereka dan kemudian meninjau komit.
  • Dorong secara terpisah.

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

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


2

Saya telah melalui pengalaman SVN -> git yang sama persis di perusahaan saya dan dari pengalaman saya, satu-satunya obat adalah waktu. Biarkan orang terbiasa dengan alat, biarkan mereka membuat kesalahan, tunjukkan pada mereka cara memperbaikinya. Kecepatan Anda akan menderita untuk sementara waktu, dan orang-orang akan kehilangan pekerjaan, dan semua orang akan sedikit malas, tetapi itu adalah sifat dari mengubah sesuatu yang mendasar seperti VCS Anda.

Yang mengatakan, saya setuju dengan semua orang yang berpendapat bahwa TortoiseGit adalah penghalang, bukan bantuan, jadi di awal periode transisi. TortoiseGit adalah ... bukan GUI yang hebat di saat-saat terbaik, dan dengan mengaburkan bagaimana sebenarnya git bekerja atas nama kesederhanaan, itu juga mencegah rekan kerja Anda untuk mendapatkan pemahaman tentang konsep inti git seperti komit dua fase.

Kami membuat (agak drastis) keputusan untuk memaksa dev untuk menggunakan command-line (git bash atau posh-git ) selama seminggu, dan itu bekerja sangat baik untuk memahami bagaimana git benar-benar beroperasi dan bagaimana perbedaannya dari SVN. Mungkin terdengar drastis, tetapi saya sarankan Anda mencobanya hanya karena itu menciptakan pemahaman tentang model git - dan begitu mereka memilikinya, rekan kerja Anda dapat mulai menggunakan fasad GUI apa pun di atas git yang mereka sukai.

Catatan akhir: akan ada beberapa rekan kerja Anda yang grok cara git bekerja segera, dan akan ada beberapa yang tidak akan pernah. Kelompok terakhir, Anda hanya perlu mengajarkan mantra mistis untuk membuat kode mereka dari mesin lokal mereka ke server sehingga semua orang dapat melihatnya.


1

Nah, baru-baru ini saya mengadaptasi alur kerja berikut untuk tidak pernah menambah cabang master:

1) Setiap orang menggunakan cabang mereka sendiri, yang merupakan salinan asli dari cabang master.

Mari beri nama cabang master "master", dan cabang saya sendiri "my_master".

Saya baru saja membuat cabang dari master, jadi persis sama. Saya mulai bekerja pada fitur baru di cabang saya sendiri, dan ketika selesai saya lakukan yang berikut.

Currenly di cabang saya, baru saja selesai coding

git add . && git commit -m "Message" && git push

Kembali ke cabang utama

git checkout master

Tarik jika tidak up to date

git pull

Kembali ke cabang saya sendiri

git checkout my_master

Gabungkan master terbaru ke cabang saya sendiri

git merge master

Perbaiki konflik & penggabungan

Uji semuanya lagi

Ketika semuanya digabung & diperbaiki di cabang saya sendiri, dorong

git push

Kembali ke cabang utama

git checkout master

Bergabunglah dengan cabang saya

git merge my_master

Tidak mungkin memiliki konflik karena diselesaikan di cabang Anda sendiri dengan penggabungan sebelumnya

Dorong tuan

git push

Jika semua orang mengikuti ini, cabang master akan bersih.


0

Jadi kami memiliki tim yang beralih dari TFS ke git dan mempertahankan cara berpikir lama. Aturan umum operasi kurang lebih sama.

Ya, ini berarti semua orang bekerja pada master. Ini tidak terlalu buruk; dan tim yang terbiasa dengan TFS atau SVN akan menemukan ini paling alami.

Prosedur umum untuk membuat ini tidak menyakitkan mungkin:

  1. lakukan git stash && git pull --rebase && git stash popsetiap pagi
  2. melakukan lebih awal dan sering (tidak perlu mendorong segera; kita setidaknya bisa mulai mengambil keuntungan dari git awal)
  3. untuk mendorong lakukan loop berikut:

    git add git commit git pull --rebase fix any merges compile git push loop until you don't get the can't fast forward error message.


Jika Anda melakukan ini, Anda sebaiknya tetap menggunakan SVN. Dalam hal yang sama seperti Anda dapat tetap dengan kereta kuda di zaman mobil. Tentu saja, Anda dapat mengendarai mobil Anda dengan kecepatan yang sama seperti yang Anda bisa lakukan dengan kereta kuda. Tapi, semua yang Anda raih dengan ini adalah untuk menghalangi diri Anda sendiri, dan membuat orang-orang yang mampu mengendarai mobil marah kepada Anda. Belajar mengemudi mobil Anda. Sekarang.
cmaster

@ cmaster: Bagi kami keuntungan # 1 dari git adalah hilangnya server tidak kehilangan seluruh riwayat kendali sumber. (Itu terjadi pada kami - kami memiliki cadangan tetapi tape drive mulai memakan kaset ketika kami mencoba untuk mengembalikan.)
Joshua

@ cmaster: Kami sudah mulai memperkenalkan beberapa fitur git lain yang bermanfaat sejak itu, tetapi mengubah percabangan mungkin tidak akan digunakan.
Joshua

@ cmaster Perbedaan antara mengendarai mobil perlahan dan menunggang kuda adalah bahwa mengendarai mobil mempersiapkan Anda untuk mengendarainya lebih cepat. Menunggang kuda tidak. Tidak semua orang yang menabrak mobil perlu menekan gas untuk pergi 60 mph beberapa kali pertama mereka di dalamnya.
jpmc26

@ jpmc26 Ketika saya mengambil pelajaran mengemudi pertama saya, saya diminta untuk mengemudi 30 km / jam pasti, dan saya percaya bahwa pelajaran itu juga termasuk jarak pendek 50 km / jam. Itu jelas lebih dari sekadar kereta kuda biasa. Dan hal yang sama berlaku untuk git: Anda biasanya belajar bercabang dan bergabung sejak hari pertama. Itu bagian integral dari penggunaan git. Hindari itu, dan Anda menyalahgunakan alat dengan cara yang sama seperti Anda menyalahgunakan mobil saat melaju tidak lebih dari 15 km / jam.
cmaster

-3

Jika semua orang bekerja pada master, tidak ada yang bisa Anda lakukan. Hal-hal pasti akan kacau.

Anda harus menggunakan master untuk produk jadi yang dikirim ke pelanggan. Anda harus menggunakan pengembangan untuk pengembangan yang berkelanjutan, dan Anda tidak boleh membiarkan siapa pun mendorong pengembangan. Standarnya adalah bahwa setiap orang bercabang dari dev, membuat perubahan, mendorongnya dari lokal ke cabang mereka di server, dan mengeluarkan permintaan push. Kemudian seseorang meninjau perubahan dan menggabungkannya ke dalam pengembangan.

Untuk menghindari konflik, semua orang menggabungkan pengembangan ke cabang mereka sendiri sebelum mendorong, dan menyelesaikan konflik pada tahap itu (sehingga hanya mempengaruhi satu pengembang secara lokal). Jika penggabungan ke dalam pengembangan akan menyebabkan konflik, maka itu tidak digabung - pengembang menggabungkan pengembangan ke cabang mereka lagi, dan mendorong ke server lagi, dan kemudian ditinjau kembali.

Anda dapat menggunakan sourcetree misalnya untuk membuat ini bekerja tanpa rasa sakit.


4
Itu hanya mengganti "master" dengan "development", dengan risiko tambahan orang tidak beralih ke cabang development setelah checkout default. Saya lebih suka GitLab Flow , yang merupakan media bahagia antara GitFlow yang berat dan GitHub Flow yang jarang.
Cees Timmerman

@CeesTimmerman Jika Anda tidak menyukai Gitflow, Anda mungkin tertarik pada Oneflow juga.
jpmc26
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.