如何享受一个美好的git开发体验
摘取之前写的新人文档留个纪念。
前置学习：
熟练使用 oh-my-zsh下 git 简写， 开始的时候会有些别扭，但是熟练起来之后会让你的操作异常帅气: git 简写 枚举。
# 常用简写速查
alias ga='git add'
alias gb='git branch'
alias gba='git branch -a'
alias gbd='git branch -d'
alias gcam='git commit -a -m'
alias gcb='git checkout -b'
alias gco='git checkout'
alias gcp='git cherry-pick'
alias gd='git diff'
alias gfo='git fetch origin'
alias ggpush='git push origin $(git_current_branch)'
alias ggsup='git branch --set-upstream-to=origin/$(git_current_branch)'
alias glgp='git log --stat -p'
alias gm='git merge'
alias gp='git push'
alias gst='git status'
alias gsta='git stash save'
alias gstp='git stash pop'
- 双管齐下
命令行。培育一个用着快捷、顺手的命令行环境； 图形工具 (source tree 等); - 学会使用vim: 花半个小时来学习一下vim的基本操作，会对之后的开发很有益处；
起手式：美好的开始从master分支开始
项目分支一般区分 master(online环境)、**其他环境, 除master 外的其他环境都有存在异常代码的风险，所以【规定】从master checkout 一条分支作为feature brach，从而减少异常代码对你本次开发的影响；
如何写一个规范的commit cz
-
commit 本质上只要描述清楚你本次提交即可，建议使用英文描述；
-
事上本没有路，走的人多了，也就有了路。 见识使用 git-cz （commitizen & cz-conventional-changelog ）来定向改善你的commit内容；
如此青春俏皮的commit跃然纸上，谁不爱呢？
分支管理 rebase & merge
-
和conflict 做朋友
新手朋友对于分支管理合并时总会感到有点恐慌，总怕在合并代码一不小心覆盖了别人的代码，从而造成奇异的bug。学会阅读和处理冲突，本质上冲突反映了两个分支的差异性，如果分支差异性过大，是不是嗅到一丝bad smell呢？
学会用可视化的方式来解决冲突，明确的对比两个版本之间的差异，从而减少出错的概率； -
学会取舍 - git diff
区分rebase & merge时，比较的基准代码版本，从而理解当前分支合传入分支的区别；
rebase 执行流程
merge 执行流程
-
学会使用 git cherry-pick
当两个分支差异过大时，使用cherry-pick 无外乎也是一种不错的方式，这种”捡🍒“的合代码方式，磨平了两个差异性巨大的分支合并时带来的问题，增量的合并使合并操作十分丝滑，但是需要注意的是gcp需要按照顺序进行，否则无尽的冲突就会向你袭来； -
做好一个”渣男“
如果你有一些修改暂时不准备提交，并且也不准备放弃。那么你可以临时把这些文件通过"stash"暂存起来，在执行完手头的操作之后，再从”备胎“堆栈中找到你刚才暂存的代码，重新进行编辑；
如何提一个 MR or PR
- gitlab 之 MR, github 之 PR
- release tag *
- ...
死亡操作：
-
从异常分支(例如：beta分支) checkout出来并开始开发，一个错误的开始很难走到每秒的结局。
死亡分支操作
- -f / --force (慎用)
- 不提交代码直接移除 / 回滚;
- rebase & merge 混用导致git tree 混乱；
- ...
ANTI-死亡操作
不要害怕使用git，你的任何操作都会被记录下来(前提是你要记得add)。
- reflog
- checkout . / -- file
- reset --hard / --soft
- revert
- blame
- ...
工作区域和流程
