赞
踩
本文内容总结自gitcode的git入门。
单分支:
一开始的时候,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 origin
git checkout -b "feature1" "origin/feature1"
Git 用<<<<<<<,=======,>>>>>>>
标记出不同分支的内容,例如下面的内容:
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.
<<<<<<< HEAD
Creating a new branch is quick & simple.
=======
Creating a new branch is quick AND simple.
>>>>>>> feature1
git fetch origin
git 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 --all
git reset --hard origin/master
git pull
git cherry-pick
命令的作用,就是将指定的提交commit
应用于其他分支。
$ git cherry-pick \<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\>
上面的命令将 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\>
上面命令表示,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
也支持转移另一个代码库的提交,方法是先将该库加为远程仓库。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。