Apa manfaat dari proses komit dua-tahap git (staging)?

175

Saya belajar git dan saya perhatikan bahwa ia memiliki proses komit dua langkah:

git add <files>
git commit

Langkah pertama menempatkan revisi ke dalam apa yang disebut "area pementasan" atau "indeks".

Apa yang saya tertarik adalah mengapa keputusan desain ini dibuat, dan apa manfaatnya?

Juga, sebagai pengguna git apakah Anda melakukan ini atau hanya menggunakan git commit -a?

Saya menanyakan ini karena saya berasal dari bzr (Bazaar) yang tidak memiliki fitur ini.

version-control git workflows

— thomasrutter
sumber

3

+1 untuk ditanyakan. Saya menggunakan Tortoise SVN, yang memiliki pendekatan yang sama dan saya tidak pernah mengerti mengapa.

— DPD

3

Area pementasan tidak biasa. Setara dengan, katakanlah, TFS akan memeriksa atau menghapus centang kotak di sebelah file sebelum memeriksa. Hanya file yang dicentang yang dikomit. Perbedaannya dengan Git adalah bahwa jika Anda menggunakan git add -p, Anda dapat memilih untuk melakukan satu bagian file sementara tidak melakukan bagian lain dari file yang sama .

— Kyralessa

Saya menemukan bahwa tautan ini merangkum sebagian besar dari apa yang dijawab di sini dan menambahkan beberapa lagi kasus penggunaan untuk membenarkan perlunya pementasan.

— Veverke

2

Pertanyaan ini sebenarnya sudah dijawab, tetapi di sini juga ada satu penjelasan yang bagus: stackoverflow.com/questions/4878358/…

— guitar_freak

1

Jangan lupa git statusdan mungkin git push. Untuk semua hype tentang git, (dan kode berbagi GitHub luar biasa) bagian-bagiannya sangat mengganggu

— user949300

83

Pisahkan pekerjaan menjadi komit terpisah. Anda mungkin berkali-kali membuka file untuk menulis perbaikan satu baris, tetapi pada saat yang sama Anda melihat bahwa pemformatan itu salah, beberapa dokumentasi dapat diperbaiki, atau beberapa perbaikan yang tidak terkait lainnya. Dengan RCS lain Anda harus menuliskannya atau memasukkannya ke memori, menyelesaikan perbaikan yang Anda datangi, melakukan itu, dan kemudian kembali untuk memperbaiki hal-hal lain (atau membuat bola-of-lumpur melakukan dengan hal-hal yang tidak terkait) . Dengan Git Anda hanya memperbaiki semuanya sekaligus, dan stage + komit satu baris secara terpisah, dengan git add -iatau git-gui.

Jangan merusak bangunan. Anda sedang mengerjakan modifikasi yang rumit. Jadi Anda mencoba hal-hal yang berbeda, beberapa di antaranya bekerja lebih baik daripada yang lain, beberapa yang merusak hal-hal. Dengan Git Anda akan melakukan hal-hal ketika modifikasi membuat segalanya lebih baik, dan checkout(atau men-tweak lebih banyak) ketika modifikasi tidak bekerja. Anda tidak akan harus bergantung pada fungsionalitas pembatalan editor, Anda dapat checkoutseluruh repo bukan hanya file-per-file, dan kesalahan tingkat file apa saja (seperti menghapus file yang belum berkomitmen atau menyimpan + menutup setelah modifikasi buruk) tidak menyebabkan banyak pekerjaan hilang.

— l0b0
sumber

3

Berasal dari DVCS (bzr) yang tidak memiliki fitur ini, kedengarannya sangat mirip dengan apa yang saya capai saat ini dengan kombinasi penggunaan liberal dari "undo" buffer editor saya, perintah "kembalikan <file>" perintah dan selektif berkomitmen (" komit <file> "). Sepertinya fitur git ini berpotensi menjadi lebih metodis.

— thomasrutter

1

Mengenai "RCS lainnya", itu belum tentu benar. Bahkan, Anda dapat mencapai fungsionalitas yang sama di Mercurial menggunakan tambalan .

— Lucio Paiva

1

@ 10b0, tentang poin kedua Anda. Jika hanya ada satu komit tahap, Anda bisa saja melakukan perubahan (yang Anda gunakan dengan git add) secara langsung sebagai komit. Jika Anda mengetahui bahwa Anda melakukan kesalahan, Anda hanya akan menghapus komit, dan kembali ke tempat Anda sebelum membuat komit. Dengan konsep pementasan, bukan hanya Anda melakukan itu, tetapi menambahkan lebih banyak kompleksitas?

