Git'in iki aşamalı taahhüt sürecinin (evreleme) faydası nedir?

174

Git öğreniyorum ve iki aşamalı bir taahhüt süreci olduğunu fark ettim:

git add <files>
git commit

İlk adım, "evreleme alanı" veya "dizin" olarak adlandırılan şeyin revizyonlarını yapar.

İlgilendiğim, bu tasarım kararının neden verildiği ve faydaları nelerdir?

Ayrıca, git kullanıcısı olarak bunu mu yapıyorsun yoksa sadece git commit -amı kullanıyorsun ?

Bunu, bu özelliği olmayan bzr'den (Bazaar) geldiğim için soruyorum.

version-control git workflows

— thomasrutter
kaynak

3

Sormak için +1. Aynı yaklaşıma sahip olan Tortoise SVN'yi kullanıyorum ve nedenini hiç anlamadım.

— DPD

3

Evreleme alanı sıradışı değil. Örneğin, TFS, eşdeğerini teslim etmeden önce bir dosyanın yanındaki kutuyu işaretler veya işaretini kaldırır. Git'in farkı, kullanırsanız git add -p, aynı dosyanın başka bir parçasını işlemeden bir dosya parçasını seçmeyi seçebilmenizdir .

— Kyralessa

Bu bağlantının burada cevaplananların çoğunu özetlediğini ve evreleme ihtiyacını haklı çıkarmak için birkaç kullanım örneği daha eklediğini gördüm .

— Veverke

2

Bu soru aslında zaten cevaplanmış, ancak burada da iyi bir açıklama var: stackoverflow.com/questions/4878358/…

— guitar_freak

1

Unutma git statusve muhtemelen git push. Git hakkındaki tüm yutturmaca, (ve GitHub paylaşım kodu harika) bölümleri çok can sıkıcı

— user949300

83

Çalışmayı ayrı taahhütlere ayırın. Muhtemelen birçok kez tek satırlı bir düzeltme yazmak için bir dosya açtınız, ancak aynı zamanda biçimlendirmenin yanlış olduğunu, bazı belgelerin geliştirilebileceğini ya da ilgisiz başka bir düzeltmeyi tespit ettiniz. Diğer RCS'lerde bunu yazmanız veya hafızaya vermeniz, geldiğiniz düzeltmeyi tamamlamanız, bunu taahhüt etmeniz ve sonra diğer şeyleri düzeltmek için geri dönmeniz (veya ilgisiz şeyler ile çamur topuzu oluşturma) gerekir. . Git ile hepsini bir kerede düzeltirsiniz ve stage + git add -iveya ile tek bir satırı ayrı ayrı işler git-gui.

Yapıyı bozma. Karmaşık bir değişiklik üzerinde çalışıyorsun. Böylece, bazıları diğerlerinden daha iyi çalışan, bazıları kırılan farklı şeyler denersiniz. Git ile, değişiklik işleri daha iyi hale getirdiğinde, checkout(ya da biraz daha ince ayar yaptığınızda) değişiklik işe yaramadığında işleri sahneye koyacaksınız . Editörün geri alma işlevine güvenmek zorunda kalmayacaksınız checkout, yalnızca dosyaya dosya yerine tüm depoya ve dosya düzeyindeki tüm hatalara (örneğin, kaydedilmemiş bir dosyayı kaldırma veya kaydetme + kapatma işleminden sonra) kötü değişiklik) çok iş kaybına neden olmaz.

— l0b0
kaynak

3

Bu özelliğe sahip olmayan bir DVCS'den (bzr) geliyor, editörümün "geri al" tamponlarının liberal kullanımı, "geri alma <dosyası>" komutunu ve seçici taahhütleri ("geri al" komutunun şu anda elde ettiklerime çok benziyor. taahhüt <dosya> "). Git'in bu özelliğine benziyorsa, daha metodik olma potansiyeli var.

— thomasrutter

1

“Diğer RCS'ler” ile ilgili olarak, bu kesinlikle doğru değildir. Aslında Mercurial'da aynı işlevleri yamalar kullanarak da yapabilirsiniz .

— Lucio Paiva

1

@ l0b0, ikinci puanınız için. Sadece tek bir aşamalı işlem olsaydı, değişiklikleri (git add ile birlikte kullandığınız) doğrudan bir taahhüt olarak kabul etmiş olabilirsiniz. Yanlış bir şey yaptığını öğrenmiş olsaydın, taahhüdü silmeliydin ve taahhüdü yapmadan önce bulunduğun yere geri dönecektin. Evreleme konseptiyle, sadece bunu yapmıyor musunuz, daha fazla karmaşıklık ekliyor musunuz?

