Githubの保護されたブランチインストールに参加したことがある場合は、おそらくこの設定で見
これが何であるかを私に尋ねなければなりません。 実際、gitのワークフローのほとんどはそれを落胆させるので、誰もそれに注意を払うべきではありません。 しかし、私はとにかくそれを見てきたので、調べてみましょう。
Define
私の意見では、それは単にマージコミットのないコミット履歴です。 つまり、各コミットには1つの親と1つの子しかありません。 それは直線のように見えます。
例えば、このような
|
1
2
|
—o—o—o—o—o—o—o—o—o—o
|
これは線形の歴史ではありません
|
1
2
3
4
|
—o—o—O—O—M—o—o—o—O—O—O—O
/
—x—x
|
線形履歴を取得する方法
まず第一に, マージコミットはいつ行われますか。 マージコミットは、2つのブランチをマージするときに生成されますが、早送り戦略を使用できない場合、gitは2つのブランチをマージするためのマージコ たとえば、このような2つの枝があります。
|
1
2
3
4
|
マスター—o—o—o
テストA—B
|
testingがmasterと同じ履歴を持ち、さらに2つのコミットAとBしかない場合、早送りできます。 つまり、AとBの変更を適用するだけです。
|
1
2
|
マスター—o—o—O—A—B
|
しかし、このような2つの枝があれば。
|
1
2
3
4
|
マスター—o—O—O—O—O—O—D
テストA—B
|
その後、早送りを使用することはできません。 Merge2ブランチは次のようになります。
|
1
2
3
4
|
マスター—o—o—O—O—O—C—D—M
/
テストA——-B
|
git mergeを--no-ffフラグとともに使用すると、ブランチを早送りすることができますが、マージコミットが作成されます。
|
1
2
3
4
|
マスター—o—O—O—–M—
/
テストA—B
|
したがって、線形履歴を取得するには、マージされたすべてのマージとブランチが、早送り戦略を使用できるように、ベースブランチとの最新の履歴を持 Branchをbase branchで更新するには、git rebaseを使用します。 Rebaseは、現在のブランチのすべてのコミットをベースブランチに再適用します。
現在の分岐例はこれです。 ブランチfeatureコミット時にマスターからチェックアウトA
|
1
2
3
4
|
マスター—A—B—C
特徴D—E
|
ここで2つのブランチをマージすると、マージコミットが作成されます。 今、ブランチからfeature私はこのようにgit rebaseを使用します。
|
1
2
|
git rebase master
|
commitCからfeatureが再度チェックアウトされ、commitDとEがfeatureに再適用されるようになります。 今のブランチはこのようになります。
|
1
2
3
4
|
マスター—A—B—C
特徴D—E
|
早送り戦略でfeatureをmasterに統合できるようになりました。
rebaseは上記のように履歴を変更することに注意してください。 したがって、あなたがやっている現在のブランチでのみrebaseを使用します（一般的なレポにプッシュされません）。 大規模で時間のかかる機能（単独で作業する場合は、ブランチを誰とも共有しないでください）を使用する場合は、基本ブランチと定期的にリベースする 機能の競合だけでなく、まだ発見されていないバグ。
線形履歴何のために
なぜ人々は線形履歴を望んでいますか。 次のようにいくつかの利点があります
- 簡単にコミットの順序を決定します。 Mergeコミットは実際には二つのブランチを結合し、各ブランチは互いに独立した履歴を持つことができることをすでに知っているでしょう。
git logを使用すると、コミットが直線として編成されていることがわかります。 しかし、実際にはそれはとても読みやすいです。 そして、実際には上の写真のように見えます。 そのため、どちらが最初であるかを判断するのは難しく、どのコミットが実際にエラーを引き起こしたかを知るのは難しいです。 - コミット履歴をもっときれいにします。 あなたを混乱させるマージコミットはもうありません。 そして、あなたは線形履歴のないレポで
git log --graphを実行しようとすると、これを理解するでしょう。 - 簡単にコミットを元に戻すことができます。 各コミットには親が1つしかないため、マージコミット、リバートコミット、またはチェリーピックとは異なり、頭痛はずっと少なくなります。
:
- ユーザーがgitを理解する必要があります。
git rebase実際には非常に使いにくく、コミット履歴エラーを簡単に行います。 git rebaseとの競合をgit mergeよりもはるかに困難に修正します。mergeでは、コミットの競合を修正するだけです。 一方、rebaseでは、すべてのコミットに競合がある可能性があります。- 実際には、美しい歴史は必要ないかもしれません。 みんな
git mergeで大丈夫です。
Require linear history on Github
この機能がGithubで有効になっている場合、マージコミットを作成してプルリクエストをマージすることはできなくなります。
あなただけの2つのオプションが残っています：スカッシュとマージとリベースとマージ。 Squashとmergeは、pull request、rebase、mergeのすべてのコミットをスカッシュします。 Rebaseとmergeは、上で見たほとんどのrebaseです。 どちらも、追加のマージコミットを作成せず、コミット履歴を線形に保つために、早送り戦略を使用します。
Rebase and mergeでマージすると、Prに戻すときに、Githubはマージコミットと同じ大きさのコミットではなく、PRのすべてのコミットをrevert commitにします。
