固定とgitより良い

イントロ
現在、私はあなたの多くがGithub Flowに精通していると確信しています.
きれいなGitの歴史を維持するのに役立ついくつかの巧妙なGitコマンドを導入する前に、いくつかの良いGitの原則を確認するのに役立つ.
5 rules to Git Better
そのリンクが利用できないなら、5つの規則があります:

は、可能な限り

としてコミットします

は意味のあるコミットメッセージ

を書きます

リベース常に

は、すべて242479182を押しつぶしません

をコメントアウトする代わりに、コミットします
さて、今、私たちには、一般的な状況を見てみましょう.
次の手順では、この投稿の手順については、次のようにします.

前提条件
あなたはきれいなgitの歴史が欲しい
あなたは一貫してあなたのGitの歴史を書き直したくありません

状況

# coding the component

$ git commit -m "add some component"

# missed an edge-case

$ git commit -m "fix missing null check"

# add component to service

$ git commit -m "add component to service"

# updating the component after service tests found a bug

$ git commit -m "fix component due to silly bug"

$ rubocop

# fix linting errors

$ git commit -m "fix linting errors"

# team members do a code review on the PR / MR

$ git commit -m "fixes based on PR comments"

現在、この歴史は珍しくありません(実際、私はこのようなものを通過しない本物の多くのPRSを考えることができません).
これは、このように見えるgit履歴をもたらします

fixes based on PR comments
fix linting errors
fix component due to silly bug
add component to service
fix missing null check
add some component

しかし、それは本当に仕事の反射ですか?コミット履歴を「フィックスリンティング」コミットしてはいけません.
これは実際に仕事の代表です.

add component to service
add some component

解決策
別の方法でこれらの“修正”について行きましょう.
私たちはよく知られているコマンドgit commitを使用しますが、適切なフラグ(適切に)fixupと呼ばれます.

# coding the component

$ git commit -m "add some component"

# missed an edge-case

$ git commit --fixup <COMMIT HASH OF THE COMMIT "add some component">

# add component to service

$ git commit -m "add component to service"

# updating the component after service tests found a bug

$ git commit --fixup <COMMIT HASH OF THE COMMIT "add component to service">

$ rubocop

# fix linting errors

$ git commit --fixup <COMMIT HASH OF THE COMMIT "add component to service">

# team members do a code review on the PR / MR

$ git commit --fixup <COMMIT HASH OF THE COMMIT "add component to service">

我々がgitログを見るならば、我々は見ます

fixup! add component to service
fixup! add component to service
fixup! add component to service
add component to service
fixup! add some component
add some component

定期的にコミットしている(そして、コミットメッセージを書く)代わりに、私たちはフィックスアップコミットを作成するために--fixupフラグを使用します.
さて、マージ要求をマージする前に、--autosquashフラグで対話的なRebaseを発行します.

注意:

GitLab marks MRs that include fixup commits as WIP, so
merging is prevented if you haven't squashed.

$ git rebase --interactive --autosquash \
  <COMMIT HASH OF THE COMMIT "add some component">~1

関連付けられたコミットが既に固定されている場合、対話的なRebaseモードに入ります.

fixup afa6970 fixup! add component to service
fixup 1da5d7c fixup! add component to service
fixup c998b08 fixup! add component to service
pick d9731b5 add component to service
fixup 33d6080 fixup! add some component
pick 73e8a6a add some component

Git履歴は次のようになります.

add component to service
add some component

最終的な結果は非常に一貫して読みやすいGitの歴史です.そこで、他のすべての開発者は、この最終的なコードへの旅行に関してすべてのバグについて知ることなく、何が起こるかについてわかっています.

概要
要約すると、Git fixupワークフローを使用するには、次の2つのgitコマンドが必要です.

$ git commit --fixup <COMMIT THAT NEEDS FIXING>
$ git rebase -i --autosquash <FIRST COMMIT THAT NEEDS FIXING>~1