GIT 学习

网址指路：git教程

版本回退

• HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令git reset --hard commit_id。

• 穿梭前，用git log可以查看提交历史，以便确定要回退到哪个版本。

• 要重返未来，用git reflog查看命令历史，以便确定要回到未来的哪个版本。

撤销修改

$ git checkout -- readme.txt

命令git checkout -- readme.txt意思就是，把readme.txt文件在工作区的修改全部撤销，这里有两种情况：

一种是readme.txt自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态；

一种是readme.txt已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。

总之，就是让这个文件回到最近一次git commit或git add时的状态。

小结

又到了小结时间。

场景1：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout -- file。

场景2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git reset HEAD^ <file>，就回到了场景1，第二步按场景1操作。

场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节，不过前提是没有推送到远程库。

git restore 是git 2.23版本新增的命令，用来代替身兼数职的git checkout。功能是一样的。

从暂存区恢复工作区，

git resotre --worktree readme.txt

从master恢复暂存区

git restore --staged readme.txt

从master同时恢复工作区和暂存区

git restore --source=HEAD --staged --worktree readme.txt

删除文件

先手动删除文件，然后使用git rm 和git add效果是一样的。

小结

命令git rm用于删除一个文件。如果一个文件已经被提交到版本库，那么你永远不用担心误删，但是要小心，你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容。

配置远程仓库

Git配置多个ssh

 ssh-keygen -t rsa -C '3557727504@qq.com' -f C:\Users\1\.ssh\gitee_id_rsa
 ssh-keygen -t rsa -C '3190105300@zju.edu.cn' -f C:\Users\1\.ssh\github_id_rsa

创建与合并分支

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

小结

Git鼓励大量使用分支：

查看分支：git branch

创建分支：git branch <name>

切换分支：git checkout <name>或者git switch <name>

创建+切换分支：git checkout -b <name>或者git switch -c <name>

合并某分支到当前分支：git merge <name>

删除分支：git branch -d <name>

解决冲突

小结

当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。

解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。

用git log --graph命令可以看到分支合并图。

分支管理

分支策略

在实际开发中，我们应该按照几个基本原则进行分支管理：

首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；

你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

所以，团队合作的分支看起来就像这样：

小结

Git分支十分强大，在团队开发中应该充分应用。

合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。

Bug分支

同样的bug，要在dev上修复，我们只需要把4c805e2 fix bug 101这个提交所做的修改“复制”到dev分支。注意：我们只想复制4c805e2 fix bug 101这个提交所做的修改，并不是把整个master分支merge过来。

为了方便操作，Git专门提供了一个cherry-pick命令，让我们能复制一个特定的提交到当前分支：

$ git branch
* dev
  master
$ git cherry-pick 4c805e2
[master 1d4b803] fix bug 101
 1 file changed, 1 insertion(+), 1 deletion(-)

Git自动给dev分支做了一次提交，注意这次提交的commit是1d4b803，它并不同于master的4c805e2，因为这两个commit只是改动相同，但确实是两个不同的commit。用git cherry-pick，我们就不需要在dev分支上手动再把修bug的过程重复一遍。

小结

修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；

当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场；

在master分支上修复的bug，想要合并到当前dev分支，可以用git cherry-pick <commit>命令，把bug提交的修改“复制”到当前分支，避免重复劳动。

rebase

小结

• rebase操作可以把本地未push的分叉提交历史整理成直线；
• rebase的目的是使得我们在查看历史提交的变化时更容易，因为分叉的提交需要三方对比。

创建标签

小结

• 命令git tag <tagname>用于新建一个标签，默认为HEAD，也可以指定一个commit id；
• 命令git tag -a <tagname> -m "blablabla..."可以指定标签信息；
• 命令git tag可以查看所有标签。

操作标签

小结

• 命令git push origin <tagname>可以推送一个本地标签；
• 命令git push origin --tags可以推送全部未推送过的本地标签；
• 命令git tag -d <tagname>可以删除一个本地标签；
• 命令git push origin :refs/tags/<tagname>可以删除一个远程标签。

小结

• 命令git push origin <tagname>可以推送一个本地标签；
• 命令git push origin --tags可以推送全部未推送过的本地标签；
• 命令git tag -d <tagname>可以删除一个本地标签；
• 命令git push origin :refs/tags/<tagname>可以删除一个远程标签。