背景
毕业作业有一些年头了，之前在写作业代码或许给开源项目贡献的时分，提交代码都不是很标准，乃至能够说十分的随意，想到什么就提交什么，根本没有办理提交记载的概念或许想法（当你身边的人都不怎样在意的时分，你也很难在意的）。作业了一段时间之后，对代码提交标准的要求高了不少，由于我发现，当我把这件事情做好的时分，会让作业变得顺利一些。有一天处理倒腾git处理了一些问题，就想到把这些东西沉淀下来，共享出去。所以写下了这篇文章。倒也不是多么高大上的代码技巧或许炫技，只是共享之前遇到的一些git commit问题，和共享一些见地。
cases and thoughts
1. 处理事务开发代码和测验联调代码
幻想一下这样一个场景：有一个需求开发完了，准备和其他同事联调这个需求。慎重起见，联调期间期望能够观测到这个需求运转过程中的大部分细节。比如上下游的输入输出是什么样的，运转到某段代码他的表现应该是什么样的。假如没有测验到位，就上线了，一不小心造成了什么事故，问题可就大了。别的，假如在测验过程中遇到了肉眼看不出来的bug，这时分也需求打一些日志去分析。
这个时分问题就来了，调试日志代码一般情况下是不能上线的，究竟一个体系在要害的当地打上日志方便线上排查bug就好，处处打日志估量服务器也很难顶得住。这个时分怎样办呢？我会经过下面的比如来演示下面处理的办法。
首要咱们假设有一个库房。叫做git-experiment.并且当前有一个提交，是一个名为Feature-1的需求的相关开发改动。经过检查git提交日志咱们能够看到：
下面让咱们看看具体怎样处理这个问题。
1.1 直接在这个分支上写，merge进master之前去掉这些提交记载
第一个做法其实比较好了解，就直接在本来的分支上加嘛，测验完了把这些关于测验的提交记载去掉就好。下面这幅图模拟的情形是：
- 加上了打印log逻辑。
- 在测验中发现了问题，又添加了一个commit来修复这个bug。
测验完毕，这个时分咱们看到上面这样一份提交记载，应该怎样办呢，用git revert？是不太行的喔，由于revert会生成一个新的提交记载。像下面这姿态。
这姿态尽管代码没了，可是这份提交记载看起来就会很古怪。很明显，在这个场景中，咱们实际上只需求关于Feature-1代码改动和关于bug fix的代码改动。这个时分推荐用git rebase。比如在上面这个case中，能够运转：
git rebase -i HEAD~2
这时分咱们将看到下面这个景象，这些你挑选好的commit会倒序排列在你面前让你操作。
d代表要放弃这个commit，pick代表保留。承认好你的操作之后退出。可能会遇到代码抵触，处理抵触之后能够履行git rebase –continue。完事之后咱们能够看到。
Perfect，这就是咱们想要的。可是，这个办法的缺陷就是在本来的分支上引入了新的不确定性，并且在去除日志代码的时分，最好期待没有抵触出现，假如出现了抵触，一个不小心把事务需求的代码搞掉了，那就乐滋滋了。这种做法相当于把一切的危险都会集在一个分支上面。
1.2 切换一个分支，在新分支上写测验相关的代码
这儿介绍第二种办法。咱们能够在本来的基础上切换出一个新的分支来，专门用来做测验相关的作业，原有的分支专心在事务开发和bug fix。
然后给这个分支加上测验相关的日志打印代码。
这时分能够看一下这个分支上面的提交日志。
这时分咱们就能够拿这个分支去布置，然后和别人联调测验了。假如在测验过程中发现了bug，需求修复怎样办？这个好办，在本来的分支上做bug fix，然后测验分支cherry-pick bug fix的commit就好了。让咱们来看看。
commit bug fix的代码后，切换到测验分支，cherry pick这个commit。
有抵触处理抵触。弄完之后让咱们来看看这个分支的log。
这样你就能够继续用这个分支做bug fix之后的测验啦。这样做的好处就是，你的开发分支始终是安全且洁净的。抵触都在测验分支处理。
2. 让每一个commit都有含义
信任我们都听过这样的一句话，”代码是写给人看的，其次它能在电脑上跑起来。”。无论是作业仍是开源项目。假如你写的代码会给别人仔细的review，那么让别人知道你的代码代表什么，要做什么，就显得尤为要害。不要由于做这个需求时间就不去做，假如别人没看懂你的commit或许需求你修正一下commit信息，这些现在省下来的时间后边仍是会还回去的。就比如上面这个比如的最终状态是这样的：
实际上，我个人认为这两个commit应该合并成一个，其实看代码的人看到这个bug fix的commit还会好奇这个提交的上下文是什么，可能脑海里会涌现出这样一个问题：bug是什么？不要让别人想太多，假如他很困惑，他就会来问你。最好能够经过commit信息告诉他你做了什么。
提到这儿你就会想了，我把一切代码都弄成一个commit，再给上比较好的commit信息是不是就好了。看情况吧，假如一个需求你写了好多代码，上千行这姿态。这时分我认为应该拆分一下commit，比如这个时分你能够拆分红好几个小的commit，再分别给提供commit信息。看代码的人能够经过你的commit信息拆解你的需求，细分到每一个小需求去审视你的代码，这也节省了别人的时间。
总结
上面是在我在作业中遇到的一些关于代码提交的问题和想法， 在这儿共享给到我们。期望对我们有所协助。
