Git学习札记

      首先理解几个基本概念：
origin：默认远程版本库；
master:默认开发分支；

（1）git log
查看提交日志。会显示出你的每一次提交。如图：


。

（2）git log --pretty=oneline
如果你觉得上面输出内容太多太杂，可以使用这个命令。信息会在一行显示。如图：


。

（3）git branch
查看当前分支。如图，我现在在master分支。


。

（4）git reflog
查看提交历史，以便确定你要回滚到哪个版本。根据前面的hash值或者HEAD可以进行回滚。


。

（5）git diff 文件名
查看你某个文件的修改前后对比。红色“-”为删除，绿色“+”为插入。修改过程就是先删除，后插入。


。

（6）git reset --hard 7位哈希值
回滚到某个版本。7位哈希值可以通过git reflog查到。如图：



。

（7）cat 文件名
查看某个文件的内容。如图：


。

（8）git checkout -- 文件名
把该文件在工作区的修改全部撤销，这里有两种情况：
一种是文件修改后还没有放到暂存区（也就是还没有执行git add）,现在撤销修改就回到和版本库一样的状态；
一种是文件修改后已经添加到暂存区（已经执行了git add），又做了修改，撤销修改就回到了添加到暂存区后的状态；
总之，就是让这个文件回到最近执行git commit或git add时的状态。
注意中间的"--"很重要，没有“--”，就变成了“切换到另一个分支”的命令。



.

（9）git reset HEAD 文件名
把暂存区的修改撤销掉（unstage）,重新放回工作区。
git reset命令既可以回退版本，也可以把暂存区的修改回退到工作区，当我们用HEAD时，表示最新的版本。


。

（10）git rm 文件名
在工作区中增加一个文件，并添加到本地分支中。但是如果你不需要这个文件了。你直接用"rm 文件名"删除该文件。这个时候，Git知道你删除了文件，因此，工作区和版本库就不一样了。git status可以查看当前的情况。
此时有两个选择：
1.确实要从版本库中删除该文件，就用命令"git rm 文件名"删掉，并且git commit提交，此时该文件就真正从版本库中删除了。

2.另一种情况是删错了，因为版本库中还有该文件，所以可以把误删的文件恢复到最新版本，“git checkout -- 文件名”。“git checkout”就是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。


。


.

（11）git remote add origin ***github仓库地址
关联一个远程仓库。在第一次提交之前进行。

（12）git remote -v
查看远程仓库的地址。

（13）git remote rm origin

删除原来的远程仓库地址。

（14）git push -u origin master
第一次推送master分支的所有内容。

（15）git push origin master
以后每次的修改使用该命令。

（16）关于分支：
在版本回滚里，每次提交，Git都把他们串成一条时间线，这条时间线就是一个分支。到目前为止，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD指针严格来说不是指向提交，而是指向master，master才是指向提交的。所以，HEAD指向的就是当前分支。

git checkout -b dev
创建一个dev分支，然后切换到dev分支。


.

（17）上述命令相当于以下两条命令：
git branch dev  :新建一个dev分支；
git checkout dev   :切换到dev分支；

（18）git branch
查看本地所有分支。前面带星号*的表示当前所在的分支。


。

注意：
git branch -a：查看所有分支，包括本地分支和远程分支。
本地分支用绿色和黑色显示，绿色表示你现在所在分支，黑色是其他分支。远程分支用红色表示。

git branch -r  :查看远程所有分支，都以红色显示。

git branch -d dev：删除本地某一个分支，如dev分支。

（20）合并分支
1. git checkout -b dev ：首先创建一个dev分支，并切换到dev分支；



2.进行修改文件，然后提交。


.

3.cat main.m
dev分支下

发现里面我增加了“//dev分支”这几个字；



4.git checkout master：现在dev分支的工作完成了，我们就可以切换到master分支。


.

5.cat main
master分支下。
发现里面并没有“//dev分支”，因为那个提交是在dev分支上，而maser分支此刻的提交点并没有变。


。.

6. git merge dev
把dev分支的工作成果合并到master分支上。
git merge 命令用于合并指定分支到当前分支。合并后，在查看文件内容，就可以看到，和dev分支的最新提交是完全一样的。


。