— alpha_989

Poin pertama Anda masuk akal, meskipun saya belum menggunakannya, sejauh ini. Secara teoritis mengapa Anda tidak bisa melakukan sesuatu seperti git add -ikomit dengan satu tahap? Anda hanya akan memilih banyak file (atau baris dalam file) yang terkait dengan fitur tunggal, dan melakukan komit. Kemudian Anda akan kembali dan melakukan komit kedua yang terkait dengan fitur lain ..

— alpha_989

@thomasrutter, Dari pernyataan Anda, tampaknya Anda menyarankan area pementasan membuat "manual membatalkan poin". Dalam VIM dengan persistent-undo, Anda bisa mendapatkan riwayat tak terbatas dengan sangat andal. Ini juga dilacak secara otomatis dalam git-branchjenis mode ( jovicailic.org/2017/04/vim-persistent-undo ). Selanjutnya riwayat undo Anda secara otomatis dilacak setiap kali Anda masuk ke mode normal. Jadi itu mengurangi beban mental Anda karena harus membuat "manual membatalkan poin". Mengapa menggunakan editor Anda "membatalkan" buffer tidak metodis?

— alpha_989

65

Salah satu manfaatnya bagi saya adalah kemampuan untuk "menambahkan" file secara progresif. Sebelum melakukan saya meninjau setiap file. Setelah file ditinjau, saya menambahkannya. Ketika saya git statusatau git diff, git hanya menunjukkan kepada saya file-file yang telah dimodifikasi dan belum ditambahkan. Ketika saya telah meninjau semua file dan menambahkannya, maka saya dapat melakukan.

Jadi ya, saya menemukan area pementasan sangat membantu.

Dan tidak, saya tidak pernah menggunakan git commit -a. Namun, saya sering menggunakannya git add -u. Dengan cara ini saya masih bisa memvisualisasikan apa yang harus dilakukan.

— David
sumber

2

Persis. Keuntungannya adalah kontrol berbutir jauh lebih baik atas apa yang Anda lakukan.

— Josh K

apa yang terjadi ketika Anda mem-stage satu file beberapa kali? apakah "digabung" di area pementasan?

— m4l490n

21

Manfaatnya cukup sederhana: ini memberi Anda kontrol penuh atas file mana yang ingin Anda komit. Untuk itu, Anda dapat menggunakan git add -puntuk mengontrol baris mana yang ingin Anda komit.

— Rein Henrichs
sumber

2

Saya selalu bertanya-tanya tentang bagaimana melakukan ini. Saya berharap ada file .gitignorelinessehingga Anda dapat membuat perubahan lokal pada setiap baris yang dapat bertahan dari komitmen, dan tetap utuh.

— alex grey

3

@ReinHenrichs, pikirkan file konfigurasi yang perlu diubah oleh setiap pengembang.

— Ian

1

@Ian Jadi bagian dari file itu jarang berubah dan dibagikan dan bagian dari file sering berubah, dengan cara yang tidak kompatibel, dan tidak dibagikan? Mendukung hubungan palsu ini jelas terdengar seperti fitur anti.

— Rein Henrichs

1

@ReinHenrichs, ya dan itu sangat umum ketika file berisi nama server database dan masing-masing pengembang memiliki database sendiri.

— Ian

4

@Ian Masalah Anda benar-benar ada, bahwa Anda memiliki file yang seharusnya merupakan konfigurasi untuk aplikasi juga mengandung beberapa konfigurasi spesifik mesin / dev. Semua sistem konfigurasi yang saya tahu memungkinkan Anda untuk membaginya menjadi beberapa file. Jadi misalnya Anda memiliki app.confyang berisi hal-hal yang ingin Anda bagikan, dan db.confyang baru saja Anda masukkan dalam daftar .gitignore. Masalah terpecahkan. Jika Anda menggunakan sesuatu yang berpemilik, Anda harus benar-benar mencari sesuatu yang sangat sederhana di sana. Atau letakkan melalui preprocessor dalam acara pra-bangun. Banyak solusi di sana.

— Aidiakapi

1

Salah satu manfaat yang saya sukai adalah kemampuan untuk melakukan sebagian perubahan. Yaitu., Dengan menggunakan git add -e. Saya tidak melakukan sesering seperti yang kadang-kadang saya lakukan, dan perintah git add -e memungkinkan saya mengurai perubahan saya sampai batas tertentu.

— leed25d
sumber