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

通常都是commit -am

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

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

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

@ETiV 原来我一直读错啊。

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

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

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

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

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

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

我觉得 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。

特么恼了直接 git add -A

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

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

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

git commit -a :)

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

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

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

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

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

我使用 gitg + terminal 来完成.

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

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

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

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