TMD，我的 branch 又被同事搞烂了，我都不知道怎么修

你自己的 branch 难道不是你做主？不给 force push ？
只要你用的 DVCS，你就应该有底气你的工作以你为准。

我刚毕业写代码的时候也犯过这个问题。改了一个全局的东西影响别人了。
这个和分支关系不大，主要是你同事他太菜了。不知道什么能改什么不能改。
测试只是辅助的手段和规则，但是作为开发者本人应该是有意识的，团队协作本身就是呆着脚镣，即使开了分支也一样。他完全不在乎，当成自己的私有地盘了。

@noobcoder1 在 feature branch 上每天先 pull 是典型的没约定职责清楚边界的错误姿势。
正常的做法是维护 feature branch 的人员不需要同时关心 merge 足够大的 milestone 以外的版本，要 merge 也是从 feature branch 往 dev 由专人负责，否则根本就没开 feature branch 的意义，还用毛线 DVCS。

@janus77 这里看上去一方面是改的人太菜，一方面也是做 review 的人菜，没搞清楚第一时间把整个项目的公共配置恢复到正常可用的（不会动不动就累积冲突的）状态。
协作 review 代码的职责不只是为了验证代码的实现情况，更重要的是了解当前别人的工作情况并协调工作进度保证不会对项目的全局目标引起灾难性后果——不 review 的情况下只要作者自己靠谱前者的问题还可能不大，而后者……冲突一频繁整个项目的进度可能就完蛋了。
还可能是因为负责人太氵，根本就没安排资源去做配置管理，没让人搞清楚只允许改哪些地方……当然，对过大的、沟通路径太多的项目，使用权限管理不够强的 VCS （如 git 这种一开始就只考虑 bazaar model 项目协作的）时，可能加物理分隔（分 repo/submodule ）来强制更可靠一点。

可以 fork 到自己的 repo,然后 remote add ,之后修改自己 repo 的自己分支下的内容，然后再 merge 不就好了么

我喜欢随时 fetch 一下，发现如果要合并的分支有改动，就 rebase 过去，解决冲突，然后再 merge 就不会有冲突了

正常操作，尽量少动自己开发文件以外的文件

还是我一个人一个项目舒服，所以省去了 feature，直接 dev 开发

单元测试的重要性不言而喻，你这个就是血淋淋的例子

大量冲突难道你们分工有很多重复的地方？

你这是因为没有测试覆盖和代码 review 造成的

我觉得流程没问题啊，很多人建议用 rebase，我觉得这个地方更适合 merge 吧，graph 才能更清晰吧。
其实 pr 尽可能的小很重要，积极沟通更重要。
你们看过同事抢先 push 代码后呵呵笑的表情吗？

建议转行。代码对你来说可能有点不像你想得那样运转

？？这不叫搞坏吧，明显是你们同时改了相同的 feature,才会有冲突。是不是分工有问题？引入 bug 的话是另外一个问题，codereview 没做好？

git reset --hard localcommithash
git push -f origin

去他喵的

分支策略层面：

1. 不同分支应该尽量处理项目中不同区域的问题，以此降低冲突的概率。
2. 公共代码的修改应该由专人从那些分支的主干上进行修改，然后“散布”到各个子分支上去。

按 feature 进行分支本身没问题，但是如果 2 个 feature 涉及到大量公共的内容，比如同一块功能的 2 个新特性，那么应该放在一个分支上顺序实现。否则 git 也无法从根本上解决冲突的发生。

个人工作层面：

1. 尽量频繁的将自己分支的代码 rebase 到最新的父分支上，降低最终代码合并到主干时冲突的可能性，同时频繁 rebase 自己的代码，即使发生冲突，其规模也会相对较小，而且冲突的解决是在你自己的分支上，别人不受任何影响。
2. 如果涉及到公共代码的调整，一如分支策略 2 所述，要么告知负责公共代码的专人在主干上调整，然后 rebase 到你自己分支上，要么你自己在主干上调整，然后 rebase 到你自己分支。

你们的模块划分有问题，理论上划分清晰的话，合并根本没有什么冲突，也就不需要没事对齐 master.

多用 rebase, 如果冲突, 马上解决, 有疑问马上结对 review. 这个步骤越快, 技术债务越少

跟楼上说的 rebase 都没关系，甚至跟 git 也没关系。
确实是谁手快就谁生效。
但根据你的描述 merge 进 dev 会 review，为啥他没被 review，或者是 review 不严格？？感觉这里出问题了。

@FrankHB 长偏大论 屌用没有 ，想法很好，但不切实际。。 因为一个团队中水平不一，你永远想不到你的队友会干啥！不要指望 code review 会有多负责，你自己写的代码什么卵样自己心里没个逼数？ 还指望人 review ？ 频繁 pull 我认为并没有什么问题，而且不 pull 你怎么知道主线上有哪些傻叼改了代码？ 我建议务实一点，自己编码时尽量在自己的分支上干，遇到 bug 自己本地开分支改好主动合，每天编码前多 pull 看下研发主线分支的改动，尽量把最新的代码合到自己分支上再继续开发，有冲突尽早的解决，功能好了没问题就尽早往主线合，不要等做完了再合，这样冲突应该会很少，即使有也不会觉得很乱。