这是一个创建于 3384 天前的主题，其中的信息可能已经有所发展或是发生改变。
比如：在编辑文件 B 的时候，发现文件 A 有些地方写的不妥，然后就把 A 给改了，改 A 的时候发现文件 C 又有点问题，又顺手把 C 给改了。
改的三处都是不同功能的修改，当 A 、 B 、 C 都完工，要 push 代码的时候，是一个一个 add 写完 commit ，然后 push ，还是就 add .， commit 就针对 B 的写，然后 push ？
如果是后者，就会不妥吧，看 commit 的时候发现新增 B 这个功能怎么扯到 A 和 C 了？
改的三处都是不同功能的修改，当 A 、 B 、 C 都完工，要 push 代码的时候，是一个一个 add 写完 commit ，然后 push ，还是就 add .， commit 就针对 B 的写，然后 push ？
如果是后者，就会不妥吧，看 commit 的时候发现新增 B 这个功能怎么扯到 A 和 C 了？
 |
1
tracyone 2016 年 10 月 28 日 via iPhone
看心情
|
 |
2
GhostFlying 2016 年 10 月 28 日 via Android
一个一个，你也说不妥了
|
 |
3
Vindroid 2016 年 10 月 28 日
按功能划分提交吧
|
 |
4
malkavia 2016 年 10 月 28 日
一个一个，方便 codereview ，方便回 revert
|
 |
5
psklf 2016 年 10 月 28 日
>add .， commit 就针对 B 的写，然后 push ？
应该是你 commit 把所有的信息都写上 |
 |
6
cha0s 2016 年 10 月 28 日 via iPad
一次提交，写清楚就行了。需要单独 review 时候 cherry 就行
|
 |
7
Jiki 2016 年 10 月 28 日 via iPhone
一个个写回退方便点，清晰点……一起写就写具体点，加上 commit 详情也挺清楚的。
还有就是改动引发次生问题和修改的可能，以及心情▼_▼ |
 |
8
kevinzhwl 2016 年 10 月 28 日 via iPhone
看心情，另外改 b 的时候别瞎看 ac ，容易爱心泛滥。哈哈
|
 |
9
Layne 2016 年 10 月 28 日
按功能来
|
 |
10
happypy1 2016 年 10 月 28 日
原则上是不同目的的修改是放在不同的 commit 里的。
如果你的 a ， b ， c 的改动都是互不关联的话，不嫌麻烦，就分开放。 不过通过很多次实践证明，你省了一时的麻烦，将来就有更多呃麻烦来找你。自己掂量吧。 |
 |
11
tobeyouth 2016 年 10 月 28 日
如果这几个文件的修改是强关联的，还是一起提交比较好
|
 |
12
otakustay 2016 年 10 月 28 日  1
保证每个 commit 是能过 ci 和可运行的
|
 |
13
pagict 2016 年 10 月 28 日
多用 branch
|
 |
14
nailuoGG 2016 年 10 月 28 日
可以按功能来新建分支，就不会忘记自己改了哪些东西了。
|
 |
15
ycge234 2016 年 10 月 28 日 1
'每个提交都应该保持原子性'
|
 |
16
csdreamdong 2016 年 10 月 28 日
git amend
|
 |
17
9hills 2016 年 10 月 28 日
改 A 的时候发现 B 有其他问题，解决办法就是开个新的 branch ，只改 B 。当前的 branch ，只改 A
之后再 merge 到一起 |
Select Language