你如何在“獨奏開發”中使用git（沒有團隊）？

Question

我是小型項目的自由職業者，所有這些都是我獨自完成的，沒有團隊。

我試着使用Git Flow。 起初，一切都很好。 有功能分支，有意義描述的小提交，合並。

但是這個過程總是以非常大的提交結束，直接到主分支，描述如“大更新”，“一些更新”。

你如何解決？ 在我的情況下我是否需要Git Flow？

Answer 1

但是這個過程總是以非常大的提交結束，直接到主分支，描述如“大更新”，“一些更新”。

這就是git rebase --interactive和git add --patch的用途。

這是你要做的第一件事：你必須讓自己成為一個瘋狂的人。 不，兩個瘋狂的人，每個人都說服對方是別人。 不，等等，那不對。 三個瘋狂的人。

你已經知道了（目前是理智的），誰完成了這項工作，並沒有看到任何其他說法。 所以：瘋狂的你和一個理智的歷史的第一步是代碼審查員的新的（但純粹想象的片段），他對你在看到提交消息和補丁之前所做的改變一無所知。 你需要尊重那個人的時間。 第三部分，從有用的怪癖到全面的精神錯亂，是橡皮鴨 。 這是一個懸而未決的問題，無論是攜帶一只真正的橡皮鴨，還是僅僅想象一下恰好是橡皮鴨的想象中的紅顏知己，對其他人的現實感（更不用說你自己）更令人不安了。

所以，兩個瘋狂的人和一只鴨子。

如果橡皮鴨無法理解您的解釋，或者評論者無法理解您的代碼，那么請簡化，直到他們可以。 將提交分解為不會破壞構建的獨立部分，不要讓審閱者或者鴨子想知道為什么每個部分都需要在那里保持一切正常。

看，如果你進行了設置，那么做正確的事情具有巨大的娛樂價值，世界將是美好的。 如果你不這樣做，那么至少會令人不快和無聊。 唯一不這樣做的時候就是你已經感覺到在幾個月內你需要做這件事有多糟糕，那只是浪費時間。 但如果你要失去它，請確保你獲得更有價值的東西作為交換。

無論你是否玩得開心，都需要改裝和添加。

Answer 2

我想這是紀律問題。

對我來說，使用描述其包含的確切更改的小提交非常有用。 我在我與團隊合作的工作環境中使用此流程，但也用於我作為業余愛好或項目的項目。

如果您有圖形用戶界面，它會有所幫助。 我使用Atlassian SourceTree，它可以很容易地選擇對行的更改。 因此，有時候我已經編寫了一段時間，進行了大量的更改，我仍然會逐個進行編寫，並使用有用的消息提交每個更改。

但最好一次做一個更改，驗證它是否有效並提交。 如果你經常提交，如果你犯了很大的錯誤，你總會有一些東西要回去。

就個人而言，我不使用git flow的開發，發布和其他動詞，雖然我確實為我開發的不同功能創建了單獨的分支。 這允許我在進行中時將更改放在一邊並進行單獨的拉取請求（這在團隊中可能更有用）。