问题的由来
由于对新工作的不熟悉，以及老同事由于种种原因没有来得及和你介绍项目分支结构，
最主要的原因是对项目和 git 不熟悉。
不知道 git 的一些基本常识，下面我们来普及一下。
基本知识
大公司合作开发一般至少有3条分支（环境，不是分支）
1 master 真实生产环境代码
2 dev 待发布环境
3 feature 测试环境
开发规范
如果你要开发一个新功能
一般是从最稳定的 master 拉取分支，因为这里的代码最纯粹都是要用到的代码，没有其他没有用的代码。
dev 是待发布的代码一般已经经过了内部测试，但是还未经过实际检验，所以不建议从dev拉取。
feature 则是有很多刚开发完的功能等待测试来检验或者正在检验，一般含有很多bug，极不成熟，如果从这里拉取了代码，那将是毁性的。
不管怎么样这篇教程就是写 当你拉取了，测试环境的代码并开发了一个月，到了产品要发布的时候，你遇到的尴尬问题-如何避免其他人的代码污染
我只介绍没有多人同时修改同一个文件的情况，如果你修改的文件同时还有其他人修改，那就不需要看这篇文章了。
假设你修改的项目有 100 个文件再一次 commit 中有 30 个文件被修改了，其中你修改了 10 个。
我们怎么才能避免那 20 个不是你修改的文件合并到 dev 或者 master 而精确地让你修改的那 10 个文件能够被合并呢，很简单：
## 1.
git checkout dev
## (或者 git checkout master)
## 2.
git merge yourDirtyedBranch
## 或者
git cherry-pick commitid
## 或者
git merge commitid
## (把你被污染的分支合并到 dev 或者 master) 这步就污染了吗？ 别急接下来的操作用是重点
## 3.
git reset
## (抛弃掉这次合并但不抛弃代码) 你会看到有很多的 文件被修改了(modified)，只是他们没有没添加到 暂存区
## 4.
git add file1.xx
git add file2.xx
## 一直到 file10.xx 把你的文件挨个添加到暂存区
## 5.
git checkout .
## 抛弃掉其他你不需要修改的文件
## 6.
git commit -m '上线xx功能'
## 7.
git push
## 完美地去掉了被污染的文件。
网友评论