7.上面的"Fast-forward"信息，Git告诉我们，这次的合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。

8.git branch -d dev
合并完成后，就可以放心的删除dev分支了。


.

9.分支小结：因为创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果使一样的，但过程更安全。

（21）解决冲突
1.git checkout -b testConflict
git add .
git commit -m "testConflict提交，测试冲突"

新建一个testConflict分支，用来测试冲突。并修改其中的一行代码；提交。


.

2. git checkout master
git add .
git commit -m "测试"
在master分支下，同样修改同一行代码，并进行提交；


.

3.git merge testConflict
此时两个分支各自有了新的提交，此时，Git无法执行“快速合并”，只能视图把各自的修改合并起来，但这种合并就会有冲突。此时合并的结果如下：


.

4.git 提示我们有冲突。可以通过"git status"命令来查看哪个文件有冲突。如图：


。

5. 我们可以直接去冲突文件查看，可以看到如下代码：


。
其中<<<<<,=====,>>>>>>，这种地方表示是有冲突的。可以手动进行修改，修改后代码如下：


。
然后在master下进行提交即可。如图：


。

6.git log --graph
可以看到分支的合并情况，如图：


。
注意上面："Merge: 5da331c 1225c73",  是把后面的分支合并到前面的分支。也就是把testConfict分支合并到master分支上。这个7位数是commit后面那串数字的前7位。
commit 后面那串数字是hash值，使用的是SHA-1哈希算法，40位的长度。是根据你的文件内容计算出的hash值。

7.git log --graph --pretty=oneline
可以让输出在一行显示，如图：


.

8. 最后把testConflict分支删除即可。注意：当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。

（22）分支管理策略
1.通常合并分支时，如果可以，Git会使用Fast Forward快进模式，但这种模式下，删除分支后，会丢掉分支信息。我们可以使用--no-ff方式的git merge.
2.git checkout -b dev
仍然创建并切换到dev分支。
3.git add .
git commit -m "merge --no-ff"
在dev分支下进行提交。
4.git checkout master
切换到master分支下。
5.git merge --no-ff -m "merge with no-ff" dev
合并使用--no-ff参数，表示禁用Fast Forward。因为本次合并要创建一个新的commit，所以加上-m参数。

6.git log --graph --pretty=oneline --abbrev-commit
查看分支历史。注意使用--abbrev-commit 参数可以把commit的40为hash值缩短为7位，方便查看。



7.分支策略：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活。干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master上发布1.0版本。每个人都有自己的分支，时不时往dev分支上合并就可以了。
合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出曾经做过合并。而fast forward合并就看不出曾经做过合并。默认是“fast forward”.

（23）Bug分支
每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。
1.git stash
把当前的工作现场储藏起来，等以后回复现场后继续使用。
git stash list
查看当前分支中存储的stash


。

2.git status
此时在dev分支中查看工作区，是干净的。因此可以放心的创建分支来修复bug。


。

3.git checkout master
git checkout -b issue-101
首先确定要在哪个分支上修复bug，假定要在master分支上修复，就从master创建临时分支。


。

4.在issue-101上修复bug，提交。


。

5.git checkout master
git merge --no-ff -m "修复完成，合并issue-101分支" issue-101

git log --graph --pretty=oneline --abbrev-commit
合并bug分支。


。

6.git branch -d issue-101
删除bug分支。


。

7.git checkout dev
git status
再次回到dev分支干活，工作现场是完全干净的。


。

8.git stash list
查看当前的工作现场。Git把stash内容存储在某个地方了。我们需要恢复现场。


.

9.git stash pop
git stash list

在恢复内容的同时把stash的内容也删了。


.

10.git stash apply
git stash drop
这两行命令相当于“git stash pop”. 用“git stash apply”恢复，但是恢复后，stash内容并不删除，需要用“git stash drop”来删除。


。

11.git add .
git commit -m "在dev分支提交"
把dev分支工作的内容提交。等下要合并到master分支。


。

12.git checkout master
git merge --no-ff -m "合并dev分支的工作内容" dev
如果有冲突，则手动修改。


。

13.git add .
git commit -m “合并了dev后的master提交”
git branch -d dev
手动解决冲突后，在master提交，然后删除dev分支。


