一括コミットvsクイックコミット[終了]


8

私はあなたのほとんどがプロジェクトの戦略と方法論に沿ってアドバイスすることを知っています。

しかし、私は簡単な質問をしますが、シニアの観点から、開発者からの小さな小さなコミット、またはブランチにプッシュされた大きなコードの塊を見るには何が良いでしょうか?


早期リリースを頻繁にリリース!-しかし、リリースが壊れていないことを確認してください!エリックレイモンド
ディパンメタ2012

回答:


21

サイズは重要ではありませんが、コミットはできるだけアトミックである必要があります。つまり、コミットによってビルドが中断されてはならず、特定のバグが1つ修正されるか、特定の機能が1つ追加され、他のコミットから独立している必要があります。機能に多くのコードが必要な場合は、そうする必要があります。しかし、通常、この戦略は小さな頻繁なコミットを自然に生成します。


さらに同意することはできません
ジャッキーチャン

「機能が多くのコードを必要とするなら、それもそうです。しかし、通常、この戦略は自然に小さな頻繁なコミットを生成します。」:必ずしもそうではありません。ローカルで開発とテストを行うことができ、十分な自信がある場合はコミットします。後でバグ/問題を見つけた場合にのみ、さらにコミットが必要になることがあります。
Giorgio

6

制限はありますが、私は小さなアトミックなコミットを好みます。

まず、変更が加えられた理由を参照すると、作業が簡単になります。第二に、ミスを犯すコストを大幅に削減します。

ただし、次の2つの注意点があります。

集中型VCSを使用している場合は、コードのビルドとテストの実行時にのみコミットしてください。(DVCSを使用している場合は、「commit」を「push」に置き換えます。)

あるコミットコメントを別のコメントから暗黙的に参照しないでください。

351: pdr: Stop foo from grommiting.
352: pdr: Ooops, got that wrong, let's try again.
353: dan: New launch page.
354: pdr: Third time lucky.

そういうこと。しないでください。5分前に行ったコミットを覚えていて、コメントは自分との会話のように感じ始めるため、頻繁にコミットしていると非常に魅力的です。しかし、あなた自身を制御してください。与えられたファイルの最後のコミットを検索する、2年後の貧しい人には意味がありません。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.