hivesql基础合并_为什么我更喜欢合并基础

hivesql基础合并

有很多使用git的方法。 工作流程会根据团队规模，组织规模和工作方式而有所不同–是分布式的，基于sprint的，是公司的还是由维护人员批准请求的开源项目。

您可以使用vanilla-git，也可以使用GitHub，BitBucket，GitLab，Stash。 然后在客户端上，您可以使用命令行，IDE集成或像SourceTree这样的独立客户端。

工作流的主要区别在于您组织分支机构的方式以及合并分支机构的方式。 您是否分支机构分支？ 您是否正在其他人的分支机构中进行工作？ 您是推动还是留在当地？ 您是像SVN一样使用它（对于宠物项目中的单个开发人员来说完全可以使用），还是钻研了更多的“ arcane”功能，如--force-with-lease 。

这都是由每个团队决定的，但是我想集中讨论一个备受争议的话题-变基础还是合并。 尽管您可以在讨论重新定级与合并方面获得大量成果，包括正式的git文档，但这已成为更多的哲学辩论，而不是实际的辩论。

我最近问了一个有关变基工作流的实际问题 。 简而言之，默认情况下，变基似乎不支持将内容推送到中央存储库。 如果您在重新设置基准之前这样做，则始终需要强制推动。 对于按您的分支机构工作的人来说，用力推动可能会非常困难。 您已经在问两个问题：

• 如果事情还没准备好，为什么还需要推动？ 能够在本地提交并仅在准备就绪时进行推送，这不是“ DVCS”中“ D”的意义吗？ 好吧，即使您不使用git作为SVN，仍然有很多用例将每个更改推送到自己的功能分支远程–您可能在不同的机器上工作，同事可能想在您离开的地方取货（在休假或生病之前），甚至硬盘驱动器故障和盗窃。 我认为，基本上，您必须在注销之前立即推送，甚至更多。 “分布式”允许脱机工作，甚至不需要中央存储库（如果发生故障），但这不是git的主要优点。
• 为什么有人会基于您的进行中分支？ 因为它发生了。 有时，任务没有严格地划分并且具有依赖性-您编写了一项功能，然后您意识到应该由在同一故事/功能中处理另一任务的队友使用。 您尚未完成（例如仍在抛光，测试），但他们不应该等待。 在等待代码审查注释时，即使是一个人也可能希望将下一个任务作为上一个任务的基础。 该工具不应不时阻止您这样做，即使它可能不是默认的工作流程方案。

另外，您不应该指望每个团队成员都是git guru，他会改写早餐的历史记录。 一个基本的命令集（甚至是GUI）对于git工作流（包括边缘情况）应该足够了。 Git很复杂，每个团队的任务是让它为他们服务，而不是与他们对抗。 对于每个git命令或概念，可能只有一篇文章的标题为“ X被认为是有害的”，对于没有经验的git用户来说，经历迷宫并不是一件容易的事。 正如Linus Torvalds曾经说过的：

Git接管了Linux遗留下来的地方，将极客们分解为一无所有和一无所知。 我真的没想到会有人使用它，因为它很难使用，但是事实证明这是它的巨大吸引力。

回到rebase vs merge –合并（带有拉取请求）对于以上内容来说很自然。 你经常分支，你经常推动。 Rebase可以在上述用例中工作（我认为这是必要的）。 您可以在每次重新设置基准后强制推动，并且可以确保您的队友解决了这一问题。 但是有什么意义呢？

实际的论点是，显示回购历史记录的图表美观且可读。 我无法争论，因为我从来没有遇到过需要更清晰，更好的图形的情况。 无论图中有多少合并提交和丑陋，您仍然可以找到自己的方式（如果需要）。 此外，即使没有图形，也可以轻松地跟踪某些更改（例如git注释）。

如果您确实确定没有一张漂亮的图表是不可能的，并且您的队友都是git大师，可以在几分钟内解决推力问题，那么重新定基可能很好。

但是我认为仅合并工作流是更方便的工作方式，可以解决更多实际情况。

我意识到这是有争议的，我当然是git n00b（我什至使用SourceTree而不是基本命令的命令行，duh）。 但是我同时使用了合并和变基工作流，但我发现合并更简单了（毕竟，强制将其作为常规工作流的一部分听起来可疑吗？）。

Git是VCS的标杆-它为您提供了许多方法来做某事，但是没有“正确的方法”。 这并不一定是不好的，因为确实有很多可以使用git的场景。 对于我所拥有的（常规公司中的常规项目，具有常规的半自动发布和部署周期，进行常规的敏捷性），我总是会进行合并，并带有请求请求。

翻译自: https://www.javacodegeeks.com/2016/06/prefer-merge-rebase.html

hivesql基础合并