なぜバージョン管理履歴問題を書き直すのか

Life is understood backwards, but must be lived forwards.
--- Søren Kierkegaard

良いコミットメッセージの概要
GitとGithubのようなバージョン管理システムが現代のソフトウェア開発ワークフローの中心にあるので、大部分のワークフローは大きく制御されて、バージョン管理のまわりで作動して、協力する方法に関して定義されます.
問題の追跡者、プルの要求、レビューツールを使用してメッセージをコミットする、ソースコードの変更を中心に回転する通信を配布する多くの正しい方法があります.…
なぜ良いコミットメッセージ?

コードは、それが書かれるよりはるかにしばしば読まれます.ASRaymond Chen says :

Even if you don't intend anybody else to read your code, there's still a very good chance that somebody will have to stare at your code and figure out what it does: That person is probably going to be you, twelve months from now.

同じ理由がコミットメッセージに及ぶ.ASChris Beans says :

... a well-crafted Git commit message is the best way to communicate context about a change to fellow developers (and indeed to their future selves). A diff will tell you what changed, but only the commit message can properly tell you why.

全体のコミットメッセージが「WIP」、「小さな修正」または「追加されたコード」のようなメッセージから成るとき.Peter Hutterer これは読書コードのトレーニングが不足していることを示唆しています.

If you haven't given much thought to what makes a great Git commit message, it may be the case that you haven't spent much time using git log and related tools. There is a vicious cycle here: because the commit history is unstructured and inconsistent, one doesn't spend much time using or taking care of it. And because it doesn't get used or taken care of, it remains unstructured and inconsistent.

共同作業における書換え費用
問題への解決策を発見するとき、探索された経路はめったに最短経路ではありません.Gitの歴史において良い説明をすることは、読むことにとって理想的になりますが、他の人と協調しながら「戻る」ときにはいくつかのコストがあります.

新しいツールを学ぶことのコスト:git履歴を書き換えることは、より難しいgitコマンドのいくつかを必要としますが、簡単なアプローチもあります.

Githubはあなたをsquash pull requests ; Web UIでは、すべてのコミットを1つにまとめることができ、textareaでコミットメッセージを編集できます.あなたのプル要求が小さいとき、これは最も働きます.

git commit --fixup and git rebase -i --autosquash 学ぶことと使いやすいです.読み込む --fixup & --autosquash guide フローレンスLebretonによって.

git reset --soft あなたが再びすべてを再コミットすることができます.読めるGit Basics: Rewriting a branch's commit history from scratch イゴールmarques da silvaによって.

履歴を書き換える前に、常にブランチのローカルコピーを作成できます.あなたもあなたのコピーの履歴を表示することができますgit log <branch> and git show <hash> ) 同時に歴史を再構築するgit add -p and git commit -v ).

Weedingのコスト:良い説明を書く時間と忍耐、そしてそれが最終的に読まれるという期待.あなたの将来の自己へのメッセージを書くことは、正当な動機づけとして働くことができます.

マージの衝突のコスト:リモートブランチに歴史と力を書き換えるとき、競合のないマージパスを削除することによって、そのブランチの上で協力者を同期させます.

明らかにpush --force 悪いんですか.幸運にもSteve Smith 言いたいことがあります.

The problem here is that when doing a force push Bob doesn’t know why his changes have been rejected, so he assumes that it’s due to the rebase, not due to Alice’s changes. This is why --force on shared branches is an absolute no-no; and with the central-repository workflow any branch can potentially be shared.

But --force has a lesser-known sibling that partially protects against damaging forced updates; this is --force-with-lease.

What --force-with-lease does is refuse to update a branch unless it is the state that we expect; i.e. nobody has updated the branch upstream. In practice this works by checking that the upstream ref is what we expect, because refs are hashes, and implicitly encode the chain of parents into their value.

あなたの協力者がコードを見直したり評価したりしても、変化を押していないとしても、強制的に押すことによって引き起こされたマージコンフリクトは余分な時間を同期させてしまうかもしれません.これが協力者を悩ますならば、おそらく、彼らの役割が満たされる前と後だけで、歴史を書き換えることは起こることができます.

探索的な経路は、「小さな修正」、「試み」と「Oops」ステップの多くを真実に含んでいるかもしれません、しかし、これらは6ヵ月で面白くありません.私たちは完全な後見に興味を持っているかもしれないので、問題追跡者のコメントのトレイルを残して、プルリクエストスレッドで、またはコードレビューでは理解を深める方法です.

良いコミットメッセージを書く方法

How to write a git commit message , クリスビームによって、書式化に焦点を合わせます:

1. Separate subject from body with a blank line
2. Limit the subject line to 50 characters,
3. Capitalize the subject line
4. Do not end the subject line with a period
5. Use the imperative mood in the subject line
6. Wrap the body at 72 characters
7. Use the body to explain what and why vs. how

On commit messages , ピーターHetererによって

1. Why is it necessary? It may fix a bug, it may add a feature, it may improve performance, reliabilty, stability, or just be a change for the sake of correctness.
2. How does it address the issue? For short obvious patches this part can be omitted, but it should be a high level description of what the approach was.
3. What effects does the patch have? (In addition to the obvious ones, this may include benchmarks, side effects, etc.)

現実世界の例
以下のコミットでプルリクエストを受け取ることを想像してください.

commit edc9ff5febb698a05f68650d6d58828202c24daf
Author: John Doe <[email protected]>
Date:   Mon Nov 22 16:23:24 2021 +0100

    WIP

このメッセージは明らかに著者が快適であるときに書き直すべき題名である.場合によってはコミットし、半分の作業をプッシュし、時には良い説明を提供すると待機したい.
協力するとき、Xは「Xをしないでください」と言う標準的な方法を確立します、そこで、Xは見て、見て、合併して、貢献するか、貢献者の間で潜在的対立を引き起こすどんな他の活動でもありえました.一般的に、語「WIP」はそれを意味します.
これは合併前にGit履歴の書き直しを保証します.

commit 11f8a068bec49abdddd7bdf203b77ecbfe48451f
Author: John Doe <[email protected]>
Date:   Thu Nov 4 10:19:40 2021 +0100

    Added cronjob

どのようなcronjobを追加し、なぜですか?

commit da8362e0b43ea3b18013f9245a614cf00ce43b60
Author: John Doe <[email protected]>
Date:   Thu Nov 4 12:49:43 2021 +0100

    fixup! Added cronjob

著者は、彼らが変化を押しつぶすつもりであると合図しています.この意図を念頭に置いて、これは明らかに合併前にGit履歴の書き直しを保証します.

commit 57e0b283f69c576db48003dc1ec3b2f492f79540
Author: John Doe <[email protected]>
Date:   Mon Nov 22 14:30:12 2021 +0100

    small fix

このコミットはいくつかの他のコミットに押しつぶされるべきである.これはコミットメッセージを書き換えるか、コミットを押しつぶすことを保証します.

commit 438cc1ce87dec47081b75d4cbd6ce4abca40b8c0
Author: John Doe <[email protected]>
Date:   Thu Oct 7 19:42:13 2021 +0200

    Added indexed "cachedStatus" field on KnowledgeNodeStore which is automatically filled with the value of KnowledgeNode->data['status']['state']. This might help the speed of common KnowledgeNodeQuery calls. Migration included that needs to run before we can remove the old filtering logic in KnowledgeNodeQuery.

はい、それは308文字の件名フィールドです.短くて、記述的なタイトル、そして、おそらく、言葉のラッピングを考え出すことに加えて、このコミットメッセージは、どのように、そして、理由よりむしろ詳細をします.記載されている含まれる移動は、別のコミットに分割できます.