Git是否可以永久地在同一个分支上工作？

Question

高级背景：

我的工作场所已经存在了数十年，这里的许多员工也是如此。我今年年初加入，但是在其他地方有很多经验。

早在我的第一份工作时，我就自学了Git，这实际上是一个2人项目。我搞砸了很多事情，实践了很多事情，所以我来自敲门打鼓的学校。正如我在给某些部门负责人的电子邮件中写的那样

[…]我不是git专家。无论好坏，我在这家公司都是：\ […]

我们只是从一个过时的源代码控制（锁定文件，复制文件等）切换到了Git / Bitbucket。大多数人（以及较早的人）都在适应新协议，而我和其他一些人正在尽我们所能。

我正在处理的人：

有一个家伙，一个大家伙，是curmudgeon。我和他相处得很好，但他是一个难以克服的坚果。他不想学习新事物，他希望它很简单。顺便说一句，这不是一个愚蠢的家伙，自从C ++发布以来，他一直在使用C ++进行编程，此外，他还编写了用于从产品（从头开始）连接到数据库的驱动程序。他从事的许多代码都是他自己的东西，本质上是其他部门使用的库，尽管他的大部分工作都在其他人也可以修改的共享代码文件中。

他已经接受我知道我在说什么，但他是老狗。Git基于“差异”与实际文件的概念具有他不希望学习的使用场景，例如创建新分支。他想要一个简单的程序。

为辩护，我是一位很好的老师。我曾与其他许多员工一起工作过，他们似乎现在就了解了，并且正在使用Git / Bitbucket淘汰他们的代码。

他想要什么：

回到curmudgeon，他希望一个分支继续工作。他不想签出新分支，切换分支，也不想知道分支。他希望自己完成工作，提交，提出请求并继续工作。

这只是一个人，公司中的大多数人都愿意改变。在过去的一周中，我与他共坐了大约5-6个小时。我之所以喜欢它，是因为我们彼此尊重，我也认为这是我的公司职责，因为我是在这里做到最好的装备（许多人发现他很难与他交谈，所以他有点像在自己的泡沫中工作，再加上这里没有多少人我做的Git的舒适度）。此外，他还全神贯注于Git的一些核心基础知识，例如暂存，本地与远程等。

尽管并不理想，但如果他每隔一段时间从master分支合并到自己的分支，并在可预见的将来仅在其一个分支上工作，这将是一个“足够好”的解决方法吗？希望我能逐渐使他成为一个好的“公民”。最糟糕的是，这家伙可能会在几年内退休。

这是一个定时炸弹吗？它会破坏主分支的历史吗（假设所有合并冲突都得到正确解决；这对他来说不是问题）？

Answer 1

对于git，合并回来后没有必要删除功能分支。特别是如果该功能分支在合并到 master 本身之前直接合并了 master。合并回来后，两个分支的尖端将（几乎）相同，因此未来发展的基础git也是相同的。（无论如何，什么是“功能”分支？我看到的只是父提交......）

无论您的老手继续在合并后的分支上工作，还是分支一个新的分支master，实际上并没有多大区别。区别只是新工作所附加的提交，以及最重要的是分支的名称。

实际上，这是 的关键优势之一git：像 SVN 这样的旧版本控制系统在处理合并返回方面存在相当大的麻烦，使得在重新集成到源分支后无法更多地利用分支。

对于git，所有分支上的所有提交看起来都是一样的，并且它不关心哪个分支名称附加到哪个提交。当git合并两个分支时，它只是确定存储库的公共基本状态，并将两个更改集合并到该基本状态。提交图仅帮助它确定公共基本状态，这通常是功能分支启动的提交，或者最后拉取的提交，但它也可以是从master功能分支拉取的提交。（到底什么是功能分支？！？）