Git ブランチを切り替えずに複数のブランチを同時に操作する方法を説明します (詳細な例)

この記事では、Git ブランチに関する関連知識を紹介します。主に、ブランチを切り替えずに複数のブランチを操作する方法に関する関連問題を紹介します。皆様のお役に立てれば幸いです。

特定の機能を開発していると、上司が突然飛び出してきて、実稼働用のホットフィックスを作成するように頼まれることはよくあることです。 Git を使用する私たち 通常、解決策は 2 つあります:

1. 未完成の機能を急いでコミットし、ブランチをホットフィックスに切り替える

2. git stash | git stash Pop 作業内容を一時的に保存し、ホットフィックスに切り替えます

2 番目の方法は最初の方法よりもはるかに優れていますが、次の点に直面します。シナリオ、stash はまだあまり良い解決策ではありません

私たちが直面するシナリオ

1. メイン ブランチ、スイッチで長期テストを実行しています。ホットフィックスまたは機能をテストしてください。中断されます。

2. プロジェクトは非常に大規模で、頻繁にインデックスが切り替えられるため、コストが非常に高くなります。

3. 数年前にリリースされた古いバージョンでは、設定と現在は異なります。IDE の再構築適応の切り替えも多くのオーバーヘッドをもたらします。

4. ブランチを切り替えるときは、設定をリセットする必要があります。対応する環境変数 (dev/qa/prod など)

5. コードの再発問題のデバッグを支援するために同僚のコードに切り替える必要がある

一部の学生複数のリポジトリを git clone すれば十分ではないでしょうか?これは上記の問題を解決する方法ですが、その背後には多くの問題も隠れています:

1. 複数のリポジトリのステータスを同期するのは簡単ではありません。たとえば、同期する方法はありません。簡単にチェリーピックするには、リポジトリのチェックアウト ブランチ、別のリポジトリを再度チェックアウトする必要があります

2. git 履歴/ログが繰り返されます。プロジェクト履歴が非常に長い場合、その内容は.git フォルダーはディスク容量を非常に占有します

3. 同じプロジェクトと複数のリポジトリを管理するのは困難です

したがってこれらの特殊なシナリオを発生させずにどのように対処すればよいでしょうか? 上記の問題についてはどうすればよいでしょうか?

git-worktree

実は、これは Git が 2015 年からサポートしている機能ですが、知っている人はほとんどいません。ターミナルに

git worktree --help

と入力すると、ヘルプ ドキュメントの説明がすぐに表示されます:

git-worktree の機能を簡単に説明すると、次のようになります。

維持する必要があるのは 1 つのリポジトリだけであり、互いに影響を与えることなく複数のブランチを同時に操作できます。

#上で赤枠で囲まれたコマンドが多数あります。ただし、ここでは一般的に使用される次の 4 つのみを使用します。 :

git worktree add [-f] [--detach] [--checkout] [--lock] [-b <new-branch>] <path> [<commit-ish>]
 git worktree list [--porcelain]
 git worktree remove [-f] <worktree>
 git worktree prune [-n] [-v] [--expire <expire>]

説明を始める前に、見落としている可能性がある 2 つの Git 知識ポイントを広める必要があります。

1. Byデフォルト、git init または git clone 初期化されたリポジトリには、main worktree

   という名前の
worktree
2. が 1 つだけあります。特定のディレクトリ内の

   # Git コマンドを使用すると、現在のディレクトリに .git フォルダーまたは .git ファイルが存在します。 .git ファイルの場合、内部のコンテンツは .git を指す必要があります。フォルダーの

の 2 番目の文は非常にわかりにくいと思います。例を使って説明しましょう。

Spring Cloud を学習している場合は、長年にわたって連載され、更新され続けている無料のチュートリアルをお勧めします: https://blog.didispace。 com/spring-cloud-learning/

git worktree add

現在のプロジェクトのディレクトリ構造は次のようになります (

amend-crash-demo はリポジトリのルートです):

.
└── amend-crash-demo

1 directory
cd amend-crash-demo` 运行命令 `git worktree add ../feature/feature2
➜  amend-crash-demo git:(main) git worktree add ../feature/feature2
Preparing worktree (new branch 'feature2')
HEAD is now at 82b8711 add main file

ディレクトリ構造を確認してください

.
├── amend-crash-demo
└── feature
    └── feature2

3 directories

デフォルトでは、このコマンドは、HEAD が配置されているコミットに基づいて、feature2 という名前のブランチを作成します (もちろん、git ログに任意の commit-ish を指定することもできます)。ブランチ ディスクの場所は、上記の構造

cd ../feature/feature2/ に示すとおりです。このブランチには .git フォルダーは存在しませんが、.git ファイルは存在します。ファイルを開くと、内容は次のとおりです:

gitdir: /Users/rgyb/Documents/projects/amend-crash-demo/.git/worktrees/feature2

