Introduction branch
Many copy of a version control system is a form of support branch, the branch is similar to the project, for example, you do
a project code is well-written, and now need a new feature, you can not be in your written very good projects
which add modifications, but should copy the entire project to write code, and the branch is to realize this
function, the name of the branch is a lot of code that you copied from the name.
use branch can be separated from the main line of development work above to avoid the influence of the main line of development.
but many branch version control system is inefficient, they are completely create a copy of the source code directory
, for large projects, this is a waste of time, and very efficient branching model in Git branch is Git is a bright spot.
Branch locations
Recall that the directories Git, are the following
two of which are related to the branch, the branch is actually similar to the name of a variable of the pointer to the hash value of the object is filed, and the main branch is the default master, for example the following images
saved Git directory that is what the current HEAD branch is
saved inside the refs hash value of the object submitted final submission of each branch
Use branches
-
Creating a branch: git branch branch name
is to create a new pointer can be moved, and this is the branch, of course, this pointer is submitted to the object currently resides
you will find that although the creation of a pointer, HEAD points, or master, not It will automatically switch to the new branch
-
Switching branches:
| git checkout branch name | Switching branch |
| git checkout | What parameters are not, it is to display a list of branches was |
| git checkout -b branch name | The previous steps, we need to create a new branch, and then switch over, so the trouble, this command is done, the new branch and switch over |
Branch switching point to note:
①: switching branch will change three places: HEAD, staging area, the working directory
HEAD branch name change to switch the
staging area becomes the final staging area look like a branch of the switch
working directory change to switch the final version of the branches
so because of the above reasons, when switching branches to ensure that the state of the current branch is submitted, is
displayed in the implementation of all git status has been submitted to the state.
said here from three transition branch situation:
①: what you in on a new branch of a file, but you do not track it, in case there is no trace of the
switch back to the main line or switch to another branch, then the new file will track you go to the main line or
other branches Actually, this document does not belong to the main line or the other branches, which would result in contamination of the main line of code
or other branches. and this new file Why will follow you go to the main line or other branch of it, because you did not follow it, so it is not git scope of management, so switching branch, the working directory will not delete it
②: that you have a new track Construction documents, but did not submit, then switch branches. Already tracking will certainly be in the staging area,
you switch into the staging area file new branch will also be brought to the new branch, and the working directory new files will be brought to the new
branch, which will contaminate the new branch.
③: is already submitted documents, upgrade now need to be modified, the modified files you do not have to track and submit, wanted to switch branches
so git is not going to give you the switch, because the file before the modification has been submitted in this branch before, then you git consider the revised document must belong to this branch after modification, so we are not forced to switch to you, so that you have to be able to commit before switching .
- Delete branch (can not delete your own, have to switch to another directory)
| git branch -d 分支名 | 这个是删除已经合并的分支,如果分支没有合并,删除就会报错 |
| git branch -D 分支名 | 这个是强制删除分支,没有合并的分支也可以删除掉 |
| git log --oneline --decorate --graph --all | 这个是可以看整个项目得完整历史,因为切换到主线上,很多主线后面的分支的提交看不了,这个代码就可以看了 |
- 其他
| git branch -v | 以查看每一个分支的最后一次提交 |
| git branch 分支名 提交对象的hash值 | 新建一个分支并且使分支指向对应的提交对象 ,利用这个可以实现版本的回退,比如你的提交对象的hash值是第一个版本的,那么就回退到第一个版本 |
| git config --global alias.别名 “命令” | 这个是当git的命令很长的时候,我们可以给他配一个别名,注意:alias.后面直接加别名,不能空格,后面的命令是写git后面的命令,不用加git,命令要用""括起来,例如:git config --global alias.st status,配置后直接敲git st 和git status一样 |
| git reflog | 就是在版本库里面看所有的提交,包括删除的 |
- 一个使用例子
现在是主分支上面已经有两个稳定的代码就是Jane1.txt和jane2.txt,现在主分支
master指向jane2.txt,
然后你需要修改一个bug,所以创建了一个jing1的分支,在jing1分支上面打了代码jing1.txt和jing.txt,如下图:
然后现在你需要立即解决另外一个bug,所以你需要返回到主分支上面
再新建一个分支urgent,在里面打了jane3.txt和修改了jane1.txt,将这个紧急bug
修改好后测试没问题,应该合并到主分支上,如下图
这里因为urgent和master是在同一条线上的,就是master分支要合并的分支是在master的前面,这样子git就会简单地将HEAD指针向前移动,指向urgent最后的提交对象上面,这样合并不需要处理分歧,也叫做快进
现在处理完了urgent的问题,又回到jing1分支继续写代码,修改了jane1.txt的代码
完成后你又要将jing1分支和master合并,
这时合并就出现了问题了,因为jing1的jane1.txt代码在urgent分支修改过,在jing1分支也修改过,合并的时候就会出现分歧,
而且对于合并过urgent分支的master主分支来说,jing1分支就是过时的,因为master
已经升级过了,
这时jing1和master合并也叫典型合并,需要处理冲突,合并后会提示需要处理的
是哪一个文件代码,你对它进行修改,add,commit后就可以了
上面的逻辑代码如下:
镜风@▒龵 MINGW64 /g/git/workspace/1 (master)
$ git log --oneline --decorate --graph --all
* b238c63 (jing1) jing1.txt comitt for jing1
* a2e2d45 (HEAD -> master) jane2
* 7942d53 jane1
镜风@▒龵 MINGW64 /g/git/workspace/1 (master)
$ git checkout jing1
Switched to branch 'jing1'
镜风@▒龵 MINGW64 /g/git/workspace/1 (jing1)
$ git ls-files -s
100644 eeaa10d7dbd999222fb0557b3b8d7c1bd2c465d4 0 jane1.txt
100644 32b22f6bd6e40627e9502847ec7cf36a3bc87420 0 jane2.txt
100644 d82550eebd096160ee791e84cc4053c6214bf183 0 jing1.txt
镜风@▒龵 MINGW64 /g/git/workspace/1 (jing1)
$ git checkout master
Switched to branch 'master'
镜风@▒龵 MINGW64 /g/git/workspace/1 (master)
$ git checkout -b urgent
Switched to a new branch 'urgent'
镜风@▒龵 MINGW64 /g/git/workspace/1 (urgent)
$ git ls-files -s
100644 eeaa10d7dbd999222fb0557b3b8d7c1bd2c465d4 0 jane1.txt
100644 32b22f6bd6e40627e9502847ec7cf36a3bc87420 0 jane2.txt
镜风@▒龵 MINGW64 /g/git/workspace/1 (urgent)
$ vim jane1.txt
镜风@▒龵 MINGW64 /g/git/workspace/1 (urgent)
$ echo "jane3.txt" > jane3.txt
镜风@▒龵 MINGW64 /g/git/workspace/1 (urgent)
$ git add ./
warning: LF will be replaced by CRLF in jane1.txt.
The file will have its original line endings in your working directory
warning: LF will be replaced by CRLF in jane3.txt.
The file will have its original line endings in your working directory
镜风@▒龵 MINGW64 /g/git/workspace/1 (urgent)
$ git commit -m "jane1.txt的修改和jane3.txt增加 to urgent"
[urgent 114582a] jane1.txt的修改和jane3.txt增加 to urgent
2 files changed, 2 insertions(+)
create mode 100644 jane3.txt
镜风@▒龵 MINGW64 /g/git/workspace/1 (urgent)
$ git checkout master
Switched to branch 'master'
镜风@▒龵 MINGW64 /g/git/workspace/1 (master)
$ git merge urgent
Updating a2e2d45..114582a
Fast-forward
jane1.txt | 1 +
jane3.txt | 1 +
2 files changed, 2 insertions(+)
create mode 100644 jane3.txt
镜风@▒龵 MINGW64 /g/git/workspace/1 (master)
$ git checkout jing1
Switched to branch 'jing1'
镜风@▒龵 MINGW64 /g/git/workspace/1 (jing1)
$ ll
total 4
-rw-r--r-- 1 镜风 197121 7 3月 2 21:35 jane1.txt
-rw-r--r-- 1 镜风 197121 6 3月 2 14:04 jane2.txt
-rw-r--r-- 1 镜风 197121 30 3月 2 21:35 jing.txt
-rw-r--r-- 1 镜风 197121 8 3月 2 21:35 jing1.txt
镜风@▒龵 MINGW64 /g/git/workspace/1 (jing1)
$ vim jane1.txt
镜风@▒龵 MINGW64 /g/git/workspace/1 (jing1)
$ git commit -a -m "修改了jane1.txt to jing1分支"
[jing1 be620f2] 修改了jane1.txt to jing1分支
1 file changed, 1 insertion(+)
镜风@▒龵 MINGW64 /g/git/workspace/1 (jing1)
$ git checkout master
Switched to branch 'master'
镜风@▒龵 MINGW64 /g/git/workspace/1 (master)
$ git merge jing1
Auto-merging jane1.txt
CONFLICT (content): Merge conflict in jane1.txt
Automatic merge failed; fix conflicts and then commit the result.
镜风@▒龵 MINGW64 /g/git/workspace/1 (master|MERGING)
$ vim jane1.txt
镜风@▒龵 MINGW64 /g/git/workspace/1 (master|MERGING)
$ git add ./
镜风@▒龵 MINGW64 /g/git/workspace/1 (master|MERGING)
$ git status
On branch master
All conflicts fixed but you are still merging.
(use "git commit" to conclude merge)
Changes to be committed:
modified: jane1.txt
new file: jing.txt
new file: jing1.txt
镜风@▒龵 MINGW64 /g/git/workspace/1 (master|MERGING)
$ git commit -m "master合并jing1"
[master 37ea712] master合并jing1
镜风@▒龵 MINGW64 /g/git/workspace/1 (master)
$ git log --oneline --decorate --graph --all
* 37ea712 (HEAD -> master) master合并jing1
|\
| * be620f2 (jing1) 修改了jane1.txt to jing1分支
| * 22c6705 jing.txt的修改 to jing1
| * 83c7ef7 commit for jing.txt to jing1
| * b238c63 jing1.txt comitt for jing1
* | 114582a (urgent) jane1.txt的修改和jane3.txt增加 to urgent
|/
* a2e2d45 jane2
* 7942d53 jane1
典型合并后需要修改的代码的样子
分支模式
Generally divided into long-branch and branch characteristics
above picture is very clear, the uppermost mater is stable code the whole company combined
develop branch is that every programmer own code, but not directly at the time of modification modify develop branch above, but continue to create additional branch changes
the master branch and develop branches here are relatively stable, long-term branch is
following topic branch to branch every programmer is a feature or bug created a topic branch
Nature branch
In fact, the branch is a pointer to the variable commit objects, introduced earlier git folder
inside a folder refs, which is the preservation of the branch
such as this is to save the three branches, each branch here is a file, which is stored
hash value for each branch to submit a final object
in the directory is the HEAD file, which is stored in the branch HEAD currently points
every time a new commit objects when submitted, HEAD will move forward while pointing branches will change HREAD
