高级背景：
我的工作场所已经存在了数十年，这里的许多员工也是如此。我今年年初加入，但是在其他地方有很多经验。
我早在第一份工作时就教过Git，这实际上是一个2人项目。我搞砸了很多事情，实践了很多事情，所以我来自敲门打鼓的学校。正如我在给某些部门负责人的电子邮件中所写的
[…]我不是git专家。无论好坏，我在这家公司都是：\ […]
我们只是从一个过时的源代码控制（锁定文件，复制文件等）切换到Git / Bitbucket。大多数人（和老朋友）都在适应新协议，而我和其他一些人则在可能的地方提供帮助。
我正在处理的家伙：
[有一个家伙，一个年长的家伙，是curmudgeon。我和他相处得很好，但他是一个难以克服的坚果。他不想学习新事物，他希望它很简单。顺便说一句，这不是一个愚蠢的家伙，自从C ++发布以来，他一直在使用C ++进行编程，此外，他还编写了用于从产品（从头开始）连接到数据库的驱动程序。他从事的许多代码都是他自己的东西，本质上是其他部门使用的库，尽管他的大部分工作都在其他人也可以修改的共享代码文件中。
他接受了我知道我在说什么，但他是一只老狗； Git基于“差异”与实际文件的概念具有他不希望学习的使用场景，例如创建新分支。他想要一个简单的过程。
为了辩护，我是一位非常出色的老师。我与其他许多员工一起工作，他们似乎现在已经掌握了它，并且正在使用Git / Bitbucket淘汰他们的代码。
他想要什么：
回到curmudgeon，他希望一个分支继续工作。他不想签出新分支，切换分支，也不想知道分支。他希望自己完成工作，提交，提出请求并继续工作。
这只是一个人，公司中的大多数人都愿意改变。在过去的一周中，我与他共坐了大约5-6个小时。我之所以喜欢它，是因为我们彼此尊重，我也认为这是我的公司职责，因为我在这方面拥有最完善的装备（很多人发现他很难与他交谈，所以他有点像在自己的泡沫中工作，再加上这里没有多少人我做的Git的舒适度）。此外，他还全神贯注于Git的一些核心基础知识，例如分期，本地与远程等。
尽管不理想，但如果经常这样做，他会从master分支合并到自己的分支中，并在可预见的将来仅在其一个分支上工作，这是否会是一个“足够好”的解决方法？希望我能逐渐使他成为一个好的“公民”。最糟糕的是，这家伙可能会在几年内退休。
此解决方法是定时炸弹吗？它会破坏主分支的历史吗（假设所有合并冲突都得到正确解决；这对他来说不是问题）？
这取决于his分支将是“主”（否则合并该分支的其他人会头疼）
当然可以，但是要付出一定的代价。同一项目的不同工作流程，之后，对功能的分析更加困难，对合并错误的跟踪也更加困难（是的，无论开发人员的努力程度如何，都会发生合并错误）。
我确信具有数十年经验的C ++家伙几乎知道他的知识和工具用指尖和谐地工作。所以从他的角度来看，git不是帮助他表现更好，但这是一个障碍。仅对较少的人有用比他专业的技术，迫使专业人士改变人们几乎完美的工作流程谁都不在附近提醒他和你自己，你可能会很高兴并不是要帮助他，而是需要他对整个团队/公司/项目的帮助。
底线取决于开发人员的数量，更改的频率，在不同功能上并行工作的可能性，这几乎是不可能的，或者是很多时间浪费了本来可以放在新功能中的。
对于git，不需要将功能分支合并回去后删除它。特别是如果该功能分支在合并到母版本身之前直接合并了母版。合并回后，两个分支的技巧将（几乎）相同，因此git认为未来发展的基础也相同。 （无论如何，“功能”分支是什么？我只看到父提交...）
您的旧手是否继续在合并后的分支上工作，还是从master分支出新的分支，并没有多大区别。区别仅仅是新工作的附加提交，最重要的是分支的名称。
实际上，这是git的主要优点之一：像SVN这样的旧版本控制系统在处理合并后有很多麻烦，因此在将分支重新集成到其源分支后就无法更多地使用它了。
对于git，所有分支上的所有提交看起来都相同，并且不在乎将哪个分支名称附加到哪个提交。当git合并两个分支时，它仅确定仓库的公共基本状态，并将两个变更集合并到该基本状态。提交图仅帮助它确定公共基本状态，通常是从其开始功能分支或最后从其拉取的提交，但也可以是master从功能分支拉取的提交。 （反正是功能分支？！？）