この時点で、上記の知識ポイント2を理解していれば、さらに明確になるでしょうか？

次に、メインのワークツリーを妨げることなく、feature2 ブランチで必要なこと (追加/コミット/プル/プッシュ) を行うことができます。

一般情况下，项目组都有一定的分支命名规范，比如 feature/JIRAID-Title, hotfix/JIRAID-Title, 如果仅仅按照上面命令新建 worktree，分支名称中的 / 会被当成文件目录来处理

git worktree add ../hotfix/hotfix/JIRA234-fix-naming

运行完该命令，文件目录结构是这样的

.
├── amend-crash-demo
├── feature
│   └── feature2
└── hotfix
    └── hotfix
        └── JIRA234-fix-naming

6 directories

很显然这不是我们想要的，这时我们就需要 -b 参数的支持了，就像 git checkout -b 一样

执行命令：

git worktree add -b "hotfix/JIRA234-fix-naming" ../hotfix/JIRA234-fix-naming

再来看一下目录结构

.
├── amend-crash-demo
├── feature
│   └── feature2
└── hotfix
    ├── JIRA234-fix-naming
    └── hotfix
        └── JIRA234-fix-naming

7 directories

进入 JIRA234-fix-naming 目录，默认是在 hotfix/JIRA234-fix-naming 分支上

worktree 建立起来很容易，不加管理，项目目录结构肯定乱糟糟，这是我们不想看到的，所以我们需要清晰的知道某个 repo 都建立了哪些 worktree

git worktree list

所有的worktree 都在共用一个 repo，所以在任意一个 worktree 目录下，都可以执行如下命令来查看 worktree 列表

git worktree list

执行完命令后，可以查看到我们上面创建的所有 worktree 信息, main worktree 也会显示在此处

/Users/rgyb/Documents/projects/amend-crash-demo                        82b8711 [main]
/Users/rgyb/Documents/projects/chore/chore                                   8782898 (detached HEAD)
/Users/rgyb/Documents/projects/feature/feature2                             82b8711 [feature2]
/Users/rgyb/Documents/projects/hotfix/hotfix/JIRA234-fix-naming     82b8711 [JIRA234-fix-naming]
/Users/rgyb/Documents/projects/hotfix/JIRA234-fix-naming              82b8711 [hotfix/JIRA234-fix-naming]

worktree 的工作做完了，也是要及时删除的，否则也会浪费很多磁盘空间

另外，如果您正在学习Spring Cloud，推荐一个连载多年还在继续更新的免费教程：https://blog.didispace.com/spring-cloud-learning/

git worktree remove

这个命令很简单了，worktree 的名字叫什么，直接就 remove 什么就好了

git worktree remove hotfix/hotfix/JIRA234-fix-naming

此时，分支名弄错的那个 hotfix 就被删掉了

/Users/rgyb/Documents/projects/amend-crash-demo                        82b8711 [main]
/Users/rgyb/Documents/projects/chore/chore                                   8782898 (detached HEAD)
/Users/rgyb/Documents/projects/feature/feature2                             82b8711 [feature2]
/Users/rgyb/Documents/projects/hotfix/JIRA234-fix-naming              82b8711 [hotfix/JIRA234-fix-naming]

假设你创建一个 worktree，并在里面有改动，突然间这个worktree 又不需要了，此刻你按照上述命令是不能删掉了，此时就需要 -f 参数来帮忙了

git worktree remove -f hotfix/JIRA234-fix-naming

删除了 worktree，其实在 Git 的文件中，还有很多 administrative 文件是没有用的，为了保持清洁，我们还需要进一步清理

git worktree prune

这个命令就是清洁的兜底操作，可以让我们的工作始终保持整洁

总结

到这里，你应该理解，整个 git-worktree 的使用流程就是下面这四个命令：

git worktree add
git worktree list
git worktree remove
git worktree prune

你也应该明白 git worktree 和 git clone 多个 repo 的区别了。只维护一个 repo，创建多个 worktree，操作间行云流水

我的实践：通常使用 git worktree，我会统一目录结构，比如 feature 目录下存放所有 feature 的worktree，hotfix 目录下存放所有 hotfix 的 worktree，这样整个磁盘目录结构不至于因为创建多个 worktree 而变得混乱

在磁盘管理上我有些强迫症，理想情况下，某个 repo 的 worktree 最好放在这个 repo 的文件目录里面，但这就会导致 Git track 新创建的 worktree 下的所有文件，为了避免 Git track worktree 的内容，来来回回修改 gitignore 文件肯定是不合适的！

那么如何解决呢？点击下方卡片，关注“日拱一兵”，正在连载Git的高级技巧！

灵魂追问

1. 可以删除 main worktree 吗？为什么

2. 反复创建和删除worktree， repo/.git/wortree 目录的变化你能理解吗？

推荐学习：《Git教程》

以上がGit ブランチを切り替えずに複数のブランチを同時に操作する方法を説明します (詳細な例)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。