Cet article vous apporte des connaissances pertinentes sur les branches Git. Il présente principalement des problèmes connexes sur la façon de travailler sur plusieurs branches sans changer de branche. J'espère qu'il sera utile à tout le monde.
Lorsque vous développez une certaine fonctionnalité, le patron surgit soudainement et vous demande de faire un hotfix pour la production. Face à cette situation, nous qui utilisons Git avons généralement deux solutions :
Soumettre à la hâte. fonctionnalité inachevée, puis passez la branche au correctif
git stash | git stash pop
pour stocker temporairement le contenu du travail, puis passez au correctifgit stash | git stash pop
暂存工作内容,然后再切换到 hotfix
第二种方式较第一种还好很多,可是面对下面这些场景,stash 依旧不是很好的解决方案
正在 main 分支上跑长时间的测试,切换到 hotfix 或 feature, 测试就会中断
项目非常大,频繁的切换索引,成本非常高
有几年前 release 的旧版本,设置和当前不一样,IDE restructure 适配切换也会带来很大的开销
切换分支,需要重新设置相应的环境变量,比如 dev/qa/prod
需要切换到同事的代码,帮助调试代码复现问题
有的同学想到,git clone 多个 repo 不就可以了吗?这是解决上述问题的一个方法,但背后同样隐藏很多问题:
多个 repo 的状态是不好同步的,比如没办法快速 cherry-pick, 一个 repo checkout 的分支,另外一个 repo 需要重新 checkout
git history/log 是重复的,当项目历史非常长,.git
文件夹下的内容是非常占用磁盘空间的
同一个项目,多个 repo,不易管理
那如何做才能满足这些特殊场景,又不出现这些上述这些问题呢?
其实,这是 Git 2015 年就开始支持的功能,却很少有人知道它,git-worktree 的使用非常方便,在终端输入:
git worktree --help
就可以快速看到帮助文档说明:
用简单的话来解释 git-worktree 的作用就是:
仅需维护一个 repo,又可以同时在多个 branch 上工作,互不影响
上面红色框线命令有很多,我们常用的其实只有下面这四个:
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>]
在展开说明之前,需要和大家普及两个你可能忽视的 Git 知识点:
默认情况下, git init
或 git clone
初始化的 repo,只有一个 worktree
,叫做 main worktree
在某一个目录下使用 Git 命令,当前目录下要么有 .git
文件夹;要么有 .git
文件,如果只有 .git
文件,里面的内容必须是指向 .git
文件夹的
第二句话感觉挺绕的,下面用例子说明,就很容易明白了
如果您正在学习Spring Cloud,推荐一个连载多年还在继续更新的免费教程:https://blog.didispace.com/spring-cloud-learning/
当前项目目录结构是这样的(amend-crash-demo
是 repo 的 root):
. └── 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 所在的 commit-ish (当然也可以指定 git log 中的任意一个 commit-ish) 创建一个名为 feature2 的分支,分支磁盘位置如上面结构所示
cd ../feature/feature2/
会发现,这个分支下并不存在 .git
文件夹,却存在一个 .git
La deuxième méthode est plus Le premier est bien meilleur, mais face aux scénarios suivants, le stash n'est toujours pas une bonne solution
tourne sur le branche principale Si vous passez au correctif ou à la fonctionnalité pendant une longue période, le test sera interrompu🎜🎜🎜🎜Le projet est très volumineux et les changements d'index fréquents sont très coûteux🎜🎜🎜🎜L'ancienne version a été publiée il y a quelques années, et les paramètres sont différents de ceux actuels. Le changement d'adaptation à la restructuration de l'IDE entraînera également beaucoup de frais généraux. Lors du changement de branche, vous devez réinitialiser les variables d'environnement correspondantes, telles que dev/qa/prod. Vous devez passer à celles de vos collègues. code pour aider à déboguer la récurrence du code. Question🎜🎜🎜Certains étudiants ont pensé : ne suffirait-il pas de cloner plusieurs dépôts ? C'est un moyen de résoudre les problèmes ci-dessus, mais il y a aussi de nombreux problèmes cachés derrière : 🎜🎜🎜🎜Le statut de plusieurs dépôts n'est pas facile à synchroniser. Par exemple, il n'y a aucun moyen de sélectionner rapidement un seul dépôt. checkout branche, et un autre dépôt doit être re-checkout🎜🎜🎜🎜git history/log est répété Lorsque l'historique du projet est très long, le contenu du dossier🎜L'encadré rouge ci-dessus Il existe de nombreuses commandes de ligne, mais nous n'utilisons que les quatre suivantes, couramment utilisées : 🎜.git
occupe beaucoup de place. espace disque🎜🎜🎜🎜Le même projet, plusieurs dépôts, difficile à gérer🎜🎜🎜Alors, que peut-on faire pour répondre à ces scénarios particuliers sans causer les problèmes ci-dessus ? 🎜git-worktree
🎜En fait, il s'agit d'une fonctionnalité que Git prend en charge depuis 2015, mais peu de gens la connaissent, car git-worktree est très pratique à utiliser. saisissez-le dans le terminal :🎜🎜Vous pouvez voir rapidement la documentation d'aide :🎜🎜🎜🎜Expliquez la fonction de git-worktree en mots simples : 🎜🎜🎜Vous n'avez besoin de maintenir qu'un seul dépôt et vous pouvez travailler sur plusieurs branches en même temps sans s'affecter les unes les autres🎜gitdir: /Users/rgyb/Documents/projects/amend-crash-demo/.git/worktrees/feature2Copier après la connexion
git worktree add ../hotfix/hotfix/JIRA234-fix-naming
git init
ou git clone
initialisé, il n'y a qu'un seul worktree
, appelé main worktree
🎜🎜🎜🎜Utilisez Git dans une certaine commande de répertoire, il y a soit un dossier .git
ou un fichier .git
dans le répertoire courant. >.git, le contenu à l'intérieur doit être 🎜🎜🎜Pointant vers le dossier .git
La deuxième phrase semble un peu déroutante. Utilisons un exemple pour l'illustrer et. ce sera facile à comprendre🎜🎜🎜Si vous apprenez Spring Cloud, recommandé Un tutoriel gratuit sérialisé depuis de nombreuses années et qui continue d'être mis à jour : https://blog.didispace.com/spring-cloud-learning/🎜 amend-crash-demo
est la racine du dépôt) : 🎜. ├── amend-crash-demo ├── feature │ └── feature2 └── hotfix └── hotfix └── JIRA234-fix-naming 6 directories
git worktree add -b "hotfix/JIRA234-fix-naming" ../hotfix/JIRA234-fix-naming
cd ../feature/feature2/
Vous constaterez que cette branche Il n'y a pas de dossier .git
, mais il y a un < code>.git Ouvrez le fichier et le contenu est le suivant : 🎜. ├── amend-crash-demo ├── feature │ └── feature2 └── hotfix ├── JIRA234-fix-naming └── hotfix └── JIRA234-fix-naming 7 directories
一般情况下,项目组都有一定的分支命名规范,比如 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
所有的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/
这个命令很简单了,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 的使用流程就是下面这四个命令:
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的高级技巧!
可以删除 main worktree 吗?为什么
反复创建和删除worktree, repo/.git/wortree 目录的变化你能理解吗?
推荐学习:《Git教程》
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!