在git中强制推送个人分支是否安全？

Question

假设我在一个名为的个人分支机构工作feature。

1. 我做了5次提交。
2. 我以高手为基础。
3. 我把分支推到一个遥控器。
4. 我git reset --hard回去提交3。
5. 我从主人那里合并。
6. 我推到遥控器（必须使用-f）。

这是安全的做法，还是会导致师父有任何问题？我将需要合并feature到master最终。

Answer 1

只要它确实是私有的，您就足够安全，并且您只需要推送到私有分支即可。这就是为什么。

分支是一种特定的“引用”，提供了提交的ID。

当您推送或获取时，您是在要求git使用您的仓库与另一个git和另一个仓库进行对话。使用a时，fetch您要求您的git要求他们的git给您的git提供您还没有的东西，然后git为您的repo设置“远程分支”，以识别新的东西。使用a时，push您要求您的git发送一些提交，然后要求他们的git使他们的引用指向那些提交中的（某些）提交。

当您“强行推送”时，即使您的git 可能会“丢失”提交，也会使 git告诉他们的git设置那些引用（la git reset）。

请记住，引用使提交可以到达。在git中，提交形成一个图形（“有向无环”图形或DAG）：

A <- B <- C

在此，每个大写字母均表示提交。每个提交都有一个不同的“真实名称” SHA-1（40个字符的明显废话，如1fc3e7aa...）。给定这些大型的长丑陋SHA-1名称中的一个，例如commit的真实名称C，您（或git）读取该提交并找到“父”提交，在这种情况下，则是另一个大的SHA-1丑陋SHA-1 B。然后，您阅读该commit并找到commit的大丑陋SHA-1 A。

但是，您从哪里获得提交的丑陋SHA-1 C？您可以尝试记住它，但这似乎是一个坏计划。相反，为什么不创建一个像这样的小文件，.git/refs/heads/feature然后将大的丑陋SHA-1写入该文件？更好的是，使用git怎么做？

这就是引用，在这种情况下，就是分支名称：refs/heads/类别下的名称。

现在您所要做的就是记住名称feature。而且，git可以在refs/目录中查找并找到所有引用：分支（在refs/heads/），标签（在refs/tags/），注释（在refs/notes/），等等。

显然，任何指向它的名称的提交都是“可到达的”：您（或git）打开名称，读取SHA-1，然后获取该提交。但是以这种方式间接可查找的任何提交也是可以实现的：也就是说，只要我们可以C直接查找，就可以使用它来查找B，然后使用它来查找A。

当您执行时git reset，您是在告诉git移动参考。让我们对该序列进行一些扩展以添加一个新的commit D，并feature指向D：

A <- B <- C <- D   <-- feature

现在让我们git reset --hard提交C。我无法真正将纯文本显示为灰色，但我会D避免使用：

              D
            /
A <- B <- C   <-- feature

我们已经告诉git feature指向C。指向什么D？什么都没有-嗯，“几乎没有”：git有“ reflogs”，并且还有reflog条目D可以再存活30天（无论如何默认情况下）。但是出于正常目的，提交D已经消失了。至少不再容易获得它，并且git log默认情况下不会显示它。一旦它确实无法访问（没有更多的引用日志条目），git最终将“垃圾收集”它并将其从存储库中删除。

如果现在您要求git push告诉其他 git设置其他存储库feature以指向commit C，那么它将也D从那里丢失提交（当然，假设它们D最初是拥有的）。

在这里情况特别糟糕的地方是，当有人使用同一“其他”（共享）git repo的人正在使用且依赖于提交时D。在某个时候，他将调用此共享存储库，并询问其中的内容，feature并返回一个答复，指出“ feature要提交的分支点C”，然后他必须弄清楚如何在不提交D或重新提供提交的情况下进行操作D，或者随你。

您说没有人正在使用此分支（它是私有的），因此没有人依赖commit D。

要知道的另一件事是，虽然您的 reflogs使您可以恢复提交D30天以上，但是您可以推送到的存储库通常禁用了reflogs。这意味着，一旦D在服务器上使提交不可访问，就很可能会垃圾回收。

最后，如果您开始习惯于强制使用，请非常小心强制使用的内容，以免您不小心强制删除了其他人正在使用/依赖的承诺。