多人开发时使用 git，能使用“git add . ”这个命令吗？

[kidneyband]

我从事ios开发接近两个月了，代码管理使用的是git，我添加代码时都是使用git add . ，ios开发的同事看到后说不能这样添加，说容易出问题，请问各位是这样吗？我觉得git add . 之后commit的时候自然会显示文件的改变情况，和一个一个添加并没有什么区别。可是同事老揪着这个不放。烦

[turing]

可能他的习惯是修改完一批文件后，逐个 git add 后 git commit，你也可以修改单个功能的相关文件后直接 git add 后 commit 而不是当所有文件都修改完成时。后者看起来更容易梳理每个 commit 之间的关系，但操作起来比较重复繁琐。可能你的同事是前者，所以不提倡 git add .

[bitzhuxb]

个人建议：如果非常熟悉git，当然可以这么做。因为你知道你要add什么文件，有哪些diff，如果失误的话也可以reset重新add。但是如果楼主对git不熟悉，很可能会在其他目录操作错误，但是没有及时发现。add一些无用的修改和文件。还不如改哪个add 哪个来的快。

[yetone]

git commit -av 不就行了 = =

[Delbert]

不应该先git status一下吗？

[kidneyband]

@turing 大部分情况下都是修改多个文件之后再add，我觉得add .和一个一个add真的没区别，只要提交的时候记得看一下文件改变的情况就行了，唉，感觉无语，一个一个添加多烦啊。

[Twinkle]

同4楼，add 前后都会 git status 看一下，一般不会有什么问题

[Axurez]

无非是添加了莫名其妙的文件，或者 commit 不是原子性的。
前者写好 .gitignore 就好了，后者看你需求了，如果你是完成一项功能或者修改然后 git add * 也可以啊。

[cheerzeng]

上面各位说的都是对的。
我说一下我一般的操作过程，
有了repo之后，准备好对应的gitignore文件，这样可以避免不必要的文件改动记录，然后操作前git status看一下，这时候知道有哪些文件改动，就一条条add也可以，全部add也可以，看个人习惯

[deljuven]

我是倾向一次commit所有变更的，每次commit都对应一个bug或者需求。其他修改本地另开分支。。。如果是担心不必要的文件的话用.gitignore来筛掉就行了。。。
不过每次操作之前都会用status来确认下修改和变更，也算是强迫症了。。。

[Kabie]

sourcetree这种可以很方便的精确到行来进行提交。。。
还是蛮有用的……

[vietor]

写好.gitignore

[SharkIng]

我觉得只是习惯问题，或者可能是公司要求问题，比如你修改了很多文件，有的时候可能是完成了同一个功能的添加或修改，但是有的时候可能是不同的，那么如果这样一次添加add 写commit的时候就会有问题，以后查的时候也会怎加困难。但是至少不是说完全不行

[yueyoum]

我是来支持LZ的， 出个毛的问题。

很多人 他们要是不会/不懂， 或者他们没搞过的， 他们总认为有问题。

我做了一个新功能， 这个功能同时修改了多个文件，

我 怎么就不能 git add . git commit -m "New Future" 呢？

[kidneyband]

@yueyoum 非常感谢，我准备去和同事撕逼去了

[Livid]

多人开发的时候，最好是用一个 GitX 这样的工具，每次手工选择要提交的更改。

[mongodb]

@kidneyband 大部分时候不是哪个习惯好的问题，注意交流方式就好...不能说人家的习惯不好，只能说“我有个觉得更好的使用习惯你试试”，否则妥妥的对方不愿意改变习惯

[jokester]

你确定每个patch不多不漏就没问题

[krafttuc]

只是 add 又不是 commit，只要不是一股脑全给提交了，就没啥好吐槽的啊。你同事和你做事风格不一样而已。只要保证最终你 commit 时一个 commit 做一件事就行啦。

[mahone3297]

不能git add .
应该是因为，你没写好.gitignore

[oxoxoxox]

最讨厌的就是这种半吊子同事，问题不在于能不能git add . 而在于要明白这个命令真正的作用是什么