多人开发时使用 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 . 而在于要明白这个命令真正的作用是什么

[sitin]

把 .gitignore 加上，每次都看下git status 情况，然后酱紫。。。何必纠结看结果而不是过程。

[wwqgtxx]

要是说怕出错还是用git-gui吧😄

[phx13ye]

git status 不会出现untrack文件根本没问题

[cvrock]

你直接去问他可能出什么问题不就完了么，沟通障碍就这么严重么？

[Sinute]

你确定所有文件的修改都是需要提交的那你add .当然没有什么问题
问题在于add .很有可能会带上其他东西比如你用于调试忘记删除的部分
每次add一个文件前都diff一下查看一下修改是一个好的习惯, 也能反思一下自己这部分的修改是否合理是否必要
当然你能保证自己的add永远也不会出错那你直接add .也没人会来找你
无脑的add .是不负责的表现

[shot]

git add . 不是问题，add完commit之前不git diff --cached或者gitk检查一下才是问题。

从同事角度来说，你怎么add，rm，checkout，branch，stash都不关我事，只要你最后push过来没问题就行。

[finian]

那你就直接问他可能会出现什么问题啊。另外，用 SourceTree 之类的 GUI 工具更好管理，stage 和 unstage 就是勾一勾文件的事，组织 commit 很方便

[falcon05]

同意ls，自己的commit 按自己习惯来，同事管不了你，也不应该管

[thonatos]

反正我是“git add .”，别人我就管不着了( ⊙ o ⊙ )啊！

[guoer]

https://help.github.com/articles/remove-sensitive-data/#avoiding-accidental-commits-in-the-future

[bdnet]

- first https://github.com/github/gitignore
- 多用用 branch，外加 stage
- 时长保持 workspace clean
要是喜欢一个个check然后add 那也没办法，自己喜欢就好，不要要求别人一起犯"傻"。

[cray]

好奇楼主同事是怎么发现你add .的

[hohoho]

配置好 .gitignore 就行了。话说 Xcode 集成的图形化 git 用着不是很方便吗，为何要 terminal 呢……不过每个人习惯不同，怎么顺手怎么来了。

[lightening]

没什么问题的吧，你同事只要管你没有提交上不该提交的东西就行了，至于你用什么命令还是用什么 GUI 关他什么事啊……

我个人用命令行交互式工具 tig。

[kidneyband]

@cray 看到的呗，以后他在我旁边我不提交代码，真的蛋疼。我认真考虑了一下一个一个提交真的有点傻。。

[Email]

团队合作，用好以下几条命令
rebase
cherry-pick
还有一根救命稻草 reflog

[cxshun]

我是喜欢指定文件来add，毕竟有些配置文件不想提交上去，这个可以理解。
如果是其他原因，就有待讨论了。

[njutree]

ios 开发这里我记得是有坑，好像是原文件目录相关的地方. 如果status 搞清楚add . 肯定没问题

[ericls]

一不小心 不需要的东西就乱入了

[vvtommy]

搞清楚当然没问题。
如果真的非常较真，那用 .gitignore 做好管理。非揪着不放的一般是自己没搞明白怎么回事但是之前通过篓子现在怕了，可以参考「湿猴理论」

[avtester]

通常都是commit -am

[ETiV]

不建议LZ跟同事搞的关系很僵，免得日后你真add了不必要的文件进去，别人还会来揪你辫子…

就比如我身边的，有把“上刑（行）带宽”读成“上杭带宽”的，也有非把 /git/ 读成 /jit/的。
对我来说毫无影响，不影响交流就好。

我又不是你老师，没责任改变你的认知。

[cute]

@ETiV 原来我一直读错啊。

[zog]

gitx逐行提交一下。做好code review

[armysheng]

实习的时候，第一次多人开发，以前都是git add . 然后commit，后来把自己的IDE配置文件也提交上去了，给队友们引起不少麻。当然.ignore 没有配置好也是原因之一。

[sarices]

自己知道哪些文件就好，有问题也可以reset嘛，只要你还没有push

[exch4nge]

感谢 @vvtommy 懂了什么叫湿猴理论。

发现使用git上的常见问题是，工作目录不干净，工作目录不干净就有可能操作失误，pull的时候也不允许工作目录不干净。然后经常误操作提交一些不需要版本控制的文件（如编译中间文件、编译产出文件、log文件等等）。

其实只要配置好了.gitignore，上面问题都（部分）解决了，git add . 也没什么大问题。

[old9]

我觉得 add . 的主要问题不是误添加了垃圾文件，如前面各位所说，垃圾文件可以 ignore 解决，它主要的问题是：容易导致你的提交违背原子性原则。

谁都很难保证自己一段时间的修改都是相关的，所以才会有 index，index 的存在很大程度上就是让你雕琢 commit 的，如果动不动 add . 甚至 commit -a 那还要 index 干什么呢？

反正我个人是极少使用 add . 的，有各种潜在风险却没什么好处。



P.S.
由于楼主只说了“我添加代码时都是使用git add . ”，没提接下来的其他的操作，以上观点基于对楼主工作流的以下假设：
1. add 到 index 区的内容就是要准备 commit 的——而不是说你 add . 了之后还会再回头 unstage。
2. commit 的内容就是要 push 的——而不是说你 push 之前还会用 rebase 之类的重新调整 commit。

[zhujinliang]

特么恼了直接 git add -A

[old9]

如果楼主只是觉得一条一条 add 比较麻烦所以选择去 add .，那可以考虑借助 GUI 工具，或者，如果是 Sublime Text 用户的话，我给你安利一下 GitSavvy 插件。

[nellace]

@zhujinliang 太残暴了。。。。。我都是要先git status一下。。。

[a591826944]

同上 我一般 都是 gst 看一下 都是我要提交的 就直接 ga .

[chmlai]

git commit -a :)

[chilaoqi]

用的熟了，那管那么多。
千人千面，只要不影响别人工作，出错了能负责任的补救就行了。

非要“推荐|强迫”别人用一种工具，一种方法这不有病么？

我从来不用git GUI，add . add single file 都随意了。

[doublleft]

看实际场景需求嘛，如果git add . 是做了同一件事情就可以做一个commit。

但如果做了很多件事情，修了很多bug，加了很多功能，git add . 确实方便，但是怎么写commit log？会被老司机骂的。

[iugo]

我使用 gitg + terminal 来完成.

gitg 不够好, 有时需要 terminal 来完成.

[xavierchow]

这么多回帖的，没人提过 `git add -u`？
我都是git add -u 然后再git status检查一下是否需要单独add untracked file.

[banxi1988]

碰到,需要选择多个需要提交的文件的情况:
我都是打开Vim, 调出 fugitive 出来. 然后 : Gstatus 非常方便

[laucie]

git add -A stages All
git add . stages new and modified, without deleted
git add -u stages modified and deleted, without new