git几个区域图
$$.初始化
git init //初始化本地git仓库（创建新仓库）
git config --global user.name "xxx" //配置用户名
git config --global user.email "xxx@xxx.com" //配置邮件
附加： git merge -Xignore-space-change test //合并代码，忽略空格修改，可避免格式化代码带来的冲突
$$.创建本地分支：git branch a // git checkout -b a
$$.本地分支推送远程，并将本地与远程分支关联：
git push --set-upstream origin b
$$.删除分支
git branch -d/-D 分支名 //删除本地
$ git push origin --delete/-d <BranchName> //删除远程
$ git branch --merged 已经合并过的分支
$$.提交
git add . //增加当前子目录下所有更改过的文件至缓存区
git commit -m 'xxx' //提交
git commit -am 'xxx' //上面两句的合并简写
$$. revert一次提交 【HEAD向前移】
git revert [commit 哈希值]
git push
//产生一条新的记录，之前的推送commit记录也还在。
//如果需要将revert的内容再次回滚回来。只需要再次revert之前的记录。
git revert [上一次revert生成的commit哈希值]
$$.revert一次合并
git revert -m 1【要撤销的那条merge线的编号，从1开始计算】 [merge commit 哈希值]
执行操作之后，会生成一条记录，之后再次revert这条记录代码就回来了。
看git graph图
执行操作之后生成的记录
$$. reset
回到指定的HEAD,把HEAD向后移动了一下。并且HEAD之后的记录都会删除。
git reset [回到指定的hash] //如果不加--hard 会使代码放入工作区，会导致需要手动清除工作区的一些东西。
git reset --hard [回到指定的hash] //使用这个，本地也会一并删除reset掉的代码
git push -f //需要强制提交。
此操作执行之后，东西比较不好找回来，所以要慎重使用。
如果实在想要恢复回来。那就是只能去git log文件里面查找回复的
hash。
.git/logs/refs/分支文件里面找到想要恢复到的commit节点。
然后执行：
git reset --hard [commit hash]
$$. 放弃本地【工作区】所有修改，文件的删除，添加
git checkout -- filename //可以把工作区的某个文件的修改撤回到上一次add或者commit的状态，不过filename不能省略。
git checkout -- // 不加文件名来查看当前工作区修改了哪些文件，这个只是针对工作区的问题。
e.g.:git checkout a.js //放弃指定文件修改
git checkout . //放弃所有修改， 只能放弃本地【工作区】修改，并不能放弃已经git add 之后在缓存区的修改。
/**
git clean是从工作目录中移除没有track的文件.
通常的参数是git clean -df:
-d表示同时移除目录,-f表示force,因为在git的配置文件中, clean.requireForce=true,如果不加-f,clean将会拒绝执行.
**/
git clean -df //只能放弃本地【工作区】添加删除，并不能放弃已经git add 之后在缓存区的操作。
$$. 承接5 那么我们如何把缓存区的修改给删除掉。其实这就是4的操作了。我们只要返回到最初的版本就好了。
git reset【commit hash】 filename 可以把add到缓存区的文件回退到工作区，也就是把add filename这个过程给回退了，这并不会修改文件的内容，这只是要把缓存区的某个文件变成和HEAD这个当前版本相同，也就是说如果你多次add，这会回退到第一次add的过程，和上面的操作一样，也可以不带上文件名来查看哪些文件被添加到了缓存区；
e.g.: git reset 92add090e36390cec5c6d0847755f1de1d0f429f //这个操作会将缓存区的内容都回退到工作区。 git status查看一下，你就能看出来。 如果不想要了
git checkout . && git clean -df //删除工作区新增文件或者修改
如果想要一步到位： git reset --hard 92add090e36390cec5c6d0847755f1de1d0f429f。
$$. 工作区执行merge操作之后，又不想要merge了。
git merge --abort
cherry-pick
$$.cherry-pick
操作过程相当于将该提交导出为补丁文件，然后在当前HEAD上重放，形成无论内容还是提交说明都一致的提交，冲突是可能的。
另外，cherry-pick不是你描述的那样，他会重新生成一个commit的，只是描述完全一样。
git checkout branch2
git cherry-pick c的哈希码
git cherry-pick e的哈希码
git cherry-pick f的哈希码
一篇很好的关于git rebase 和git merge合并代码的区别总结
$$.git rebase和merge 区别和应用场景
对于两个分支而言，rebase和merge没有区别，
1.但是rebase更干净，因为log hisitory是线性的，但commit不一定按日期先后排，而是local commit总在后面
2.merge之后history变得比较复杂，但是commit按日期排序
总结：普通分支合并master分支用rebase，master分支合并普通分支用merge.
$$.交互式rebase
这种方法通常用于在向别处推送提交之前对它们进行重写。
交互式rebase提供了一个简单易用的途径让你在和别人分享提交之前对你的提交进行分割、合并或者重排序。
在把从其他开发者处拉取的提交应用到本地时，你也可以使用交互式rebase对它们进行清理。
对于我们主要用途可能就是合并commit,修改不好看的commit文案之类的。用法比较难描述，直接上图。我以最近三次的commit为例子。
1.修改最近一次commit描述
git rebase -i HEAD^
image.png
点击i进入编辑模式。根据上面的指令描述来。
将pick该成r ---> wq保存退出，会弹出如下内容
image.png
进入编辑模式 修改你的提交文案 然后 wq。
image.png
修改成功 git log
已经变了
同步远程 git push -f 即可
下面我们一起来看看执行git rebase -i HEAD^^^^ 得到的图：
image.png
红框里面的信息表示从你上一次推送操作起有4个提交。每个提交都用一行来表示，行格式如下：
(action) (partial-sha) (short commit message)
现在你可以将操作（action）改为'edit'（使用提交，但是暂停以便进行修正）或者'squash'（使用提交，但是把它与前一提交合并），默认是'pick'（使用提交）。你可以对这些行上下移动从而对提交进行重排序。当你退出编辑器时，git会按照你指定的顺序去应用提交，并且做出相应的操作（action）。
网友评论