Achievement Goals

Git Branchの概念は理解できる.
Gitを使用してコラボレーションやブランチを行う理由が理解できます.
Gitを使用してプロジェクトを管理し、ブランチを作成、変換、マージできます.

🍞 ブランチ

ブランキーって何?
すでに作成されたコードは単独の概念と見なすことができる.
このブランドはなぜ良いのか、もしあなたが一人で長いコードを修正したいならば、しかしあなたはそれにぶつかって、あなたはあなたの前にした仕事を破壊することができて、あなたはそのため崩壊して、生きたくなくて、圧力と脱毛します.(うん?)
要するに,ブランチは独立して格納されているので,既存のコードを保持し,同じコード全体をコピーしたように,コード変更を心配することなく開発を思う存分行うことができる.これらの機能は同時に複数の作業を行うことができます.
整理すると、

のソースコードで同時に複数の操作を行うことができる.

ソースコードのある時点と同じ状態を作成し、ブランチ間で操作を実行できます.

各分岐路に生じる変化は、他の分岐路に影響を及ぼさず、独立して符号化することができる.

これは以前よく知られていた分岐で、master/main分岐があり、分岐の根と言える.
この2つだけでhotfix、release、develop、featureなど多くのブランチを作成できると思っていました.

異なるブランチで作業した後の変更は、他のブランチとマージ(merge)
いいですよ.
たとえば、独立したタスクを完了したら、統合ブランチにマージします.他の担当者が担当するすべての作業を連結ブランチにマージして、変更を保存します.
このように作業を行うと、問題が発生した場合に作業ユニットに分割され、問題の原因をすぐに把握できます.

🍞 ブランチのタイプ

🥪 統合ブランチ

main/masterのように、ライブラリの最初の作成時に作成されたブランチです.
分岐の根元として扱われます.
配備するソースコードが記録され、プロジェクト内のすべての機能が正常に動作するソースコードが含まれています.

🥪 フィーチャーブランチ

「トピックブランチ」と呼ばれるフィーチャーブランチは、機能の追加やエラーの変更など、単位操作に使用される部分であるマージブランチから作成されます.フィーチャーブランチでは、1つの操作が完了すると、マージブランチにマージされます.

🍞 分岐コマンドバーzip

🥪 新規ブランチの作成
$git branch新しいブランチ名
🥪 新しいブランチを作成し、ブランチに切り替えます.
$git checkout-b新しいブランチ名
$git switch-c新しいブランチ名
🥪 ブランチの切り替え
$git checkoutブランチ名
$git switchブランチ名
🥪 ブランチリストの確認
$ git branch
🥪 ブランチリストと各ブランチの最近のコミットを確認
$ git branch -v
🥪 ブランチの削除
$git branch-d削除するブランチ名
$git branch-dコマンドは、マージされていないブランチを強制的に削除するために使用されます.
🥪 ブランチのマージ
devブランチをmasterブランチにマージする場合(master←dev)
$ git checkout master
$ git merge dev
🥪 すべてのブランチをログにグラフィックで表示
$ git log --branches --graph --decorate
🥪 コミットされていないタスクをスタックに一時保存
$ git stash

🍞 プロジェクトgitワークフロー

実際、チームメンバーとプロジェクトを行う際のプロセスはどのようなものですか?
よく観察します
インポート1.fork+gitクローン
香水をつけるときにすることRemoteの記録を私の記録に持ってきてください.以下の説明は省略する.ハハハ
2.メイン/メインブランチにdev(HEAD)ブランチを作成する
mainブランチは確かにルートですが、通常は新しいdevブランチが作成され、そこから始まります.

git checkout -b dev 또는 git switch -c dev
git push origin dev 

このときHEADは現在位置のコミットを表す.
また、新しく作成したブランチをremote repositoryに適用するために、originでdevを解放するコマンドも使用しました.
3.ブランチ作成の確認
ブランチを作成するかどうか、および現在の場所が新しく作成したブランチにあるかどうかを決定するコマンド.

git branch

確認して外に出たい場合は、qを押して終了します.
4.各機能のブランチを作成する
メンバーたちと会議をした後、どんな機能にも参加することにした.
devブランチに直接配置するのではなく、「feature/機能」ブランチを作成してタスクを分割し、対応するタスクを配置します.
ログ人気に参加したい場合はfeature/loginというブランチを生成します.

git checkout -b feature/login 또는 git switch -c feature/login

適切なコマンドを作成し、作成時にブランチに移動します.
また、既存のログイン機能にOAuthソーシャルログイン機能を追加する場合は、feature/loginブランチで新しいブランチ特性/login-oauthブランチを閉じずに作成するよりも、新しいブランチ特性/login-oauthブランチを作成する必要があります.既存のログイン機能コードでエラーが発生する可能性があります.
しかし、feature/loginから派生したブランチなので、位置を確認してブランチを生成!

git checkout -b feature/login-oauth 또는 git switch -c feature/login-oauth 

5.完了した機能をブランチにマージ
ログイン機能とソーシャルログインOAuthコードが完全に駆動されていることを確認し、2つのブランチを1つのブランチに統合することにした.
そのため、OAuthの長兄級feature/loginに移動します.
(合併する分岐の兄のように移動.ここでHEADはfeature/loginでしょうか?)
移動後に派生したfeature/login-oauthをマージします.

 git checkout(switch) feature/login // 형님브랜치로 이동
 git merge feature/login-oauth // 형님브랜치와 oauth 브랜치와 병합

自動的にfast-forward方式でマージされます.

🧐 fast-forwardは?

rebase方式で、feature/login-oauthが指すコミットを、個別のコミットを生成するのではなく、feature/login-oauthが生成するコミットに変換します.
feature/loginをコミットしてmergeを行った場合、merge commitでマージされます.
merge
変更内容の履歴が残りますので、履歴が複雑になります.
rebase
名前の通りbranchbaseを移動するという意味で、mageのようにブランチをマージすることを目的としていますが、ブランチをある時点に指向する機能です.

git rebase main feature/login

mergeとrebaseの違い

6.ローカルで働くコンテンツをプッシュ
すべての作業が完了したら、リモートRepositoryにプッシュします.

 git push origin feature/login

7.devブランチに適用
GithubのPull Request機能でdevブランチへの反映を要求できます.コメントを完了するコードは、ブラウザでdevブランチにマージすることもできます.

create pull requestボタンを押してマージ
(サンプル写真なのでボタンはblk処理ですのでご了承ください.)

🍞 分岐フロー全体の表示

次は、前のプロセス全体を図式化した図です.

最初のローカルに新しいブランチを作成してプロジェクトをコミットし、完了したらリモートにプッシュします.この場合、最も根本的なremote、Project Upstream Repositoryにも反映されるので、マージを要求することを忘れないでください.
プロジェクトUpstream Repositoryを変更した場合は、ローカルに戻す必要があります.

git extension : git graph

git graphを押すと既存のブランチやHEADなどが簡単に見えます.