用于合并向下进程的Git命令，该命令不会记住以前的恢复

Question

下面是我想要实现的目标的描述：

我在我们的git仓库上有一个主分支。

每个月都会有一个日期，在这一天，我会将主分支代码完全复制到“辅助”分支上。我们的目的是将二级分支完全替换为主代码，就像硬拷贝一样。我不需要保留二级分支上的任何代码。

一旦硬拷贝和替换完成，我将从“二级”分支中删除一个提交列表，这是我不需要的。

下面是多个循环的样子：

1) 8月月度合并停机(从主到次)日: a)硬拷贝，用主分支代码替换次分支。b)从二级分支中删除提交列表(我使用了git revert命令来解决这个问题；稍后会有更多介绍)

2) 9月月度合并停机(从主到次)日: a)硬拷贝并用主分支代码替换次分支。b)从二级分支删除提交列表

我每个周期都遵循下面的git命令：

在主分支上：

    1.    git fetch
    2.    git checkout secondary
    3.    git branch --set-upstream-to=origin/secondary (only the first time after the branch is created)
    4.    git fetch origin
    5.    git reset --hard origin/master
    6.    git status
    7.    git commit -a
    8.    git status
    9.    git push origin secondary
    11.  git revert 10d3ed335687ef5925c40bd723c81688b7b532c0
    11.  git revert 8e6cb3c361cb415f60d12b26ac547929ec2311de
    12.  git status
    13.  git push origin secondary

这个过程的问题是:理想情况下，我不希望在8月周期中完成的git恢复在9月周期中被记住或尊重，因为我将使用master完全硬替换辅助分支。但是，正如所观察到的，情况并非如此。在前一个周期中完成的恢复也会在下一个周期中被记住(这是我不希望发生的)。

因此，看起来git revert不是满足我们需求的正确命令。

你能建议我们正确的git命令和步骤来达到我们的要求吗？

Answer 1

这里的问题是，git reset --hard origin/master将您的本地分支重置为origin/master当前指向的提交。您甚至可以使用git push -f origin secondary更新中央存储库。但是，您团队中以前拉过secondary的任何其他人都会维护最初存在于该分支上的相同历史记录。当他们执行git pull时，他们只将修改后的secondary分支从中央存储库合并到其本地存储库。先前的恢复操作仍将保留。

要解决此问题，他们可以执行以下操作：

git fetch
git checkout secondary
git reset --hard origin/secondary

然而，这似乎是一个奇怪的部署工作流程。注释中的示例表明，您需要对项目进行配置，以允许您在不更改任何代码的情况下部署到不同的环境。