高层背景:
我的工作场所已经存在了几十年，这里的许多员工也是如此。我今年早些时候加入，但在其他地方有丰富的经验。
早在我的第一份工作中，我就自学了 Git，这本质上是一个 2 人项目。我搞砸了很多事情，也练习了很多事情，所以我来自于艰苦的学校。正如我在给一些部门负责人的电子邮件中所写的
[…] I am not a git expert. For better or worse, though, in this company I am :\ […]
我们刚刚从一种更过时的源代码控制(锁定文件、复制文件等的控制)切换到 Git/Bitbucket。大多数人(和老前辈)正在适应新的协议(protocol)，我和其他一些人正在尽我们所能提供帮助。
与我打交道的人:
有一个家伙，一个年长的家伙，脾气暴躁。我和他相处得很好，但他是个很难对付的人。他不想学习新东西，他希望事情变得简单。顺便说一句，这不是一个愚蠢的人，自从 C++ 发布以来，他一直在用 C++ 进行编程，除此之外，他还编写了我们用来从我们的产品连接到数据库的驱动程序(从头开始)。他处理的许多代码都是他自己的东西，本质上是其他部门使用的库，尽管他的大部分工作都在其他人也修改的共享代码文件中。
他承认我知道我在说什么，但他是一只老狗； Git 基于“diff”的概念与实际文件的概念有他不想学习的使用场景，比如创建新分支。他想要一个简单的程序。
在我看来，我是一位非常好的老师。我曾与其他一些员工一起工作过，他们似乎现在已经明白了这一点，并且正在使用 Git/Bitbucket 编写他们的代码。
他想要什么:
回到脾气暴躁的人，他想要一个分支工作。他不想 checkout 新分支、切换分支，他不想了解分支。他希望他完成他的工作，提交，执行 pull 请求，然后继续他的工作。
这只是一个人，公司里大多数人都愿意改变。上周我和他一起坐了大约 5-6 个小时。我喜欢它，因为我们互相尊重，而且我也认为这是我的公司职责，因为我是这里最有能力做到这一点的人(许多人发现他很难说话，所以他有点在自己的泡沫中工作，而且这里没有多少人有这样的能力)我对 Git 的熟悉程度)。此外，他还专注于 Git 的一些核心基础知识，例如暂存、本地与远程等。
虽然并不理想，但如果他经常从主分支 merge 到自己的分支中，并在可预见的 future 只在他的一个分支上工作，这是否是一种“足够好”的解决方法？希望随着时间的推移，我能逐渐让他成为一名优秀的“Gitizen”。最坏的情况是，这家伙可能会在几年内退休。
这个解决方法是一个定时炸弹吗？它会搞砸主分支的历史吗(这是假设所有 merge 冲突都得到正确解决；这对他来说不是问题)？
最佳答案
对于 git，功能分支 merge 回来后无需删除它。特别是如果该功能分支在 merge 到 master 本身之前直接 merge 了 master。 merge 回来后，两个分支的提示将(几乎)相同，因此 git 所感知的 future 开发的基础也是相同的。 (无论如何，什么是“功能”分支？我看到的只是父提交......)
无论您的老手继续在 merge 后的分支上工作，还是在 master 上分支一个新的分支，并没有多大区别。区别只是新工作附加的提交，以及最重要的是分支的名称。
实际上，这是 git 的主要优点之一:像 SVN 这样的旧版本控制系统在处理 merge 回方面存在相当大的麻烦，使得在分支之后无法更多地使用它已重新集成到其源分支中。
对于git来说，所有分支上的所有提交看起来都是一样的，并且它不关心哪个分支名称附加到哪个提交。当 git merge 两个分支时，它只是确定存储库的公共(public)基本状态，并将两个更改集 merge 到该基本状态。提交图仅帮助它确定公共(public)基本状态，这通常是功能分支启动的提交，或者最后 pull 的提交，但它也可以是 master pull 的提交来自功能分支。 (到底什么是功能分支？!？)
关于git - Git 是否可以永久在同一个子分支上工作？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/58822714/