Answers:
有一件事人们往往没有考虑到的是一个干净的架构不仅加快长期维护，这也加快了发展，现在。在您的更改“完成”之前，请不要与您的更改隔离。您所做的更改将帮助他们提高工作效率，减少错误的发生。
人们进行大型重构时最常犯的错误是合并不够频繁，而试图一次“大爆炸”。正确的方法是进行尽可能小的重构，对其进行测试，然后将其合并到您的同事的分支机构中，并教给他有关更改的知识，以便他可以将其合并。理想情况下，您每天要进行一次合并，或者至少每周要进行一次合并。
您永远不会“不够大，无法交流”。如果您的手指可以打字，您的嘴唇也可以说话。最终，技术进步是85％的沟通和15％的技术。只是因为您宁愿坐在那里编码，也不愿与某人进行艰难的对话……这并不意味着这是一个好主意。沟通实际上是您要努力完成的工作，但不仅要避免沟通。
是的，分支是一个很好的解决方案。
我建议您开始在分支上进行此工作，并确保HEAD在此期间它可以干净地应用于当前版本（例如，使测试变基并定期合并，以确保您可以轻松应用更改并且测试仍然通过- -也可以寻求git rerere帮助git）。然后，完成基础调整并将更改合并到HEAD。
您越早开始进行这项工作就越好，因为不断变化的体系结构变得越来越工作，代码变得越冷。同样，可能会有许多手工编码的代码实例散布在整个代码库中，例如，您的新函数和Shiner Helper函数可能使事情变得简单得多。
tl; dr-听起来是时候该加入大型联赛了。把口红涂在猪身上并不会使它更漂亮，除非您喜欢这种东西。
人事问题
第一个问题是提交同步。如果您有多个人同时处理同一代码，则只需要一条规则即可防止出现问题：
Rule 1: Always pull before you merge/rebase
当涉及到DVCS时，很难对远程分支（即主存储库）进行更改，并且非常容易对本地分支进行更改。每个人都有责任使自己的代码添加到更大的整体中，而不会出现问题。除非有两个人在同一时间承诺，否则您不会经验。提交对原始/远程主服务器的访问权限应仅限于少数开发人员，并且他们应通过远程跟踪分支从其他开发人员处提取更改。
代码问题
您怎么知道所做的更改不会破坏代码？
简单的答案...编写测试以证明它们不是。如果您忽略TDD（测试驱动设计）的思想流派，那么测试的重点就是添加一个验证级别，使您可以更改代码而不会破坏代码。
Rule 2: Don't make assumptions, write proofs (ie tests).
除此之外，应先进行全部测试，然后再推送到原始/远程主服务器。
尽量减少提交的内容。这样，如果您需要撤消以后会破坏某些内容的更改，则无需重新实现那些不会破坏代码的部分，从而可以节省很多时间。
您可能需要先进行一些组织重组
如果上述解决方案无法轻松应用，则可能首先需要解决开发结构中的一些问题。
项目的所有者应该是网守。如果存在提交同步问题，则可能有太多的人具有提交访问权限。即使在像Linux内核这样的大型项目上，也只有少数开发人员可以访问原始/远程主存储库。实际上，有多层存储库来管理提交。分层模型不是由每个人都将更改推向原点的单层提交模型，而是由网守来拉动更改并在将其纳入项目之前验证其质量。与单层模型相比，分层提交模型可以扩展得更大，更有效，而不会牺牲质量。
对于那些没有得到提交访问开发者，他们应该学会建立自己的远程跟踪分支（Git和gitorious是这个好），所以谁的开发者做已提交权限可以轻松拉/集成分支到原点。如果更改很小，补丁也将正常工作。
在执行合并/变基之前拉出更改的能力假定您不在本地master分支上进行开发。解决此问题的简单方法是在开始编写代码之前先进行一次拉动，然后在该分支上进行所有工作。困难的方法是在合并和回滚母版之前对其进行分支。
定义整个项目的编码风格，并让开发人员遵循。贡献开发人员应编写符合项目标准/规范的代码，以最大程度地减少清理工作。在一个开放项目中，编码风格可能是一个很大的自我障碍。如果未设置任何标准，则每个人都将以自己喜欢的样式进行编码，并且代码库很快就会变得非常难看。
“神话人月”的神话
信不信由你，更大/更成功的开源项目并没有像民主国家那样运作。它们作为层次结构运行。声称一个项目不能有效地发展到超过8-10个开发人员是天真的。如果这是真的，那么像Linux Kernel这样的大型项目将不存在。更深层的问题是，授予所有人提交访问权限只会使有效的沟通变得难以处理。
神话般的人月问题实际上可以克服。您只需要像军方一样运行项目即可。层次结构中有许多级别，因为众所周知，单个人实际上只能有效地管理与少数人的通信。只要没有一个人负责管理超过5至7个人的工作，该系统就可以无限扩展。
它可能会限制最好/有经验的开发人员进行更多的集成和更高级别的设计/计划，但这并不是一件坏事。扩大规模的一部分是决定该项目需要长期计划。在未来的项目中拥有最大投资（时间也是一种资源）的最高层人员应该负责做出重大决策。
很高兴听到一个开源项目正在经历越来越多的痛苦。恭喜你，祝你好运。
干净/美丽，最重要的是长期可维护的代码。
以我的经验，清洁/美丽是可维护的敌人。经常使用漂亮的代码：
另一方面，可维护的代码：