Cet article vous apporte des connaissances pertinentes sur Git, qui présente principalement les problèmes liés à la création, la suppression, l'affichage et la fusion de branches dans la gestion des versions. J'espère qu'il sera utile à tout le monde.
Etude recommandée : "Tutoriel d'apprentissage Git"
Branche unique :
Au début, la branche master
est une ligne, et Git utilise master
pointe vers la dernière soumission, puis utilise HEAD
pour pointer vers master
afin de déterminer la branche actuelle et le point de soumission de la branche actuelle : master
分支是一条线,Git 用master
指向最新的提交,再用HEAD
指向master
,就能确定当前分支,以及当前分支的提交点:
每次提交,master分支都会向前移动一步,这样,随着你不断提交,master分支的线也越来越长。
多分支:
当我们创建新的分支,例如dev
时,Git 新建了一个指针叫dev
,指向master
相同的提交,再把HEAD
指向dev
,就表示当前分支在dev
上
你看,Git 创建一个分支很快,因为除了增加一个dev
指针,改改HEAD
的指向,工作区的文件都没有任何变化!
不过,从现在开始,对工作区的修改和提交就是针对dev
分支了,比如新提交一次后,dev
指针往前移动一步,而master
指针不变:
多分支合并:
把master指向dev的当前提交,就完成了合并, Git 合并分支也很快!就改改指针,工作区内容也不变!
合并完分支后,甚至可以删除dev分支。删除dev分支就是把dev指针给删掉,删掉后,我们就剩下了一条master分支:
git checkout
:$ git checkout -b dev Switched to a new branch 'dev'
git checkout命令加上-b参数表示创建并切换,相当于以下两条命令:
$ git branch dev $ git checkout dev Switched to branch 'dev'
git switch
:创建并切换到新的dev分支,可以使用:
$ git switch -c dev
注意:
git switch
和git checkout
在分支操作方面的用处完全一样。那么可以在分支操作上尽量光用git branch
和git switch
。
因为git checkout
除了可以操作分支,它还可以操作文件(可以重写工作区)。
$ git branch * dev master
git merge
命令:用于合并指定分支到当前分支。
# 切换回当前的分支:$ git checkout master Switched to branch 'master'# 合并到指定分支:$ git merge dev Updating 599dbdb..4aac6c7 Fast-forward readme.txt | 1 + 1 file changed, 1 insertion(+)
上面使用的是Fast forward模式(“快进模式”),但这种模式下,删除分支后,会丢掉分支信息。
如果要强制禁用Fast forward模式
,Git 就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息。
$ git merge --no-ff -m "merge with no-ff" dev Merge made by the 'recursive' strategy. readme.txt | 1 + 1 file changed, 1 insertion(+)
合并后的结果如下:
$ git branch -d dev Deleted branch dev (was 4aac6c7).
冲突情况发生的情况如下图所示,Git 无法执行“快速合并”,必须手动解决冲突后再提交。
合并冲突后的结果:
点击合并请求
,选择我们需要的分支内容,然后选择合并。
git fetch origingit checkout -b "feature1" "origin/feature1"
Git 用
dev
, Git crée un nouveau pointeur appelé dev
, qui pointe vers le même point que master
Soumettez, puis pointez HEAD
sur dev
, ce qui signifie que la branche actuelle est sur dev
🎜🎜Vous voyez, Git crée une branche très rapidement, car À part l'ajout d'un pointeur dev
et le changement du pointeur de HEAD
, il n'y a aucune modification dans les fichiers dans l'espace de travail ! 🎜🎜🎜🎜Mais à partir de maintenant, les modifications et les soumissions à l'espace de travail sont destinées à la branche dev
. Par exemple, après une nouvelle soumission, le pointeur dev
avance d'un pas, et le mastercode> Le pointeur reste inchangé : 🎜🎜<img src="https://img.php.cn/upload/article/000/000/067/f7fc56762371f73f89d657e60fd745a4-2.png" alt="Veuillez ajouter une description en image"><br>Fusion multi-branches : 🎜🎜Pointez master vers le commit actuel du développeur pour terminer la fusion. Git fusionne les branches très rapidement ! Changez simplement le pointeur et le contenu de l’espace de travail restera inchangé ! 🎜🎜<img src="https://img.php.cn/upload/article/000/000/067/f7fc56762371f73f89d657e60fd745a4-3.png" alt="Veuillez ajouter une description en image">🎜🎜Après la fusion des branches , Vous pouvez même supprimer la branche dev. Supprimer la branche dev signifie supprimer le pointeur dev. Après la suppression, nous nous retrouvons avec une branche master : 🎜🎜<img src="https://img.php.cn/upload/article/000/000/067%20/f7fc56762371f73f89d657e60fd745a4-.%204.png" alt="Veuillez ajouter une description de l'image">🎜🎜2 Gestion des succursales🎜🎜2.1 Créer une succursale🎜<ul><li>Utilisez <code>git checkout
:
Git is a distributed version control system. Git is free software distributed under the GPL. Git has a mutable index called stage. Git tracks changes of files.>>>>>> feature1
git fetch origingit checkout "master"git merge --no-ff "feature1"
git switch
:git push origin "master"
🎜Remarque :🎜2.2 Afficher les branches🎜git switch
etgit checkout
en termes des opérations en succursale Les usages sont exactement les mêmes. Ensuite, vous pouvez essayer d'utiliser uniquementgit branch
etgit switch
pour les opérations de branche.
Parce quegit checkout
peut non seulement faire fonctionner des branches, il peut également gérer des fichiers (peut réécrire l'espace de travail). 🎜
git stash git pull origin master git stash pop
git merge
: utilisée pour fusionner la branche spécifiée avec la branche actuelle. 🎜git reset --hard git pull origin master # 或git fetch --allgit reset --hard origin/master git pull
Mode avance rapide
, Git générera un nouveau commit lors de la fusion, afin que les informations sur la branche puissent être vues à partir de l'historique de la branche. 🎜$ git cherry-pick \<commithash></commithash>
a - b - c - d Master \ e - f - g Feature
Demande de fusion
, sélectionnez le contenu de la branche dont nous avons besoin, puis choisissez de fusionner. \# 切换到 master 分支 $ git checkout master\# Cherry pick 操作 $ git cherry-pick f
Contenus de différents succursales, telles que les suivantes : 🎜Git is a distributed version control system. Git is free software distributed under the GPL. Git has a mutable index called stage. Git tracks changes of files.>>>>>> feature1
git fetch origingit checkout "master"git merge --no-ff "feature1"
git push origin "master"
其他方法为:
保留本地最新修改,并拉取仓库中 的代码到本地
git stash git pull origin master git stash pop
git reset --hard git pull origin master # 或git fetch --allgit reset --hard origin/master git pull
git cherry-pick
命令的作用,就是将指定的提交commit
应用于其他分支。
$ git cherry-pick \<commithash></commithash>
上面命令就会将指定的提交commitHash
,应用于当前分支。这会在当前分支产生一个新的提交,当然它们的哈希值会不一样。
举例来说,代码仓库有master
和feature
两个分支。
a - b - c - d Master \\ e - f - g Feature
现在将提交f
应用到master
分支。
\# 切换到 master 分支 $ git checkout master\# Cherry pick 操作 $ git cherry-pick f
上面的操作完成以后,代码库就变成了下面的样子。
a - b - c - d - f Master \\ e - f - g Feature
从上面可以看到,master
分支的末尾增加了一个提交f。
git cherry-pick
命令的参数,不一定是提交的哈希值,分支名也是可以的,表示转移该分支的最新提交。
$ git cherry-pick feature
上面代码表示将feature
分支的最近一次提交,转移到当前分支。
Cherry pick
支持一次转移多个提交。
$ git cherry-pick \<hasha> \<hashb></hashb></hasha>
上面的命令将 A
和 B
两个提交应用到当前分支。这会在当前分支生成两个对应的新提交。
如果想要转移一系列的连续提交,可以使用下面的简便语法。
$ git cherry-pick A..B
上面的命令可以转移从 A
到 B
的所有提交。它们必须按照正确的顺序放置:提交 A
必须早于提交 B
,否则命令将失败,但不会报错。
注意,使用上面的命令,提交 A
将不会包含在 Cherry pick
中。如果要包含提交 A
,可以使用下面的语法。
$ git cherry-pick A^..B
`git cherry-pick`命令的常用配置项如下。 #### -e,--edit 打开外部编辑器,编辑提交信息。 #### -n,--no-commit 只更新工作区和暂存区,不产生新的提交。 #### -x 在提交信息的末尾追加一行`cherry picked from commit ...`,方便以后查到这个提交是如何产生的。 #### -s,--signoff 在提交信息的末尾追加一行操作者的签名,表示是谁进行了这个操作。 #### -m parent-number,--mainline parent-number 如果原始提交是一个合并节点,来自于两个分支的合并,那么 `Cherry pick` 默认将失败,因为它不知道应该采用哪个分支的代码变动。 `-m`配置项告诉 Git,应该采用哪个分支的变动。它的参数`parent-number`是一个从1开始的整数,代表原始提交的父分支编号。 ```bash $ git cherry-pick -m 1 \<commithash></commithash>
上面命令表示,Cherry pick
采用提交commitHash
来自编号1的父分支的变动。
一般来说,1号父分支是接受变动的分支,2号父分支是作为变动来源的分支。
如果操作过程中发生代码冲突,Cherry pick
会停下来,让用户决定如何继续操作。
(1)–continue
用户解决代码冲突后,第一步将修改的文件重新加入暂存区(git add .
),第二步使用下面的命令,让 Cherry pick
过程继续执行。
$ git cherry-pick --continue
(2)–abort
发生代码冲突后,放弃合并,回到操作前的样子。
(3)–quit
发生代码冲突后,退出 Cherry pick
,但是不回到操作前的样子。
Cherry pick
也支持转移另一个代码库的提交,方法是先将该库加为远程仓库。
转移另一个代码库的提交
$ git remote add target git://gitUrl
上面命令添加了一个远程仓库target
。
然后,将远程代码抓取到本地。
$ git fetch target
上面命令将远程代码仓库抓取到本地。
接着,检查一下要从远程仓库转移的提交,获取它的哈希值。
$ git log target/master
最后,使用git cherry-pick
命令转移提交。
$ git cherry-pick \<commithash></commithash>
在实际开发中,我们应该按照几个基本原则进行分支管理:
首先,master
分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;
其次,干活都在dev
分支上,也就是说,dev
分支是不稳定的,到某个时候,比如1.0版本发布时,再把dev
分支合并到master
上,并在master
分支发布1.0版本;
小伙伴们每个人都在dev分支上干活,每个人都有自己的分支,时不时地往dev分支上合并就可以了。
在开发过程中,bug 就像家常便饭一样。有了 bug 就需要修复,在 Git 中,由于分支是如此的强大,所以,每个 bug 都可以通过一个新的临时分支来修复,修复后,合并分支,然后将临时分支删除。
当你接到一个修复一个代号101的 bug 的任务时,很自然地,你想创建一个分支 issue-101
来修复它,但是,等等,当前正在dev
上进行的工作还没有提交:
$ git status On branch dev Changes to be committed: (use "git reset HEAD \<file>..." to unstage) new file: hello.py Changes not staged for commit: (use "git add \<file>..." to update what will be committed) (use "git checkout -- \<file>..." to discard changes in working directory) modified: readme.txt</file></file></file>
并不是你不想提交,而是工作只进行到一半,还没法提交,预计完成还需1天时间。但是,必须在两个小时内修复该 bug,怎么办?
幸好,Git还提供了一个stash
功能,可以把当前工作现场“储藏”起来,等以后恢复现场后继续工作:
$ git stash Saved working directory and index state WIP on dev: f52c633 add merge
现在,用git status
查看工作区,就是干净的(除非有没有被Git管理的文件),因此可以放心地创建分支来修复 bug。
首先确定要在哪个分支上修复 bug,假定需要在master
分支上修复,就从master
创建临时分支:
$ git checkout master Switched to branch 'master'Your branch is ahead of 'origin/master' by 6 commits. (use "git push" to publish your local commits)$ git checkout -b issue-101 Switched to a new branch 'issue-101'
现在修复bug,需要把“Git is free software …”改为“Git is a free software …”,然后提交:
$ git add readme.txt $ git commit -m "fix bug 101"[issue-101 8842ff5] fix bug 101 1 file changed, 1 insertion(+), 1 deletion(-)
修复完成后,切换到master
分支,并完成合并,最后删除issue-101
分支:
$ git switch master Switched to branch 'master'Your branch is ahead of 'origin/master' by 6 commits. (use "git push" to publish your local commits)$ git merge --no-ff -m "merged bug fix 101" issue-101 Merge made by the 'recursive' strategy. readme.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
太棒了,原计划两个小时的 bug 修复只花了5分钟!现在,是时候接着回到dev
分支干活了!
$ git switch dev Switched to branch 'dev'$ git status On branch dev nothing to commit, working tree clean
工作区是干净的,刚才的工作现场存到哪去了?用git stash list
命令看看:
$ git stash list stash@{0}: WIP on dev: f52c633 add merge
工作现场还在,Git 把stash
内容存在某个地方了,但是需要恢复一下,有两个办法:
一是用git stash apply
恢复,但是恢复后,stash
内容并不删除,你需要用git stash drop
来删除;
另一种方式是用git stash pop
,恢复的同时把stash
内容也删了:
$ git stash pop On branch dev Changes to be committed: (use "git reset HEAD \<file>..." to unstage) new file: hello.py Changes not staged for commit: (use "git add \<file>..." to update what will be committed) (use "git checkout -- \<file>..." to discard changes in working directory) modified: readme.txt Dropped refs/stash@{0} (5d677e2ee266f39ea296182fb2354265b91b3b2a)</file></file></file>
再用git stash list
查看,就看不到任何stash
内容了:
$ git stash list
你可以多次stash
,恢复的时候,先用git stash list
查看,然后恢复指定的stash
,用命令:
$ git stash apply stash@{0}
在master
分支上修复了bug
后,我们要想一想,dev
分支是早期从master
分支分出来的,所以,这个bug
其实在当前dev
分支上也存在。
那怎么在dev
分支上修复同样的bug
?重复操作一次,提交不就行了?在 Git 中还有比这更简单的方法可以实现。
同样的 bug,要在dev
上修复,我们只需要把8842ff5 fix bug 101
这个提交所做的修改“复制”到dev
分支。注意:我们只想复制8842ff5 fix bug 101
这个提交所做的修改,并不是把整个master
分支merge
过来。
为了方便操作,Git 专门提供了一个cherry-pick
命令,让我们能复制一个特定的提交到当前分支:
$ git branch\* dev master $ git cherry-pick 8842ff5[dev 0944c8c] fix bug 101 1 file changed, 1 insertion(+), 1 deletion(-)
Git 自动给dev
分支做了一次提交,注意这次提交的commit
是0944c8c
,它并不同于master
的8842ff5
,因为这两个commit
只是改动相同,但确实是两个不同的commit
。用git cherry-pick
,我们就不需要在dev
分支上手动再把修 bug 的过程重复一遍。
有些聪明的童鞋会想了,既然可以在master
分支上修复bug
后,在dev
分支上可以“重放”这个修复过程,那么直接在dev
分支上修复 bug,然后在master
分支上“重放”行不行?当然可以,不过你仍然需要git stash
命令保存现场,才能从dev
分支切换到master
分支。
在开发过程中,除了 bug 外,也还会有无穷无尽的新的功能要不断添加进来。
添加一个新功能时,你肯定不希望因为一些实验性质的代码,把主分支搞乱了,所以,每添加一个新功能,最好新建一个feature
分支,在上面开发,完成后,合并,最后,删除该feature
分支。
现在,你终于接到了一个新任务:开发代号为Vulcan
的新功能,该功能计划用于下一代星际飞船。
于是准备开发:
$ git switch -c feature-vulcan Switched to a new branch 'feature-vulcan'
5分钟后,开发完毕:
$ git add vulcan.md $ git status On branch feature-vulcan Changes to be committed: (use "git reset HEAD \<file>..." to unstage) new file: vulcan.md $ git commit -m "add feature vulcan"[feature-vulcan d12cf23] add feature vulcan 1 file changed, 3 insertions(+) create mode 100644 vulcan.md</file>
切回dev
,准备合并:
$ git switch dev
一切顺利的话,feature
分支和bug
分支是类似的,合并,然后删除。
但是!就在此时,接到上级命令,因经费不足,新功能必须取消!虽然白干了,但是这个包含机密资料的分支还是必须就地销毁:
$ git branch -d feature-vulcan error: The branch 'feature-vulcan' is not fully merged. If you are sure you want to delete it, run 'git branch -D feature-vulcan'.
销毁失败。Git 友情提醒,feature-vulcan
分支还没有被合并,如果删除,将丢失掉修改,如果要强行删除,需要使用大写的-D
参数。。
现在我们强行删除:
$ git branch -D feature-vulcan Deleted branch feature-vulcan (was d12cf23).
终于删除成功!
推荐学习:《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!