主页 / 问题 / 550704
Accepted
Алексей Шиманский
Asked:2020-08-01 17:13:53 +0000 UTC2020-08-01 17:13:53 +0000 UTC

如何将一个项目作为一个提交而不是数百个提交上传到 Github？

  • 772

一开始的想法：

假设有一个项目。计划位于

https://github.com/myProfile/test.git

      在本地，一些事情一直在做，在数百个分支机构中提交了数百次。然后以1.1版本上传到github。然后通过另外 100 次提交修复 100 个错误，并上传为版本 1.2，等等。

      也就是说，作为一个内部开发的产品，它将有成百上千次提交的历史记录来跟踪和回滚（以防万一），并且（在 github 上）历史记录只有“ver 1.1.”，“ver 1.2（这是固定的）”，等等......

       这可以以某种方式完成吗？是否有可能？

       下面是这个过程是如何在本地发生的（顺便说一下，也许这已经是错误的，我不知道）：

  • 创建一个文件夹test
  • 输入初始化命令git init
  • 创建一个文件并添加git add .，git commit -am "initial commit"

       然后根据场景跳舞：

       第一步：创建分支git checkout -b develop20160731

       第 2 步：完成并添加了一些内容：

   git add .
   git commit -am "some comment"
   git checkout master
   git merge develop20160731
   git checkout develop20160731

       第 3 步：第 2 步重复 N 次。
       第 4 步：用另一个分支重复第 1 步中的所有内容

       结果，这个故事看起来像这样：

* a0c188f 2016-07-31 | comment №2 for anotherBranch (HEAD -> master, anotherDevelop) [anonymous]
* 6acdde0 2016-07-31 | comment №1 for anotherBranch [anonymous]
* 9557ff9 2016-07-31 | comment №2 for my branch (develop20160731) [anonymous]
* b6946aa 2016-07-31 | comment №1 for my branch [anonymous]
* 864e4d9 2016-07-31 | initial commit [anonymous]

       我在师傅 我想将所有这些作为 1.1 版发送到Github，即 在提交历史中，这样就有一个孤独的提交，比如

Commits on Jul 31, 2016
  @anonymous
  added superProject v1.1
  anonymous committed 1 second ago

并非所有项目都会提交。

下一次，added superProject v1.2从本地收集的所有提交中只添加一个提交，等等。

如何完成？

PS 如果我不知何故在本地做错了什么，那么我请你描述它是如何更正确的。理想情况下，我想要“手指上”的完整说明

git

2 个回答

  1. Best Answer

    然后以1.1版本上传到github。然后通过另外 100 次提交修复 100 个错误，并上传为版本 1.2，等等。

    通常，版本之间会添加不止一项功能或一个错误修复。将所有修复和添加合并到一个提交中是没有建设性的。那么将很难发现错误或反向更改。

    如果你的故事是这样的：

    c1fed68 попробуем сделать это так
a046d5b неа, не работает, давай по-другому
836f56c вроде нормально, давай пока сохраним несколько временных файлов
5edb66e пускай этот код не компилируется, но я иду домой, надо сохранить работу
8cb14a7 зря я вчера так написал, есть покрасивее способ
91c6c05 вот так зашибись
01c5594 вроде даже работает

    那么我们可以建议如下操作方式（大致对应方法论）：

    1. 在处理功能的过程中，开发人员为该功能创建一个单独的分支，并根据需要向其添加尽可能多的提交。
    2. 如果您也不想显示此类分支的内容，那么您可以创建第二个封闭的存储库，它将包含整个“厨房”，包括拉取请求。
    3. 功能分支被提供用于合并到开发中，它们在那里累积直到发布。合并时，特性分支折叠为 1 个提交（可选git rebase -i, git reset --soft develop），向提交写入明确的注释。同时，您可以通过合并（合并）和变基来进行更改以进行开发——这是团队偏好的问题。两种方法都有优点和缺点。

    4. 当在 develop 中积累的特性和错误修复，根据你的主观标准，应该成为一个 release 时，会发生以下步骤：

      1. develop分支合并到master。快进很可能是可能的，但如果你也想在这里提交合并，请使用git merge --no-ff develop. 可以将 Git 配置为--no-ff隐含在所有或仅某些分支中——有关更多信息，请参见KoVadim 的回答。

      2. 发布标签附加到收到的提交。请务必使用完整的提交（带有注释）。

        git tag 1.2.3 -m 'release 1.2.3'
git push --follow-tags

      3. 如果您决定使用两个存储库，现在是时候将一个存储库推送到公共存储库了。

        git push github --follow-tags

    顺便说一句，像 Linux 这样的大型项目的工作已经按照类似的方案实施。有中级审阅者专门接受干净、完整和打包的提交，然后进一步推动它们。并且草稿不会超出开发人员自己的存储库。

    原则上，您可以在推送到公共存储库之前将所有发布提交合并为一个。然而，这充满了困难：

    • 几乎不可能追踪引入错误的提交。
    • 您不能撤消 ( git revert) 特定提交（即功能、编辑等）
    • 如果你想发布一个版本的补丁，你仍然必须将它作为一个单独的提交发布。
    • 如果来自外部的人向您提供了一个只进行了少量修改的拉取请求，那么接受它然后将其倒入一个大的提交中是不礼貌的。因此，您实际上将删除有关代码作者身份的信息。

    我建议停止在 1 个功能 - 1 个提交的对应处并且不要进一步合并。用户，即使是最没有经验的用户，也应该能够使用 Github 上相对简单的发布界面。而如果在合并一个特性分支的那一刻，有一些代码“不方便”展示给公众，这就是这个特性还没有准备好的标志。

    示例：Git 程序的发布页面本身就很好地说明了什么是发布：

    在此处输入图像描述

    • 15

  2. 很难确保 github 有一个提交，而开发人员有另一个。但是你可以像他们在大团体中那样做。

    1. 所有功能或错误修复都在单独的分支中进行。即使是小的。有多少次提交并不重要。
    2. 所有更改都在其分支机构中进行测试。如果更改不合适，则可以留下或钉住分支（可选）。
    3. 当一个 feature/bugfix 准备好后，它被合并到 master/develop 中（这个由当前流程和需求决定） with no fast forward( git merge --no-ff<branch>)。在这种情况下，主分支将有一个提交，但如有必要，所有其他分支都将可见。这样的commit很容易reverse( git revert -m 1 <sha хеш мержд коммита>)（实际上，它不仅仅是revert，而是“相反”地滚动变化的差异，因此，如果有必要，它可以回滚很多次——也就是说，你可以roll回滚回滚）。

    no fast forward可以在配置中启用，那么在合并期间甚至不需要指定它，git config --add merge.ff false或者git config branch.master.mergeoptions "--no-ff"如果您只需要为 master 禁用它。

    总结一下，其实好像只需要在config里面加个设置，连流程都不用改。

    • 8

相关问题