。

14.小结：修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除。
当手头工作没有完成时，先把工作现场git stash 一下，然后去修复bug，修复后，再git stash pop，回到工作现场。

（24）Feature分支
1.添加一个新功能，你肯定不希望因为一些实验性质的代码，把主分支搞乱了。所以，每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，最后删除feature分支。
当开发完成后，如果在还没有合并之前，这个新功能不需要了。就需要删除该分支。
git branch -d feature-net


.

2.git branch -D feature-net
注意：1中的删除无法成功，因为该分支还没有被合并，如果删除，将丢失修改。如果要进行强行删除，要使用"git branch -D feature-net"命令。


。
3.小结：开发一个新的feature,最好新建一个分支。如果要丢弃一个没有被合并过的分支，可以通过git branch -D <name>强行删除。

（25）git remote

查看远程库的信息。
git remote -v
显示详细信息。显示了可以抓取和推送的origin地址。如果没有推送的权限，就看不到push的地址。


。

（26）多人协作
1.推送分支：就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上。
git push origin master
如果要推送到其他分支，比如dev，就改成：
git push origin dev
但是并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些分支不需要呢?
--master分支是主分支，因此要时刻与远程同步；
--dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；
--bug分支只用于在本地修复bug，没必要推送到远程；
--feature分支可以看实际开发需要。

2.抓取分支
git checkout -b dev origin/dev

创建远程origin的dev分支到本地。

git branch --set-upstream dev origin/dev
设置本地dev与远程origin/dev分支的链接。

3.多人协作的模式：
--首先，可以试图用git push origin branch-name推送自己的修改；
--如果推送失败，因为远程分支比你的本地分支版本新，需要先用git pull视图合并；
--如果合并有冲突，则解决冲突，并在本地提交；
--没有冲突或者解决冲突后，再用git push origin branch-name推送就能成功。
--如果git pull提示“no tracking information”，则说明本地分支和远程分支的链接关系没有创建，用命令"git branch --set-upstream branch-name origin/branch-name".
4.小结
--查看远程库信息，使用“git remote -v”;
--本地新建的分支如果不推送到远程，对其他人就是不可见的；
--从本地推送分支，使用“git push origin branch-name”,如果推送失败，先用"git pull"抓取远程的新提交；
--在本地库创建和远程分支对应的分支，使用“git checkout -b branch-name origin/branch-name”,本地和远程分支的名称最好一致；
--建立本地分支和远程分支的关联，“git branch --set-upstream branch-name origin/branch-name”;
--从远程抓取分支，使用git pull.如果有冲突，要先处理冲突。

（27）标签管理
发布一个版本时，我们通常先在版本库中打一个标签，这样，就唯一确定了打标签时刻的版本。将来无论什么时候，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。所以，标签也是版本库的一个快照。
Gitde 标签虽然是版本库的快照，但其实他就是指向某个commit的指针。所以，创建和删除标签都是瞬间完成的。

（28）创建标签
git tag v1.0
切换到要打标签的分支上，执行“git tag v1.0”,默认是打在最新提交的commit上。

git tag

查看所有的标签。


.

git tag v1.1 commit_id
标签可以打在任意一个提交上。

git show v1.0
查看标签信息。


.

（29）操作标签
1.git tag -d v1.0
因为创建的标签都只存储在本地，不会自动推送到远程。所以，打错的标签可以在本地安全删除。


。

2.git push origin v1.0
推送某个tag到远程分支。


。

3.git push origin --tags
一次性推送全部尚未推送到远程的本地标签。


。

4.如果标签已经推送到远程，要删除远程标签就麻烦一点，先从本地删除
git tag -d v1.0
然后从远程删除。删除命令也是push，但是格式如下：
git push origin :refs/tags/v1.0


.

5.小结：
--命令“git push origin <tagname>”:可以推送一个本地标签；
--命令“git push origin --tags”:可以推送全部未推送的本地标签；
--命令"git tag -d <tagname>":可以删除一个本地标签；
--命令“git push origin :refs/tags/<tagname>”:可以删除一个远程标签。

本文参考廖雪峰 Git教程。感谢！

github主页：https://github.com/chenyufeng1991  。欢迎大家访问！