Dari Git SCM Book :
Seringkali, ketika Anda sedang mengerjakan bagian dari proyek Anda, banyak hal berada dalam keadaan berantakan dan Anda ingin berganti cabang sedikit untuk mengerjakan sesuatu yang lain. Masalahnya adalah, Anda tidak ingin melakukan komitmen pekerjaan setengah jadi hanya agar Anda bisa kembali ke titik ini nanti. Jawaban untuk masalah ini adalah perintah git stash.
Stashing mengambil kondisi kotor dari direktori kerja Anda - yaitu, file yang Anda lacak yang dimodifikasi dan melakukan perubahan - dan menyimpannya di tumpukan perubahan yang belum selesai yang dapat Anda aplikasikan kembali kapan saja.
Dengan uraian ini, saya akan mengatakan ini adalah Pola Anti. Penjelasan Git Stash yang terlalu disederhanakan adalah bahwa itu adalah "Potong dan Tempel" dari kontrol sumber. Anda mengambil banyak file yang diubah, "menyimpannya" dalam pena di luar alur kerja percabangan normal Git, dan kemudian mengajukan kembali perubahan itu ke cabang lain di kemudian hari.
Kembali sedikit lebih jauh, berkomitmen untuk menguasai adalah pola anti di sini. Gunakan cabang. Untuk itulah mereka dirancang.
Ini benar-benar bermuara pada ini:
Anda dapat memalu sekrup ke dinding dan itu akan menahan gambar, tetapi menggunakan obeng adalah apa yang harus Anda lakukan. Jangan gunakan palu saat obeng duduk tepat di samping Anda.
Tentang Komit "Rusak" Kode
Sementara berikut ini adalah opini, saya sampai pada pendapat ini dari pengalaman.
Berkomitmen awal, dan komit sering. Komit sebanyak mungkin kode yang Anda inginkan. Lihat riwayat komit lokal Anda sebagai "save points" saat Anda meretas sesuatu. Setelah Anda melakukan pekerjaan logis, buatlah sebuah komit. Tentu itu bisa menghancurkan segalanya, tapi itu tidak masalah selama Anda tidak mendorong komitmen itu. Sebelum mendorong, rebase dan remas komit Anda.
- Buat cabang baru
- Hack hack hack
- Komit kode yang rusak
- Memoles kode dan membuatnya berfungsi
- Komit kode kerja
- Rebase dan Squash
- Uji
- Dorong ketika tes lulus
Untuk OP, utas pesan kernal Linux ini mungkin menarik, karena kedengarannya seperti beberapa anggota tim OP menggunakan Git dengan cara yang sama.
@RibaldEddie mengatakan dalam komentar di bawah ini:
Pertama-tama, simpanan bukan di luar "alur kerja percabangan" karena di bawah kap simpanan hanyalah cabang lain.
(dengan risiko menimbulkan kemarahan banyak orang)
Linus berkata:
Dengan "git simpanan", Anda dapat memiliki beberapa hal simpanan yang berbeda juga, tetapi mereka tidak saling mengantri - mereka hanya tambalan independen acak yang Anda simpan karena mereka tidak nyaman di beberapa titik.
Apa yang saya pikirkan @RibaldEddie coba katakan adalah bahwa Anda dapat menggunakan git stash
alur kerja cabang fitur - dan ini benar. Bukan penggunaan git stash
itu masalahnya. Ini adalah kombinasi dari komitmen untuk menguasai dan menggunakan git stash
. Ini adalah pola anti.
Mengklarifikasi git rebase
Dari komentar @ RibaldEddie:
Rebasing jauh lebih mirip copy paste dan bahkan lebih buruk memodifikasi riwayat yang dilakukan.
(Penekanan milikku)
Memodifikasi riwayat komit bukanlah hal yang buruk, asalkan itu adalah sejarah komit lokal . Jika Anda rebase melakukan yang sudah Anda dorong, Anda pada dasarnya akan yatim piatu dengan orang lain menggunakan cabang Anda. Ini buruk.
Sekarang, katakan Anda telah membuat beberapa komitmen selama sehari. Beberapa komitmen bagus. Beberapa ... tidak begitu baik. The git rebase
perintah dalam hubungannya dengan meremas komit Anda adalah cara yang baik untuk membersihkan sejarah komit lokal Anda. Sangat menyenangkan untuk menggabungkan satu komit ke cabang publik karena menjaga komit sejarah cabang bersama tim Anda bersih. Setelah rebasing, Anda akan ingin menguji lagi, tetapi jika tes lulus maka Anda dapat mendorong satu komit bersih daripada beberapa yang kotor.
Ada thread Linux Kernel lain yang menarik tentang clean commit history .
Lagi, dari Linus:
Saya ingin membersihkan sejarah, tetapi itu benar-benar berarti (a) bersih dan (b) sejarah.
Orang dapat (dan mungkin harus) menumbuhkan pohon pribadi mereka (pekerjaan mereka sendiri). Itu pembersihan . Tapi tidak pernah kode orang lain. Itu adalah "menghancurkan sejarah"
Jadi bagian sejarahnya cukup mudah. Hanya ada satu aturan utama, dan satu klarifikasi kecil:
Anda tidak boleh pernah menghancurkan sejarah orang lain. Anda tidak boleh mengulangi komitmen yang dilakukan orang lain. Pada dasarnya, jika Anda tidak memiliki sign-off di atasnya, itu terlarang: Anda tidak dapat rebase, karena itu bukan milik Anda.
Perhatikan bahwa ini benar-benar tentang sejarah orang lain , bukan tentang kode orang lain . Jika mereka mengirim barang kepada Anda sebagai tambalan yang diemailkan, dan Anda menerapkannya dengan "git am -s", maka itu adalah kode mereka, tetapi ini adalah
riwayat Anda .
Jadi Anda bisa menjadi liar pada hal "git rebase" di atasnya, meskipun Anda tidak menulis kode, selama komit itu sendiri adalah milik pribadi Anda.
Klarifikasi kecil terhadap aturan: setelah Anda menerbitkan riwayat Anda di beberapa situs publik, orang lain mungkin menggunakannya, dan sekarang jelas bukan riwayat pribadi Anda lagi.
Jadi klarifikasi kecil sebenarnya adalah bahwa ini bukan hanya tentang "komit Anda", tetapi juga tentang kerahasiaan pada pohon Anda, dan Anda belum mendorongnya dan mengumumkannya.
...
Sekarang bagian "bersih" sedikit lebih halus, meskipun aturan pertama cukup jelas dan mudah:
Biarkan riwayat Anda sendiri dapat dibaca
Beberapa orang melakukan ini hanya dengan menyelesaikan masalah di kepala mereka terlebih dahulu, dan tidak membuat kesalahan. tapi itu sangat jarang, dan bagi kita semua, kita menggunakan "git rebase" dll ketika kita mengerjakan masalah kita.
Jadi "git rebase" tidak salah. Tapi itu benar hanya jika itu pohon git ANDA SANGAT SENDIRI.
Jangan biarkan omong kosong Anda.
Ini berarti: jika Anda masih dalam fase "git rebase", Anda tidak mendorongnya. Jika belum siap, Anda mengirim tambalan, atau menggunakan pohon git pribadi (seperti "pengganti rangkaian tambalan") yang tidak Anda beri tahu masyarakat luas.
(penekanan milikku)
Kesimpulan
Pada akhirnya, OP memiliki beberapa pengembang melakukan ini:
git checkout master
(edit files)
git commit -am "..."
(edit files)
git stash
git pull
git stash (pop|apply)
Ada dua masalah disini:
- Pengembang berkomitmen untuk menguasainya. Kunci ini segera. Sungguh, ini adalah masalah terbesar .
- Pengembang terus menggunakan
git stash
dan git pull
menguasai saat mereka harus menggunakan cabang fitur.
Tidak ada yang salah dengan menggunakan git stash
- terutama sebelum tarikan - tetapi menggunakan git stash
dengan cara ini adalah pola anti ketika ada alur kerja yang lebih baik di Git.
Mereka menggunakan git stash
herring merah. Bukan itu masalahnya. Berkomitmen untuk menguasai adalah masalahnya.