我们最近从简单易用的集中式VCS切换到Git。为了简化过渡，我们使用SourceTree作为Git的GUI。我的一位同事询问是否有某种方法可以模仿他习以为常的工作流程：
假设他正在开发一个包含三个文件的项目：A，B和C.他可能会检查A并对其进行更改。当他对A做出更改时，其他人正在对A，B和C进行更改，并将更改提交给VCS回购。使用VCS客户端或Visual Studio，他会定期将最新的B和C拉到他的工作目录，但从不A，即，如果其他人对A进行了更改，他会忽略它们直到他完成A的工作。那时我猜猜他合并了这些变化。
我告诉他，Git不会以这种方式工作，即逐个文件。我建议如果他正在研究A，他可以定期将远程变更合并到A，B和C.如果A中存在冲突，他可以解决它们。 （无论如何，他最终还是必须这样做。）我考虑将A添加到.gitignore并将其从repo中移除（完全不正确），为A添加merge = our gitattribute（似乎更适合配置文件，而不是集合）他本周正在处理的源文件），或使用假设未更改或跳过工作树（再次，似乎不适合他现在正在处理的不断变化的源文件集）。
他是否只需要习惯新的工作流程，或者我在Git中遗漏了哪些东西会模仿他过去常用的旧的集中式VCS工作流程？
谢谢， 马特
答案 0 :(得分：0)
老实说，在这种情况下，如果每个人都以这种共享代码的方式处理这段代码，那么我认为最好的办法就是让他通过更新B和C定期处理A中出现的任何合并冲突。如果运气好，并且有一个合理的分支系统，其中功能以合理的方式分离出来，那么他将是A中唯一能够影响自身功能的部分，如果其他人正在做的事情与他的特定部分（或整个）功能正在发挥作用，那么也许工作不会以最佳方式分离出来。
话虽如此，如果有人做出改变影响他的A，他很可能会尽快知道，因为一旦他将他的功能合并回操作的主干，他等待处理这些合并的时间越长，分歧越大，合并可能变得无法管理的可能性就越大。
像Git这样的事情之一就是你可以采取这样的情况，并建立一个软件开发模式，围绕避免这些类型的问题，一个好的SoC（关注点分离）导致一个漂亮的软件这个过程将彻底消除这些类型的冲突。
希望有所帮助！