ナゲッツテクノロジーコミュニティのクリエイター署名プログラムの募集に参加しています。リンクをクリックして登録し、送信してください。
Gitのキラー機能は、軽量のブランチを提供することです。svnブランチを使用すると、Gitがブランチを作成して切り替える速度に驚かれることでしょう。
Gitではブランチの操作が非常に頻繁に行われています。ブランチ操作の学習はGitの学習の基礎ですが、実際の作業では、多くの学生がGitブランチの操作に慣れていないことがわかりました。コマンドの背後にあるGitブランチモデル。
マスターブランチ
Gitで新しいプロジェクトを作成した後、デフォルトでブランチ、つまりメインブランチがあります。メインブランチは通常、プロジェクトの安定バージョンを表します。メインブランチには、安定したバグのないコードが含まれ、いつでもリリースできる状態を維持する必要があります。小規模なプロジェクトの場合、メインブランチは1つだけで十分です。送信するたびに、コミットが作成されます。ノード。
$ git commit -m "c1"
$ git commit -m "c2"
$ git commit -m "c3"
上記のコマンドは3つのコミットノードを作成します。このとき、マスターブランチを次の図に示します。
メインブランチはパッケージ化、マージ、送信のみが必要であり、すべての反復はブランチで実行する必要があります。単純な変更の場合は、メインブランチで直接変更することもできます。関数が複雑で必要な場合複数の提出がある場合は、メインブランチを使用することはお勧めしません。直接変更してください。
機能ブランチ
開発する新機能がある場合は、新機能ブランチを作成する必要があります。コマンドは次のとおりです。
$ git checkout -b feature/a
次に、次のコマンドを使用して、ブランチに2つのコミットを作成します。
$ git commit -m "c4"
$ git commit -m "c5"
この時点で、コミットツリーは次のようになります。
機能ブランチの開発が完了したら、メインブランチにマージする必要があります。メインブランチにマージする方法には、高速マージと非高速マージの2つのオプションがあります。この2つの違いは、作成するかどうかです。コミットノード。コマンドは次のとおりです。
$ git merge feature/a # 快速合并
$ git merge --no-ff feature/a # 非快速合并
次の図に示すように、クイックマージの結果は、マスターを直接feature/aにポイントします。
非高速マージの結果は、次の図に示すように、マスター上にマージコミットノードを作成します。
両方のマージ方法を使用できます。すばやくマージする場合は、各コミットが独立して完全であることを確認する必要があります。要件を満たしていない場合、Gitはコミット履歴の変更をサポートしています。コミット履歴は変更して再度マージする必要があります。
rebaseコマンドを使用して、履歴を変更できます。次のコマンドは、最後の3つのコミットを変更し、2番目のコミットの選択をスカッシュに変更し、最初と2番目のコミットをマージし、3番目のコミットの選択を編集に変更します。 3番目のコミットのコミット情報は変更できます。
$ git rebase -i HEAD~3
pick d24b753 feat: update ci
squash f56ef2f feat: up ci
edit 6c91961 feat: up
# Rebase 50ece5c..6c91961 onto 50ece5c (3 commands)
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
次の図に示すように、現在のブランチが作成された後、マスターブランチに新しいコミットが含まれる場合があります。
在合并之前，建议先将主分支新的提交合并到当前分支，有两种策略可以选择，合并和变基，合并操作更简单，变基操作提交树更清晰，建议使用变基的方式。
先来看下合并操作的过程，命令如下：
$ git merge master
$ git checkout master
$ git merge feature/a
合并操作后的提交树如下图所示：
变基会修改feature/a的历史，就像 feature/a 是在 master 之后开发的一样，变基命令如下：
$ git rebase master
$ git checkout master
$ git merge feature/a
变基操作后的提交树如下图所示，虚线的提交是feature/a变基之前的状态，在变基后，虚线的提交不再有分支指向，但并不会删除，而是变成Git中的游离节点，在Git执行GC（垃圾清理）操作后，节点才会彻底删除。
故障分支
如果发现存在 Bug，要尽快修复，此时可以基于主分支新建故障分支，命令如下：
$ git checkout -b bugfix/b
当验证没问题后，故障分支需要合并回主分支，并在主分支上发布新的补丁版本，命令如下：
$ git checkout master
$ git merge --no-ff bugfix/b
# 测试 构建 打标签 发布到npm
主分支更新后，下游的公共分支要及时同步变更，建议使用变基进行同步，命令如下：
$ git checkout feature/a
$ git rebase master
故障分支模型如下图所示，bugfix/b 分支合并到 master 后，feature/a 分支进行了变基操作。
标签与历史
每次发布新版本时都要打标签，版本号需要符合第四章介绍的语义化版本规范，一般功能分支发布次版本号，故障分支发布修订版本号，使用Git添加tag的命令如下所示：
# 假设当前版本是 1.1.0
$ git tag 1.1.1 # 修改次版本号
$ git tag 1.2.0 # 修改主版本
Git 的版本号，还可以添加 v 前缀，两种风格都可以，建议在一个项目里面保持统一，添加v前缀的版本示例如下：
# 假设当前版本是 v1.1.0
$ git tag v1.1.1 *# 修改次版本号
$ git tag v1.2.0 *# 修改主版本号
添加标签后，提交树示例如下图所示。
现在假设最新版本是 v1.2.0 了，突然用户反馈了 v1.0.0 版本存在 bug，如果是比较小的问题，一般我们会建议用户升级到最新版本 ，但如果用户不能升级怎么办，比如 1.x 到 2.x 存在大版本变化。
出于各种原因，存在需要维护历史版本的需求，对于还有用户使用需求的历史版本，需要提供 bug 修复的支持。
此时创建的标签就起作用了，可以基于标签新建一个版本分支，并在版本分支上修复 bug，且发布新的版本，历史版本分支，不需要再次合并回主干分支，创建标签分支的示例如下：
$ git checkout -b v1.0.x v1.0.0
此时历史分支的示例如下图所示。
总结
この記事では、Gitの一般的なブランチコマンドとブランチモデルを紹介し、Gitの原則をよりよく理解できるようにしたいと考えています。この記事が役立つと思われる場合は、作成者を気に入ってフォローしてください。この記事について質問がある場合は、コメントでExchangeへようこそ。
さらに、著者はGitHubで多くの優れたオープンソースプロジェクトを維持しています。ぜひご覧ください：github.com/yanhaijing