标签:style 使用 io strong 文件 for ar 问题
分支是什么?
分支就像树分出的树枝,不同的是,它们之间可以互相合并。
将版本的推进想象成一个链表的伸长: version 1.0 ==》 version 2.0 ==》version3.0 。
master是主要的分支基本上用于发布产品。你可以从master分出一个dev,在上面创建新功能,或者修bug然后调试。最后再合并到master里面。就像下面这样。
master分支: version 1.0=========》version 2.0===...
\ / (merge)
dev分支: \=version 1.5=/=========...
甚至还可以有更多分支
master分支: version 1.0=========》version 2.0===...
\ / (merge)
dev分支 : \→→→O→→→→ O=========...
\ / (merge)
Hanson分支: \ -> 修BUG ->/
分支不主动删除是不会消失的。
(另外,当前版本可以认为是一个指针指向链表最后一个节点,reset (第二章) 命令 就是把指针往前移,revert命令还是向后移。 )
如何管理分支?
1.创建与查看分支:
现在我们要创建一个名为dev的分支。(Dev在软件开发中多用于开发软件的代号,与Beta(测试版)的意思相近,其意思为"开发中的版本" 即development version或development edition etc。)创建分支的命令是 $git branch dev 移动到指定分支的命令是 $git checkout dev
也有一个将两个命令合起来的简便方法:$git checkout -b dev 这样就直接创建并转到分支dev上。(相当于当前master版本的一个副本。)
在windows上的git bash上可以通过每行命令上面那行最后的括号确定现在是哪个分支。在linux上没有。
那如何查看当前有哪些分支和确定在哪条分支上呢? 输入 :$git branch ,会列出所有分支,分支前面的星号就是当前所在分支。
$git branch
*dev
master
2.合并与删除分支:
将工作区内容修改后 使用 $git add hello.txt 和 $git commit hello.txt -m "modify" 上传就dev分支
然后 $git checkout master 切换到master分支后,输入 $git merge dev 这样dev就会融入master。
若是想删除掉dev分支 输入$ git branch -d dev 即可。(如果没有合并就想要废弃这条分支 需要使用$git branch -D dev)
在使用merge命令时,可以添加参数 -m "blabla" 也就是添加备注。
还有一个参数是 --no-ff :
顾名思义 这个参数的意思是 不要FF模式。
FF 即 fast forward ,这种模式下,删除分支后,会丢掉分支信息。 就像这个分支从来没存在过一样。
而如果使用 --no-ff 就会我开头举的例子,Hanson分支被删除后仍然存在于记录中。会在merge时生成一个新的commit 。
这条命令会是这样
git merge --no-ff -m "merge with no-ff" Hanson
另外还有一些原则需要遵守
master分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;
那在哪干活呢?干活都在dev分支上,也就是说,dev分支是不稳定的,到某个时候,比如1.0版本发布时,再把dev分支合并到master上,在master分支发布1.0版本;
你和你的小伙伴们每个人都在dev分支上干活,每个人都有自己的分支,时不时地往dev分支上合并就可以了。
或许你已经想到了这个问题 “要是合并的时候有冲突怎么办?”
比如两个分支不约而同地修改了同一行。 在master上 你改了 hello.txt 最后一行,在dev上也改了hello.txt最后一行都提交上去了。
git是这样做的:合并的时候git发现了这样的冲突,它只好试图将两行合起来,并 提示你:
Auto-merging hello.txt
CONFLICT (content): Merge conflict in hello.txt
Automatic merge failed; fix conflicts and then commit the result.
你从这知道 需要你手动更改文件合并 然后提交。
输入$git status 可以查看冲突的文件
# On branch master
# Your branch is ahead of ‘origin/master‘ by 1 commits. (这一句是说当前的master超前远程仓库的master一个commit)
#
# Unmerged paths:
# (use "git add/rm <file>..." as appropriate to mark resolution)
#
# both modified: hello.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
打开对应的 hello.txt 文件 发现你分别修改的两行是以这样的形式存在在文件中:
<<<<<<< HEAD
………的……
=======
………地……
>>>>>>> dev
这样就标记了不同的分支中的内容 然后需要你手动更改并 $git add hello.txt 与commit -m 提交。
使用 $git log带参数可以看到合并情况 关于参数以后再详细记录笔记。
$ git log --graph --pretty=oneline --abbrev-commit
3.临时储存工作现场
你常常会遇到这样的情况,你正在自己的分支上做一个新功能,但是有一个BUG需要在一小时内解决。你不可能直接切换到一个新分支来修复bug,这样你做了大半天的工作就没了。也不可能在这个分支上修复提交,因为等你新功能写完还得好久。
输入 $ git stash save "work in progress for foo feature" (save命令是用于备注,并非必须)吧 你会发现工作区变成了当前分支上次提交的样子,这时候你就可以放心的创建分支修复BUG了。
修复之后,你想回到dev继续工作了!
输入 $git stash list
下面就会显示stash的列表,像这样:stash@{0}: WIP on dev: …………
怎么恢复呢?有两个办法:
一是用git stash apply恢复,但是恢复后,stash内容并不删除,你需要用git stash drop来删除,
默认是恢复最后一次保存。如果你多次保存,想恢复前面保存的现场。就得根据stash list找到前面的标志恢复,像这样
git stash apply stash@{1} ;
另一种方式是用$git stash pop,恢复的同时把stash内容也删了,这种方法只能恢复最后一次stash。
$git stash clear 用于清除stash列表。
Git 学习笔记<分支管理> (三),布布扣,bubuko.com
标签:style 使用 io strong 文件 for ar 问题
原文地址:http://www.cnblogs.com/imyijie/p/3896971.html