Git学习札记

Posted 2020-06-17

 首先理解几个基本概念：

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>”:可以删除一个远程标签。