SSH

用于本地和远程仓库的授权、验签

type ssh-keygen -t rsa -C "youremail@example.com" ，这会在本地创建.ssh目录，并在该目录下生成本地SSH公钥和私钥
在github远程仓库的SSH KEY里添加本地公钥（登陆github,选择settings-ssh key)，用于本地对远程仓库发起push操作的验签，以及本地拉取远程仓库代码操作的授权
单台机器（MAC地址唯一）只需要生成一次SSH KEY，即可完成与特定git账号下的git服务端加密、验签

git全局配置

git config –global user.emai …
git config –global user.name “…”
可以用git config –list查看全局global信息。

创建本地仓库

git init 会在当前文件夹创建本地仓库

本地关联远程仓库

git remote add origin git@github.com:dcbupt/java.git
origin指代远程仓库
删除远程仓库：git remote rm origin
查看本地关联的远程仓库：git remote -v

本地仓库的三个空间

首先，本地文件夹下还没add的文件存在于工作区空间
add后的文件位于暂存区空间
commit后的文件位于分支空间。

commit id

每次commit，git会分配一个唯一的commit id。分支空间里有一个HEAD指针唯一指向最新一次的commit。
可以理解为：HEAD = the newest commit id。
HEAD^指向上一次commit的commit id。

推送 & 拉取

拉取：git pull 远程仓库名远程分支名：本地分支名
例子：git pull origin master:master
推送：git push 远程仓库名本地分支名：远程分支名

.gitignore

作用是指定本地的一些文件和文件夹不属于git版本控制的范围内

git常用指令

git status的作用是检查这三个空间的状态。它的逻辑是：工作空间里出现的新文件或者被修改过的文件必须移动到暂存空间，暂存空间的文件必须移动到分支空间。
git reset --hard HEAD^ 的作用是让HEAD指针指向前一个commit id。效果是你最近一次commit对文件所做的修改失效，该文件回退到上上次提交后的状态。
git log --pretty=oneline的作用是查看所有commit id和commit内容。最上面的一个ID就是最近一次的commit id，也是HEAD指向的ID。注意如果你改变了HEAD指针，例如让HEAD指向前一个commit id，则最新一次的commit就消失了，git log也查不到。
git reflog的作用是记录每一次HEAD变更所做的操作，即使因为执行git reset --hard ...而被淹没的commit id也能在这里查到。
git reset --hard commit id的作用是让本地回退到某一次commit提交后的状态。结合reflog可以自由进行版本回退。
git reset file的作用是你add到暂存空间的文件撤回到工作空间。一般是你对文件做了修改后add，但你不满意还想继续修改于是就取回到工作空间。但前提是还没有commit到分支空间，一旦文件被commit，则文件不会存在于暂存空间。
git checkout file的作用是对工作空间里的文件做的修改执行撤销，一般是你对文件修改后不满意想重新修改，于是撤销掉以前所有的修改。如果你add了，那么 checkout返回给你的是暂存区的文件，如果你没有add，那么checkout返回给你的是上一次你commit进分支空间的文件。如果你在工作空间误操作rm了文件，依然可以git checkout file来实现恢复文件，原理同上。
git rm file会删除工作空间和分支空间的这个文件，接下来你需要commit一下才最终完成这次delete操作。
git rm --cached file可以删除暂存区的文件。
git rm+git commit -am如果本地有很多文件需要删除，同时也要删除分支空间里对应的文件，那么git rm+git commit会比较麻烦，这时可以用git rm+git commit -am的方式，因为git commit -m不会向分支空间提交rm的修改，需要参数-am。

多分支

首先，在一个git init的目录下是可以创建多个分支的。默认的是master分支。
git checkout -b dcddc创建并切换到了dcddc分支。
相当于git branch dcddc + git checkout dcddc
理解HEAD指针在多分支里的作用
其实HEAD指针不是指向commit的，HEAD指针指向当前分支，当前分支指向commit。所以你切换到了其他分支后，head分支就指向当前分支，你的commit操作只发生在当前分支上，当你checkout回另一个分支后，HEAD又指向那个分支，而那个分支指向的commit并不是另一分支指向的commit，所以你可以在dcddc下写代码并commit进度，等完工后再合并master分支和dcddc分支，这样master分支也就追上了dcddc分支的进度，然后你再push到github就OK了。
合并分支的操作：git merge dcddc （在master )
删除dcddc分支：git branch -d dcddc

rebase

使用场景

开发一个新需求，基于master拉出一个新分支a，然后fetch并checkout到本地。
开发期间，有些其他的需求陆续上线，因此master有新的merge commit，因此分支a与master分叉了。
为了保持分支a与master的同步性，需要不定期将master的新commit合并到分支a，此时rebase就能发挥作用了。
rebase主要用来跟上游同步

与merge的区别：

rebase后，自己的commit依然会顶到commit history的顶部（待验证）
rebase可能会需要多次解conflict，merge只会解一次（因此建议保持每周都rebase的习惯）

用法：
git checkout a
git rebase origin master

原理：
git rebase会把a分支里的每个提交(commit)取消掉，并且把它们临时保存为补丁(patch)(这些补丁放到”.git/rebase”目录中),然后把a分支更新为最新的master分支，最后把保存的这些补丁应用到a分支上。
因此，在rebase的过程中，也许会出现冲突(conflict). 在这种情况，Git会停止rebase并会让你去解决冲突；在解决完冲突后，用”git-add”命令去更新这些内容的索引(index), 然后，你无需执行 git-commit,只要执行:
git rebase --continue
这样git会继续应用(apply)余下的补丁。
在任何时候，你可以用–abort参数来终止rebase的行动，并且a分支会回到rebase开始前的状态。
git rebase --abort