git重点知识梳理

工作链路

工作区(update)-----add---->暂存区----commit----->本地仓库-----push—>远程仓库

Git常用命令

• git init 在工作目录中初始化新仓库
• git clone [url] 从现有仓库克隆
• git status 检查当前文件状态/哪些更新还没有暂存？有哪些更新已经暂存起来准备好了下次提交？
• git add [filename] 跟踪新文件，未跟踪的文件意味着Git在之前的快照（提交）中没有这些文件
• git diff 查看尚未暂存的文件更新了哪些部分（此命令比较的是工作目录中当前文件和暂存区域快照之间的差异，也就是修改之后还没有暂存起来的变化内容）
• git diff --cached 已经暂存起来的文件和上次提交时的快照之间的差异
• git commit -m [msg] 提交更新（每一次运行提交操作，都是对你项目作一次快照，以后可以回到这个状态，或者进行比较）
• git commit -a -m [msg] Git 就会自动把所有已经跟踪过的文件暂存起来一并提交，从而跳过 git add 步骤
• git commit --amend 用于修改最近一次提交,会放弃最近一次的commit id。
• git rm [filename] 从已跟踪文件清单中移除（确切地说，是从暂存区域移除),并连带从工作目录中删除指定的文件，这样以后就不会出现在未跟踪文件清单中了
• git rm --cached [filename] 仅是从跟踪清单中删除
• git mv file_from file_to 移动文件
• git log 在提交了若干更新之后，又或者克隆了某个项目，想回顾下提交历史
• git commit --amend 修改最后一次提交
• git reset HEAD … 取消已经暂存的文件
• git checkout – … 取消文件的修改
• git remote 查看当前的远程库，origin 远程库，Git 默认使用这个名字来标识你所克隆的原始仓库
• git remote add [shortname] [url] 添加一个新的远程仓库
• git fetch [remote-name] 从远程仓库中拉取所有你本地仓库中还没有的数据
• git pull 自动抓取数据下来，然后将远端分支自动合并到本地仓库中当前分支
• git push [remote-name] [branch-name] 推送数据到远程仓库(如果在你推数据前，已经有其他人推送了若干更新，那你的推送操作就会被驳回。你必须先把他们的更新抓取到本地，合并到自己的项目中，然后才可以再次推送)
• git remote show [remote-name] 查看远程仓库信息
• git remote rename 修改某个远程仓库在本地的简称
• git remote rm [remote-name] 移除远端仓库
• git tag 列出已有标签
• git tag -a v1.0 -m ‘my version 1.0’ 创建一个含附注类型的标签
• git show v1.0 查看相应标签信息
• git branch branchname 创建新的分支
• git checkout branchname 切换到其他分支(Git 会把工作目录的内容恢复为检出某分支时它所指向的那个提交对象的快照。它会自动添加、删除和修改文件以确保目录的内容和你当时提交时完全一样)
• git checkout -b branchname 新建并切换到该分支
• git checkout master && git merge branchname 合并分支到master分支
• git branch -d branchname 删除分支
• git branch 列出分支清单
• git push [远程名] :[分支名] 删除远程分支
• git push --force 覆盖服务器上的历史
• git stash save “message…” 暂存， 作用：当本地要切到另外一个分支时，但当前分支尚有代码不想被reset掉，那么可以把当前分支的代码暂存
• git stash apply 恢复暂存，作用：将暂存后的代码重新恢复回来，stash不会删除
• git stash list 查看所有stash
• git stash pop [–index][] pop指定的stash，stash会删除
• git stash clear 清除所有的stash
• git rebase snack/master 将snack/master的最新代码rebase到当前所在分支上

git merge vs. git rebase

以前在使用git开发时，都会偏向每个开发需求新起分支，不定期使用git pull更新分支代码，以保证与master分支代码的同步。久而久之，项目分支树变得盘根错节，无比复杂。因为
git pull = git fetch + git merge， 所以会出现各种复杂的分支合并路线。
为了避免这种情况，git提供rebase命令。

git pull等价于git fetch, git merge FETCH_HEAD
git pull --rebase等价于git fetch, git rebase FETCH_HEAD

https://git-scm.com/book/en/v2/Git-Branching-Rebasing中对选择使用merge还是rebase有下面的看法
对于git这个工具，有两类典型的观点：

1.一种观点认为git应该事无巨细地记录下项目开发过程中的所有事情，这种情况下merge是对应的方法，因为merge把差异合并过程都以一个单独的commit记录下来了，后来的维护者在看的时候能真正理解当时开发时发生的事情。

2.另一种观点认为git应该记录“有意义”的事情，比如说我实现了某一项功能，我可以把它记录成一整个单独的commit，至于开发这个功能中发生过哪些事无巨细的小事情，发生了哪些曲折回环的合并过程，git不应该关心。

