是不是在使用 Git 尝试 2 或 3 个解决方案时，我们必须使用 2 或 3 个分支进行提交？

如何解决是不是在使用 Git 尝试 2 或 3 个解决方案时，我们必须使用 2 或 3 个分支进行提交？

对于一个问题，我们可能想通过 3 种方式解决它。有时我们可以只注释掉代码并尝试 3 个方法，但是如果我们想要 3 个工作代码的快照，在几秒钟内轻松切换怎么办？ （这样 React 网站就可以“热加载”，例如向经理或同事展示三种解决方案）。

如果我 git clone 3 次，我可以完成这个任务，并将每个目录编辑为我想要的任何内容。在这种情况下，我们根本不需要做任何提交。问题在于，例如，如果它是 React 应用程序，我们必须停止服务器并在另一个目录中重新启动服务器。 （而不是动态重新加载网站...）

然后是另一种方式，创建一个分支

git checkout -b easy-way

并进行我们的更改和git commit。现在，如果第二个解决方案是在解决方案 1 的基础上构建，那么

git checkout -b more-complicated-way

并进行我们的更改和git commit。

然后如果我们的第三个解决方案是基于服务器上的原始代码，那么：

git checkout 3f564c   # check the ID from the git log for the original code
git checkout -b the-third-way

然后再次进行更改和 git commit，所以现在，我们可以通过以下方式在 3 个版本之间切换：

git checkout simple-way
git checkout more-complicated-way
git checkout the-third-way

？这是让它工作的唯一方法吗？不知何故，我觉得做这些提交很奇怪，因为可能有 console.log() 并在每个地方注释掉代码。所以到git commit的时候代码还是乱七八糟的感觉怪怪的。

解决方法

具体来说，

在使用 Git 时……我们真的必须……吗？

这是让它发挥作用的唯一方法吗？

嗯，没有。即使在 Git 中，也有多种不同的方法来做到这一点。但是您特别询问的两种方式都是（恕我直言）体面可行的解决方案，但也许可以使用一些小的（概念性）调整。

旁注：您没有明确说明，但您暗示您打算从存储库内的目录中提供您的应用程序。我倾向于避免这样做。相反，我会将 repo 放在一边并使用部署脚本将适当的文件子集移动到服务位置。这样做的好处是您可以准确选择提供哪些文件子集，而且，也许更重要的是，提供的位置更有可能是干净的。例如，当 Git 存储库处于需要手动干预的冲突操作中时，它通常不处于可用状态。话虽如此，但许多人都通过 repo 提供服务，并且（AFAIK）它对他们有用。

至于一些想法：

1. 服务器上的 3 个不同目录：从 Git 的角度来看，我实际上认为这是选项 #2 或 #3 的子集。我认为您不需要 3 个单独的回购副本；一个就够了。但是您仍然可以将 3 组不同的代码部署到服务器上的 3 个不同目录中，每个目录由不同的提交表示。如果足够简单，您可以同时设置 3 个端点，而不是更改端点使用的目录，以便观众可以毫无延迟地看到所有 3 个端点（甚至可以随时自己尝试每个端点）。
2. 在同一个分支上进行 3 次不同的提交：这实际上是有多少人自然地开发代码：创建一个新的分支来处理。尝试一些东西并提交它。调整它或完全重做它并再次提交。 （注意这里你不必注释掉之前的尝试，只需完全替换它，因为它已经保存在之前的提交中。）再调整一些并提交它。如果您这样做，出于演示目的，您可以 git reset --hard [commit-id] 或 git checkout [commit-id] 在您想要的特定提交的状态之间切换，并将其部署到所提供的目录（如果您还没有在 repo 之外提供）。
3. 3 个不同的分支：请注意，一个分支基本上只指向一个提交 ID，因此 3 个提交是在同一个分支上还是在不同的分支上并不重要。主要区别在于，如果您使用不同的分支，您可以使用漂亮的文本名称进行检查：git checkout cool-feature-test1 或 git checkout cool-feature-test2 等。注意，即使提交是在同一个分支上，通过用一个好听的名字来标记提交 ID，然后只检查命名好的标签而不是提交 ID。尽管在某些时候可能会被扔掉的东西上，我可能会避免使用标签。如果你只是因为这个原因准备在同一个分支上标记提交，那么我会从这些提交中的每一个创建新的分支，无论如何你最终都会排名第 3。

如果是我，我可能会结合 #3（单独的分支）和 #1（多个端点）。我更喜欢 #3，所以我不必确切记住要切换回哪个提交 ID，#1 这样我就可以给测试人员提供 URL，并在他们自己的时间要求他们提供反馈。 （如果在实时演示中部署需要一段时间，尤其是在任何代码需要编译时，#1 也很好。）使用 #3，如果您打算对更多代码进行额外编辑，您还可以获得能够单独调整每个尝试的额外好处演示后不止一次尝试。

同样，任何这些都应该可以正常工作。我不会过分强调该走哪条路。选择一些东西并尝试一下，然后根据需要进行调整。