[TIL]9月17日:Branch、PR、Merge

今日の好奇心

GitHubはブランチを作成し、ファイルを作成し、マージを試みます.端末ではgit branchというコマンドを使用してブランチリストを問合せ、メインブランチのみを表示します.ここで初めて悩む...
だからネットで検索した結果!
git branchコマンドは、ローカルブランチリストを表示するコマンドです.
GitHubが生成するブランチはリモートブランチであり,端末でそれを照会するにはgit branch-rを入力するだけでよい.ローカルブランチリストとリモートブランチリストをクエリーするコマンドはgit branch-aであることに注意してください.
ああ、なるほど…ちょっと待ってrepositoryがローカルとリモートに分かれているのは知っていますが、ブランチも分かれています...?
ここで二度目の苦悩
GitHubでリモートブランチを作成しましたが、このブランチをローカルにインポートできますか?
ローカルで作成したブランチをリモートブランチに送信できますか?
ローカルブランチとリモートブランチが一致しない場合はどうなりますか?
Gitを使うと好奇心が増すこれらの疑問を解決すれば未来の私は幸せな顔をするだろう.だから今からGitのBranch,Merge,Pull Requestを詳しく知ります.

Branch

GitHub Repositoryアドレスをコピーし、ローカルRepositoryにコピーします.コピー後、対応するローカルリポジトリに移動します.
注意:git cloneを行うとgit remote add origin(そのリポジトリアドレス})コマンドが自動的に実行されるため、git remoteクエリーでoriginが表示されるかどうかを判断できます.
クローン後の画面

Branchを生成します.

git checkout kj(브랜치명): 브랜치로 이동
git checkout -b kj(브랜치명): 브랜치 생성 후 브랜치로 이동

git checkout-bkjの入力

kjブランチが作成され、ブランチに移動したことを確認できます.
その後、Branchを問い合わせることができます.

git branch : 로컬 리포지토리 브랜치 확인 
git branch -r : 원격 리포지토리(깃허브) 브랜치 확인
git branch -a : 모든(원격+로컬) 브랜치 확인

git分岐結果
ローカルリポジトリブランチを確認できます.

git branch-r結果
まだpushがないのでkj分岐は見えません.

git branch-a結果
ローカルおよびリモートのリポジトリブランチを表示できます.

ローカルリポジトリのkjブランチをリモートリポジトリブランチに接続します.

git branch --set-upstream-to origin/main (<- 연동할 브랜치명) 

その後、リモートブランチを変更した場合はgit fetchコマンドで変更をローカルリポジトリにロードします.
リモートブランチに変更があり、ローカルブランチの変更とマージされない場合は、ローカルブランチのワークピースをアップグレードするときに競合します.

作業物をローカルのkjブランチに配置し、pushを行います.


Push Hutchバニラ入ったら

ローカルに生成されたkj分岐がリモートリポジトリにも適用されることを確認できます.
また確認できるのはCompare&pull requestボタンです.
pull request略称PR.
ブランチを作成したり、新しい機能を作成したり、エラー修正コードを作成したりして、PRに修正を反映するように要求します.コメント担当者は、変更をコメントおよび承認する際に、これらの変更を反映します.
入ってみます.

PRにコメントを残し、問題がなければCreate Pull Requestボタンをクリックします!
注意:Draft pull request-draftモードのPRホットスポットではmergeボタンは有効ではありません.代わりに「This pull request isはまだ進行中」という内容です.これは、コードがまだ動作しており、マージの準備ができていないことを意味します.すなわち,Draftモードを用いて動作中のコードを議論することができる.Webページを通じてコードを交換し、作業事項を反映します.
CreatePull Requestボタンをクリックします.

以下の画面が表示されます.
Merge Pull Requestの横の矢印を押します

3種類の集計方式が確認できます.

Merge

マージ、Squash merge、およびRebase merge方式のマージ方法があります.

Merge

連結は一般連結です.ブランチとブランチは、次にマージされたRepositoryの履歴で、どのブランチでマージされ、このブランチにどのcommitがあるかを表示できます.

user 2ブランチもkjブランチと同じPRを行い,両ブランチともマージした.

統合のメリット

このPRは、履歴において詳細に確認することができる.
ブランチ別にコミットを分離してコミットを維持します.
従来のブランチのコミットは変わらず、他の開発者との作業共有に関心を持つ必要はありません.

欠点のマージ

ブランチが多くなり、提出も多くなると、履歴に多くの情報が蓄積され、認識されにくくなります.そのため、プロジェクトの規模が大きいほど、人気がありません.

Rebase merge

Rebase mergeは、連結ブランチのCommit履歴をそのまま移動します.ブランキーのベースメイクを変えて、その名の通りRebaseです.したがって、ブランチは接続できません.

マージベースの利点

歴史の物語を見るときはきれいに見ることができます.複数のブランチを複雑に織り交ぜない限り、1つのブランチの履歴を読むだけで、そのプロジェクトの履歴を知ることができます.これは、複数の開発者が同じブランチを共有するときに、コミットを統合する最も直感的で簡潔な方法です.

ベースマージの欠点

Rebaseが複数のコミットをマージし、Commit競合が発生した場合、マージするコミットはすべて競合します.
グラフにはクモの巣のように接続された分岐はありませんが、意味のないcommitも履歴に残ります.
衝突の場合は複雑です.Rebaseはコミット順に実行され、各コミットは順番に競合を解消する必要があります.SourceTreeが指導していますが、簡単ではありません.

Squash merge

SquashはRebase mergeにオプションを追加したような気がします.Squashオプションを適用するResbase mergeをSquash mergeと呼びます.
Squash mergeはベースですが、マージするcommitをcommitに組み合わせます.

Squash mergeの利点

歴史の分岐も清潔に保ち、些細な提出を解消し、有意義な提出だけが歴史を構成することができる.

Squash merge端点

欠点は、マージに関する情報が不足していることです.ただし、Merge commitの説明で詳細を説明すれば問題にならない.

3種類の集約グラフィックの外観

sourcetree

青:main(デフォルト)ブランチ
オレンジ:kj分岐(Merge)
赤:user 2ブランチ(Merge)
紫:user 3分岐(Squash merge)
緑:ユーザー4ブランチ(Resbase merge)
一般mergeでは、1つのブランチが次のブランチであることを確認できます.
上のグラフではよくわからないようなので、自分で描いてみました.

merge

squash

commit a、b、cをマージし、新しいcommit abcを作成してmasterに追加します.
abcには親がいます.

rebase

すべてのcommitはマージされず、mainブランチにそれぞれ追加されます.
各commitにはparentがあります.

3種類の集約履歴画面

一般的なマージでは、履歴に2つの異なるcommitメッセージと2つの異なるPRマージ情報が表示されます.
Squash mergeは簡単です.commitメッセージとカッコに#数字が入っているからです.#PRマージ情報は、数値をクリックして表示できます.
Rebase mergeはcommitメッセージですが、画面に表示されます.
リファレンス
“Github - Merge/Squash Merge/Rebase Merge.” Velog,
https://velog.io/@code-bebop/Github-merge-squash-merge-rebase-merge .