git-scm https://git-scm.com/book/en/v2/Git-Branching-Rebasing的观点应该是一种折中，对于那些只是在你本地的改动，可以使用rebase。比如说你花了很多天开发一个功能，在本地每天都会记录一个commit（可以设想成是为了防止丢失。。），最后在提交的时候，可以rebase成一个单独的commit，这个过程只发生在本地，所以任何操作都不会影响到远端，rebase完全是没问题的。但是对于在已经提交到远端的commit，就不太适合再pull下来，rebase成比较清晰的一条commit历史之后，再force push到远端了。因为有很多人在一起操作着这个仓库，你不顾别人擅自改动远端并强制覆盖，会发生什么事就不用我说了。。

遇到冲突时的分支合并
如果在不同的分支中都修改了同一个文件的同一部分，Git 就无法干净地把两者合到一起（逻辑上说，这种问题只能由人来裁决。例如：

$ git merge iss53
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.
Git 作了合并，但没有提交，它会停下来等你解决冲突。要看看哪些文件在合并时发生冲突，可以用 git status 查阅：

$ git status
On branch master
You have unmerged paths.
  (fix conflicts and run "git commit")

Unmerged paths:
  (use "git add <file>..." to mark resolution)

        both modified:      index.html

no changes added to commit (use "git add" and/or "git commit -a")
任何包含未解决冲突的文件都会以未合并（unmerged）的状态列出。Git 会在有冲突的文件里加入标准的冲突解决标记，可以通过它们来手工定位并解决这些冲突。可以看到此文件包含类似下面这样的部分：

<<<<<<< HEAD
<div id="footer">contact : [e-mail]</div>
=======
<div id="footer">
  please contact us at [e-mail]
</div>
>>>>>>> iss53
可以看到 ======= 隔开的上半部分，是master分支中的内容，下半部分是在 iss53 分支中的内容。解决冲突的办法无非是二者选其一或者由你亲自整合到一起。比如你可以通过把这段内容替换为下面这样来解决：

<div id="footer">
please contact us at [e-mail]
</div>
这个解决方案各采纳了两个分支中的一部分内容，而且我还删除了 <<<<<<<，======= 和 >>>>>>> 这些行。在解决了所有文件里的所有冲突后，运行 git add 将把它们标记为已解决状态（译注：实际上就是来一次快照保存到暂存区域）。因为一旦暂存，就表示冲突已经解决。

git stash

非常好用的功能，之前不知道这个功能的时候在某些场景下非常的low，备份代码，然后拷贝。会了它之后再也不用担心了。
应用场景：
1 当正在dev分支上开发某个项目，这时项目中出现一个bug，需要紧急修复，但是正在开发的内容只是完成一半，还不想提交，这时可以用git stash命令将修改的内容保存至堆栈区，然后顺利切换到hotfix分支进行bug修复，修复完成后，再次切回到dev分支，从堆栈中恢复刚刚保存的内容。
2 由于疏忽，本应该在dev分支开发的内容，却在master上进行了开发，需要重新切回到dev分支上进行开发，可以用git stash将内容保存至堆栈中，切回到dev分支后，再次恢复内容即可。
总的来说，git stash命令的作用就是将目前还不想提交的但是已经修改的内容进行保存至堆栈中，后续可以在某个分支上恢复出堆栈中的内容。这也就是说，stash中的内容不仅仅可以恢复到原先开发的分支，也可以恢复到其他任意指定的分支上。git stash作用的范围包括工作区和暂存区中的内容，也就是说没有提交的内容都会保。

Git分支创建规范约定

主分支

master分支：存放随时可供生产环境中的部署的代码
develop分支：存放当前最新开发成果的分支，当代码足够稳定时可以合并到master分支上去。

辅助分支

feature分支：开发新功能使用，最终合并到develop分支或抛弃掉
release分支：做小的缺陷修正、准备发布版本所需的各项说明信息
hotfix分支：代码的紧急修复工作

Git查看每行代码的最后提交人

查找背锅人专用：
git blame 文件名
格式：
commit ID | 代码提交作者 | 提交时间 | 代码位于文件中的行数 | 实际代码

a08d47080 (dongyong 2019-09-04 11:38:39 +0800   2) 
a08d47080 (dongyong 2019-09-04 11:38:39 +0800   3) import java.util.ArrayList;
a08d47080 (dongyong 2019-09-04 11:38:39 +0800   4) import java.util.Comparator;
6407bd1a2 (dongyong 2019-09-11 22:13:00 +0800   5) import java.util.HashMap;
a08d47080 (dongyong 2019-09-04 11:38:39 +0800   6) import java.util.List;
a08d47080 (dongyong 2019-09-04 11:38:39 +0800   7) import java.util.Map;