— alpha_989

Şimdiye kadar kullanmadığım halde ilk noktanız mantıklı. Teorik olarak, neden git add -itek aşamalı bir taahhütle gibi bir şey yapamıyorsunuz ? Sadece tek bir özellik ile ilgili bir sürü dosya (veya dosyalar içindeki satırlar) seçer ve bir taahhütte bulunursunuz. O zaman geri dönüp başka bir özellikle ilgili ikinci bir iş yaparsınız ..

— alpha_989

@thomasrutter, İfadenize göre, evreleme alanının "manuel geri alma noktaları" oluşturduğunu öne sürüyorsunuz. Persent-undo özellikli VIM'de sınırsız tarihin güvenilir bir şekilde alınmasını sağlayabilirsiniz. Bu aynı zamanda otomatik olarak bir git-branchtür izlenir ( jovicailic.org/2017/04/vim-persistent-undo ). Ayrıca geri alma geçmişiniz, normal moda her girdiğinizde otomatik olarak izlenir. Bu nedenle “manuel geri alma noktaları” oluşturma zorunluluğunuzu azaltır. Editörlerinizi neden metodik değil “geri al” tamponlarını kullanıyorsunuz?

— alpha_989

65

Benim için yararlarından biri, dosyaları aşamalı olarak "ekleme" yeteneğidir. Taahhüt etmeden önce her dosyayı gözden geçiririm. Dosya incelendikten sonra ekliyorum. Ben git statusveya git diff, git bana yalnızca değiştirilmiş ve henüz eklenmemiş dosyaları gösterir. Tüm dosyaları inceledikten ve eklediğimde, o zaman kabul edebilirim.

Yani evet, evreleme alanını çok faydalı buluyorum.

Ve hayır, asla kullanmam git commit -a. Ancak, sıklıkla kullanıyorum git add -u. Bu şekilde, neyin taahhüt edileceğini hala görselleştirebiliyorum.

— David
kaynak

2

Kesinlikle. Bunun avantajı, tam olarak neyle uğraştığınızın üzerinde çok daha hassas bir kontrol.

— Josh K,

bir dosyayı birden çok kez açtığınızda ne olur? evreleme alanında "birleştirildi" mi?

— m4l490n

21

Avantaj oldukça basittir: ne zaman işlem yapmak istediğiniz konusunda tam kontrol sağlar. Bu konuda, git add -phangi hatları taahhüt etmek istediğinizi kontrol etmek için kullanabilirsiniz.

— Rein Henrichs
kaynak

2

Bunu nasıl yapacağımı hep merak etmişimdir. Keşke bir dosya olsaydı, .gitignorelinesböylece hayatta kalabilecek ve hatta kalabilecek münferit satırlarda yerel değişiklikler yapabilseydiniz.

— alex grey

3

@ReinHenrichs, her geliştiricinin değiştirmesi gereken yapılandırma dosyalarını düşünün.

— Ian,

1

@Ian Yani dosyanın bir kısmı nadiren değişir ve paylaşılır ve dosyanın bir kısmı sıklıkla, uyumsuz şekillerde değişir ve paylaşılmaz mı? Bu sahte bağlanma desteklenmesi kesinlikle bir anti-özellik gibi geliyor.

— Rein Henrichs

1

@ReinHenrichs, evet ve dosya veritabanı sunucusunun adını içerdiğinde ve her bir devin kendi veritabanına sahip olması çok yaygındır.

— Ian

4

@ Sizin probleminiz gerçekten orada, uygulamanın konfigürasyonu olması gereken bir dosyaya sahip olmanız da, ayrıca makineye / makineye özel bir yapılandırma içeriyor. Bildiğim tüm konfigürasyon sistemleri bunu çoklu dosyalara bölmenize izin veriyor. Mesela app.conf, paylaştırmak istediğiniz şeyleri db.confiçerenleri ve daha sonra sadece .gitignore listesine koyduğunuz şeyleri aldınız. Sorun çözüldü. Özel bir şey kullanıyorsanız, gerçekten bu kadar basit bir şey elde etmeyi düşünmelisiniz. Ya da bir derleme öncesi olayda bir önişlemciden geçirin. Orada birçok çözüm var.

— Aidiakapi

1

Sevdiğim yararlardan biri, değişimin bir kısmını işleme yeteneğidir. Yani, git add -e kullanarak. Bazen istediğim kadar sık uğraşmıyorum ve git add -e komutu değişikliklerimi bir ölçüde çözmeme izin veriyor.

— leed25d
kaynak