是否可以在 Git 中永久在同一个分支机构工作？
Is it possible in Git to work on the same sub-branch in perpetuity?
高级背景：
我的工作场所已经存在了几十年，这里的许多员工也是如此。我今年早些时候加入，但在其他地方有很多经验。
我在第一份工作时自学 Git，那基本上是一个 2 人项目。我搞砸了很多事情，练习了很多事情，所以我来自苦难学校。正如我在给一些部门负责人的电子邮件中所写
[…] I am not a git expert. For better or worse, though, in this company I am :\ […]
我们刚刚从更陈旧的源代码控制（锁定文件、复制文件等）切换到 Git/Bitbucket。大多数人（和老前辈）都在适应新协议，我和其他一些人也在力所能及的范围内提供帮助。
我正在处理的人：
有一个老兄，一个脾气暴躁的人。我和他相处得很好，但他很难对付。他不想学习新事物，他希望它简单。这不是一个愚蠢的人，顺便说一句，自从 C++ 发布以来，他一直在用 C++ 编程，除其他外，他编写了我们用来从我们的产品（从头开始）连接到我们的数据库的驱动程序。他处理的很多代码都是他自己的东西，本质上是其他部门使用的库，尽管他的大部分工作都在其他人也修改的共享代码文件中。
他承认我知道我在说什么，但他是个老狗； Git 基于 "diff" 与实际文件的概念有他不想学习的使用场景，比如创建新分支。他想要一个简单的程序。
在我看来，我是一个很好的老师。我和其他一些员工一起工作过，他们现在似乎明白了，并且正在使用 Git/Bitbucket.
来攻击他们的代码
他想要什么：
回到那个脾气暴躁的人，他想要一个分支来工作。他不想检查新分支、切换分支，他不想了解分支。他希望完成他的工作、提交、执行拉取请求并继续他的工作。
这只是一个人，公司里大部分人都愿意换。在过去的一周里，我总共和他坐在一起大约 5-6 个小时。我喜欢它，因为我们互相尊重，而且我也认为这是我的公司职责，因为我是这里最有能力做到这一点的人（许多人发现他很难与之交谈，所以他有点在他自己的圈子里工作，而且这里没有多少人有我对 Git 的舒适度）。此外，他还专注于 Git 的一些核心基础知识，例如暂存、本地与远程等。
虽然不理想，但如果他每隔一段时间从 master 分支合并到他自己的分支并在可预见的未来只在他的一个分支上工作，这是否是一个 "good enough" 解决方法？希望随着时间的推移，我可以逐步让他成为一名优秀的 "Gitizen"。最坏的情况下，这家伙可能会在几年内退休。
这个解决方法是一颗定时炸弹吗？它会搞砸主分支的历史吗（这是假设所有合并冲突都得到正确解决；这对他来说不是问题）？
视情况而定，假设他的分支是"master"（否则其他人合并他的分支会很头疼）
- 他可以 pull/merge 并轻松提交+推送他的更改
- 他将很难在一段时间内处理多个问题。假设因为他不喜欢分支，他也不会使用 stashes（尽管他可以投入大量时间并使用 diff/patch-files 并保持所有这些都是最新的）
** 在没有 "branches and merge only at end"
的情况下，很难使用来自上游的更改更新同一文件的多个版本
- 在功能分支上与他一起工作，通过电子邮件来回发送补丁会很困难吗？
- 如果有其他开发人员使用功能分支，他的更改在 gitk 中将不会像所有提交的平行线一样好地可见，相反他将仅在 master 上
它当然可以，但要付出代价。同一项目的不同工作流程，
之后更难分析功能，更难跟踪合并错误（是的，无论开发人员多么勤奋，它们都会发生）。
我敢肯定，拥有数十年经验的 C++ 人员几乎了解他的东西和工具
用他的指尖在神奇的和谐中工作。所以从他的角度来看， git 不是
帮助他表现得更好却是一种障碍。只对资源较少的人有帮助
knowhow 比他强，逼着pro改人近乎完美的工作流程
谁不在附近。提醒他和你自己可能会有帮助
不是想帮助他，而是需要他的帮助 team/company/project 作为一个整体。
底线是，这取决于开发人员的数量、更改的频率、在不同功能上并行工作的可能性，这几乎是不可能的，或者需要很多时间
浪费了，本来可以加入新功能的。
对git来说，一个feature分支合并回来后，没有必要删除。特别是如果该功能分支在合并到 master 本身之前直接合并 master 。合并回来后，这两个分支的提示将（几乎）相同，因此 git 所感知的未来发展的基础也是相同的。 （无论如何，什么是 "feature" 分支？我所看到的只是父提交...）
无论您的老手是继续在合并后的分支上工作，还是从 master 分支出新的分支，都没有太大区别。区别只是新工作附加的提交，最重要的是，分支的名称。
实际上，这是 git 的主要优点之一：像 SVN 这样的旧版本控制系统在处理合并后退时遇到了很多麻烦，使得在分支被合并后无法更多地使用它重新整合到其源代码分支中。
到git，所有分支上的所有提交看起来都一样，并且不关心哪个分支名称附加到哪个提交。当 git 合并两个分支时，它只是确定 repo 的公共基础状态，并将两个变更集合并到该基础状态。提交图仅帮助它确定公共基础状态，这通常是功能分支开始的提交，或者它最后一次拉取的提交，但它也可以是 master 从功能中拉取的提交分支。 （无论如何，什么是功能分支？！？）
高级背景：
我的工作场所已经存在了几十年，这里的许多员工也是如此。我今年早些时候加入，但在其他地方有很多经验。
我在第一份工作时自学 Git，那基本上是一个 2 人项目。我搞砸了很多事情，练习了很多事情，所以我来自苦难学校。正如我在给一些部门负责人的电子邮件中所写
[…] I am not a git expert. For better or worse, though, in this company I am :\ […]
我们刚刚从更陈旧的源代码控制（锁定文件、复制文件等）切换到 Git/Bitbucket。大多数人（和老前辈）都在适应新协议，我和其他一些人也在力所能及的范围内提供帮助。
我正在处理的人：
有一个老兄，一个脾气暴躁的人。我和他相处得很好，但他很难对付。他不想学习新事物，他希望它简单。这不是一个愚蠢的人，顺便说一句，自从 C++ 发布以来，他一直在用 C++ 编程，除其他外，他编写了我们用来从我们的产品（从头开始）连接到我们的数据库的驱动程序。他处理的很多代码都是他自己的东西，本质上是其他部门使用的库，尽管他的大部分工作都在其他人也修改的共享代码文件中。
他承认我知道我在说什么，但他是个老狗； Git 基于 "diff" 与实际文件的概念有他不想学习的使用场景，比如创建新分支。他想要一个简单的程序。
在我看来，我是一个很好的老师。我和其他一些员工一起工作过，他们现在似乎明白了，并且正在使用 Git/Bitbucket.
来攻击他们的代码他想要什么：
回到那个脾气暴躁的人，他想要一个分支来工作。他不想检查新分支、切换分支，他不想了解分支。他希望完成他的工作、提交、执行拉取请求并继续他的工作。
这只是一个人，公司里大部分人都愿意换。在过去的一周里，我总共和他坐在一起大约 5-6 个小时。我喜欢它，因为我们互相尊重，而且我也认为这是我的公司职责，因为我是这里最有能力做到这一点的人（许多人发现他很难与之交谈，所以他有点在他自己的圈子里工作，而且这里没有多少人有我对 Git 的舒适度）。此外，他还专注于 Git 的一些核心基础知识，例如暂存、本地与远程等。
虽然不理想，但如果他每隔一段时间从 master 分支合并到他自己的分支并在可预见的未来只在他的一个分支上工作，这是否是一个 "good enough" 解决方法？希望随着时间的推移，我可以逐步让他成为一名优秀的 "Gitizen"。最坏的情况下，这家伙可能会在几年内退休。
这个解决方法是一颗定时炸弹吗？它会搞砸主分支的历史吗（这是假设所有合并冲突都得到正确解决；这对他来说不是问题）？
视情况而定，假设他的分支是"master"（否则其他人合并他的分支会很头疼）
- 他可以 pull/merge 并轻松提交+推送他的更改
- 他将很难在一段时间内处理多个问题。假设因为他不喜欢分支，他也不会使用 stashes（尽管他可以投入大量时间并使用 diff/patch-files 并保持所有这些都是最新的） ** 在没有 "branches and merge only at end" 的情况下，很难使用来自上游的更改更新同一文件的多个版本
- 在功能分支上与他一起工作，通过电子邮件来回发送补丁会很困难吗？
- 如果有其他开发人员使用功能分支，他的更改在 gitk 中将不会像所有提交的平行线一样好地可见，相反他将仅在 master 上
它当然可以，但要付出代价。同一项目的不同工作流程， 之后更难分析功能，更难跟踪合并错误（是的，无论开发人员多么勤奋，它们都会发生）。
我敢肯定，拥有数十年经验的 C++ 人员几乎了解他的东西和工具 用他的指尖在神奇的和谐中工作。所以从他的角度来看， git 不是 帮助他表现得更好却是一种障碍。只对资源较少的人有帮助 knowhow 比他强，逼着pro改人近乎完美的工作流程 谁不在附近。提醒他和你自己可能会有帮助 不是想帮助他，而是需要他的帮助 team/company/project 作为一个整体。
底线是，这取决于开发人员的数量、更改的频率、在不同功能上并行工作的可能性，这几乎是不可能的，或者需要很多时间 浪费了，本来可以加入新功能的。
对git来说，一个feature分支合并回来后，没有必要删除。特别是如果该功能分支在合并到 master 本身之前直接合并 master 。合并回来后，这两个分支的提示将（几乎）相同，因此 git 所感知的未来发展的基础也是相同的。 （无论如何，什么是 "feature" 分支？我所看到的只是父提交...）
无论您的老手是继续在合并后的分支上工作，还是从 master 分支出新的分支，都没有太大区别。区别只是新工作附加的提交，最重要的是，分支的名称。
实际上，这是 git 的主要优点之一：像 SVN 这样的旧版本控制系统在处理合并后退时遇到了很多麻烦，使得在分支被合并后无法更多地使用它重新整合到其源代码分支中。
到git，所有分支上的所有提交看起来都一样，并且不关心哪个分支名称附加到哪个提交。当 git 合并两个分支时，它只是确定 repo 的公共基础状态，并将两个变更集合并到该基础状态。提交图仅帮助它确定公共基础状态，这通常是功能分支开始的提交，或者它最后一次拉取的提交，但它也可以是 master 从功能中拉取的提交分支。 （无论如何，什么是功能分支？！？）