1.git-merge相关的选项参数
1.1摘要
在git-merge命令中,有以下三种使用参数:
git merge [-n] [--stat] [--no-commit] [--squash] [--[no-]edit] [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]] [--[no-]rerere-autoupdate] [-m <msg>] [<commit>...]
git merge <msg> HEAD <commit>...
git merge --abort
1.2git-merge简介
git-merge命令是用于从指定的commit(s)合并到当前分支的操作。
注:这里的指定commit(s)是指从这些历史commit节点开始,一直到当前分开的时候。
git-merge命令有以下两种用途:
- 用于git-pull中,来整合另一代码仓库中的变化(即:git pull = git fetch + git merge)
- 用于从一个分支到另一个分支的合并
假设下面的历史节点存在,并且当前所在的分支为“master”:
7810BEAB-4124-48D7-A185-CD0A1626CFC8.png
那么git merge topic
命令将会把在master分支上二者共同的节点(E节点)之后分离的节点(即topic分支的A B C节点)重现在master分支上,直到topic分支当前的commit节点(C节点),并位于master分支的顶部。并且沿着master分支和topic分支创建一个记录合并结果的新节点,该节点带有用户描述合并变化的信息。
即下图中的H节点,C节点和G节点都是H节点的父节点。
C8CF6D76-B282-42E6-ABAF-E481223835FB.png
1.3git merge <msg> HEAD <commit>...
命令
该命令的存在是由于历史原因,在新版本中不应该使用它,应该使用git merge -m <msg> <commit>....
进行替代
1.4git merge --abort
命令
该命令仅仅在合并后导致冲突时才使用。git merge --abort
将会抛弃合并过程并且尝试重建合并前的状态。但是,当合并开始时如果存在未commit的文件,git merge --abort
在某些情况下将无法重现合并前的状态。(特别是这些未commit的文件在合并的过程中将会被修改时)
警告:运行
git-merge
时含有大量的未commit文件很容易让你陷入困境,这将使你在冲突中难以回退。因此非常不鼓励在使用git-merge
时存在未commit的文件,建议使用git-stash
命令将这些未commit文件暂存起来,并在解决冲突以后使用git stash pop
把这些未commit文件还原出来。
2.参数
本部分用于介绍git-merge
命令中使用的参数
2.1--commit
和--no-commit
--commit
参数使得合并后产生一个合并结果的commit节点。该参数可以覆盖--no-commit
。--no-commit
参数使得合并后,为了防止合并失败并不自动提交,能够给使用者一个机会在提交前审视和修改合并结果。
2.2--edit
和-e
以及--no-edit
--edit
和-e
用于在成功合并、提交前调用编辑器来进一步编辑自动生成的合并信息。因此使用者能够进一步解释和判断合并的结果。--no-edit
参数能够用于接受自动合并的信息(通常情况下并不鼓励这样做)。
如果你在合并时已经给定了
-m
参数(下文介绍),使用--edit
(或-e
)依然是有用的,这将在编辑器中进一步编辑-m
所含的内容。
旧版本的节点可能并不允许用户去编辑合并日志信息。
2.3--ff
命令
--ff
是指fast-forward命令。当使用fast-forward模式进行合并时,将不会创造一个新的commit节点。默认情况下,git-merge
采用fast-forward模式。