作为一名合格的软件工程师，不仅要知道如何设计并实现一个软件项目，还要知道如何在一个团队中合作开发一个项目。那么git是最为常用的版本控制工具了，下面就简单记录一下一些基本功能。这篇文章并不是一个基础教程，仅记录一些较为日常的命令。
创建工作进度及恢复
这是Git提供的一个很方便的功能。如果一个新功能开发到一半又需要转火更为紧急的需求，这时可以使用这个功能保存一下工作进度并重新检出一个干净的版本开发新需求，并在需要的时候从进度恢复。
git stash save "gallery-dev" # 保存一个名为gallery-dev的进度
git stash list # 显示保存的进度
git stash pop [--index] [<stash>] # 恢复某个工作进度并删除
git stash branch <branchname> <stash> # 根据工作进度创建分支
git stash apply [--index] [<stash>] # 恢复某个工作进度但不删除
git stash drop [<stash>] # 删除工作进度
git stash clear # 删除所有工作进度
基于分支的开发流程
在软件开发的过程中，我们经常需要开发各种各样的需求、修复各种各样的bug。为了使开发过程中解决各种问题代码清晰且互不干扰，前辈们发明了分支管理的结构。简单来说就是为不同种类的需求创建不同的分支，并且在需要发布这些更改时将其合并到主干。日常开发过程中我们可能需要3个分支，线上、开发和补丁。线上分支用于发布正式版，开发分支用于新功能的开发，补丁分支用于修复之前版本存在的问题。当然，也可以通过TAG的方式标记。这里
git checkout -b|-B <new_branch> [<start point>] # 从名为start point创建名为new_branch的分支
git checkout <branch> # 检出某一分支，也就是切换分支
git rebase <branch> # 将某一分支合并到当前分支，推荐用rebase，merge的话会让历史树变得不易回顾
获取当前短版本
有时候，我们需要与团队的其他成员交流bug的所在位置，除过文件信息外，版本信息也显得十分重要。如果单纯发送commit id的话，显得过长，不易阅读，这时，就可以使用较短的commit id。
git rev-parse --short HEAD
基于主干的开发流程
上面提到一种基于分支的开发流程，但基于分支开发有如下几个难以解决的问题：
- 分支维护时间较长时，合并非常困难。
- 上条因素导致开发人员不愿重构代码。
- 上条因素导致代码资产最终变得一文不值。
为了解决该问题，现在较为流行的做法是使用主干开发，并在代码逻辑中嵌入特性开发。这种开发模式非常灵活，比如很多编译型语言很早就支持了，比如C和CPP中的宏，Rust中的feature开关。
那么，基于主干的话，我们日常中的开发模式如下：
- 修改代码。
- 提交（commit）代码。
- 拉取 remote master，
git pull --rebase。 - 修复冲突（若有）
- 推送变更，
git push origin master。
代码检视流程
对于有的敏捷实践做的更好的公司或团队，一般会有一个代码检视（Code Review）的流程，用以在团队中形成更好的代码结构与规范、更好的代码熟悉度、更高效的工作节奏。如今，可以借助一些Git在线工具，让这个流程线上化，使其变得高效、一致。下面是一个采用这种流程的开发方式：
- 拉取最新 remote master，
git pull --rebase。 - 创建以故事卡号为名的分支，
git checkout -b STORY_ID。 - 修改代码。
- 提交（commit）代码。
- 推送变更至 remote 对应的分支，
git push origin STORY_ID。 - 在码云或其它平台上上创建合并至 master 的 Pull Request，并@相关责任人。
- 检视通过后通过步骤 1 进行确认。
- 检视不通过后回到步骤 3 进行修改。
以上，希望大家都能有个良好维护且清晰的代码。
