Git 保存的不是文件的变化或者差异,而是一系列不同时刻的文件快照,某一次的提交指向这处时刻的文件快照,看起来就像每次提交都保存了当时的文件,连续的提交形成一条长链
分支 指向某一个特定的提交,不同的分支可以指向同一个提交,此时它们是相同的;不指向一个提交的分支,按提交的顺序排序,指向提交靠前的分支在指向提交靠后的分支前面;由于不同的分支都可以提交新的提交,这些就打乱原来链状的提交,开成分叉,这时回到原来的分支,需要合并,丢弃不用分支要删除,当然首先得创建分支。
X-k_@HK ~/Desktop/Hk (master)
$
windows 下的 Git 的命令行除了当前仓库的路径,后面的括号里显示的就是当前分支
master 是 Git 默认创建的分支,在第一次提交或克隆自动创建
git branch name 创建分支,下面创建 dev 分支
$ git branch dev
查看分支,带 * 的是当前分支
$ git branch
dev
* master
切换分支
$ git checkout dev
Switched to branch 'dev'
现在可以在 dev 分支上开发,待开发到一定程度时,没什么BUG,比较稳定时,可以合并到主分支上。
e.g
在 dev 分支修改 t.c (添加一行 "float c;")后提交,切回 master 分支合并到 master 分支。
git merge dev 把 dev 合并到当前分支
$ git commit -a -m float
[dev 06a9033] float
1 file changed, 1 insertion(+)
$ git status
On branch dev
nothing to commit, working directory clean
$ git checkout master
Switched to branch 'master'
$ git merge dev
Updating 11891ac..06a9033
Fast-forward
t.c | 1 +
1 file changed, 1 insertion(+)
$ git log --format="%h %s" --graph
* 06a9033 float
* 11891ac add t.c
* 9201c98 update readme.md
* 2e07671 first commit
现在提交还在一条链上,合并只是把 master 分支的指向 dev 分支指向的提交
那么现在试下在 master 分支和 dev 分支同时修改 t.c 并提交,然后合并,看看会发生什么
在 master 分支修改 float > long,提交 ‘long’
$ git log --format="%h %s" --graph
* a779b07 long
* 06a9033 float
* 11891ac add t.c
* 9201c98 update readme.md
* 2e07671 first commit
在 dev 分支修改 float > double ,提交 ‘double’
$ git log --format="%h %s" --graph
* 87531a3 double
* 06a9033 float
* 11891ac add t.c
* 9201c98 update readme.md
* 2e07671 first commit
dev 合并到 master 分支
$ git merge dev
Auto-merging t.c
CONFLICT (content): Merge conflict in t.c
Automatic merge failed; fix conflicts and then commit the result.
合并遇到冲突,此时 Git 做了合并,但是没有自动地创建一个新的合并提交。 Git 会暂停下来,等待你去解决合并产生的冲突。用 git status 命令来查看那些因包含合并冲突而处于未合并(unmerged)状态的文件:
$ git status
On branch master
You have unmerged paths.
(fix conflicts and run "git commit")
Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified: t.c
no changes added to commit (use "git add" and/or "git commit -a")
Git 会在有冲突的文件中加入标准的冲突解决标记,这样你可以打开这些包含冲突的文件然后手动解决冲突。出现冲突的文件会包含一些特殊区段,看起来像下面这个样子:
int a;
int b;
<<<<<<< HEAD
long c;
=======
double c;
>>>>>>> dev
"这表示 HEAD 所指示的版本(也就是你的 master 分支所在的位置,因为你在运行 merge 命令的时候已经检出到了这个分支)在这个区段的上半部分(======= 的上半部分),而 dev 分支所指示的版本在 ======= 的下半部分。
保留了其中一个分支的修改,并且 <<<<<<< , ======= , 和 >>>>>>> 这些行要完全删除了。"
修复后,正常提交就可以了,这时的历史是这样的
$ git log --format="%h %s" --graph
* 0451275 merge
|
| * 87531a3 double
* | a779b07 long
|/
* 06a9033 float
* 11891ac add t.c
* 9201c98 update readme.md
* 2e07671 first commit
最后的选项 --graph 添加了一些ASCII字符串来形象地展示分支、合并历史
现在 dev 分支没有了,就可以删掉了
$ git branch -d dev
Deleted branch dev (was 87531a3).
如果无法删除,可以尝试使用 -D 强制删除
git branch 还可以用选项 -a 查看全部分支(包括远程分支),
-v 查看分支和分支最后一次提交
高级参考
- 分支Git Git 分支 - 分支简介
- 分支合并 Git 分支 - 分支的新建与合并
- 高级合并 Git 工具 - 高级合并
- 分支开发工作流参考 Git 分支 - 分支开发工作流