本地分支出现在 GitHub 的“网络”上看法

发布于 2024-09-03 12:38:13 字数 349 浏览 8 评论 0原文

我们使用 Git,我们的工作流程由“dev”和“master”分支组成,它们位于 GitHub 和每个开发人员的本地存储库上。不会直接在“master”或“dev”上执行任何工作,而是在本地分支中执行工作,并且仅在“dev”上进行合并,然后与“master”进行合并。我们不会将本地分支推送到 GitHub。

由于某种原因,开发人员的本地分支显示在 GitHub 上的“网络”视图中,这使网络图变得混乱(我应该指出,分支本身并不存在于 GitHub 上的分支列表下)。

我的问题是,这是否是正常行为并自动发生,作为显示“dev”和“master”的更改来自何处的一种方式,还是因为有人错误地推送了本地分支并随后将其删除?如果是后者,有没有办法清理混乱?

We are using Git and our workflow consists of a 'dev' and 'master' branch which lives on GitHub and each developer's local repository. No work is performed directly on 'master' or 'dev', but rather in local branches and only merges happen on 'dev' and later with 'master'. We do not push local branches to GitHub.

For some reason developers' local branches show up in the "Network" view on GitHub and this clutters up the network diagram (I should point out that the branch itself doesn't exist under the list of branches on GitHub).

My question is whether this is normal behavior and happens automatically as a means of showing where the changes to 'dev' and 'master' come from or is it because someone pushed a local branch by mistake and deleted it later? If it's the latter, is there a way to clean-up the clutter?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

薄情伤 2024-09-10 12:38:13

您在“网络”视图中看到的工件可能是基于合并的工作流程的痕迹。

当合并操作导致合并提交*(即它不是“快进”)时,DAG 模型将包括代表两个分支的部分。当非本地分支被推送时,其祖先将包括最初在本地分支上进行的提交。
*要么使用git merge --no-ff,要么因为两个分支都超出了它们的合并基础。

考虑一系列假设的事件,并且中央存储库中生成的历史 DAG+refs:

A$ git fetch && git checkout -b foo central/dev
# A works and commits to her local branch
B$ git fetch && git checkout -b bar central/dev
# A and B work and commit to their local branches
A$ git checkout dev && git pull &&
   git merge --no-ff foo && git push central dev
# B works and commits to his local branch
C$ git fetch && git checkout -b quux central/dev
# B and C work and commit to their local branches
B$ git checkout dev && git pull &&
   git merge --no-ff bar && git push central dev
C$ git checkout dev && git pull &&
   git merge --no-ff quux && git push central dev
D$ git fetch && 
   git checkout master && git pull &&
   git merge --no-ff dev && git push central master

---o---o-------------------------------D  master
        \                             /
         \             o---o---o     /      (was quux in C's local repository)
          \   o---o   /         \   /       (was foo in A's local repository)
           \ /     \ /           \ /
            o-------A---------B---C       dev
             \               /
              o---o----o----o               (was bar in B's local repository)

本地(foobarquux)分支从未直接推送到中央存储库。但是,“他们的”提交由推送到中央存储库中的 dev 分支(稍后推送到 master 分支)的合并提交引用。

我怀疑 GitHub 网络视图正在向您显示这些间接推送的分支。

如果你想消除分支的这种拓扑证据,你将需要转向基于变基操作而不是合并操作的工作流程(这意味着本地分支的原始“分叉点”将被丢弃,这可能或可能对您的整体工作流程并不重要)。

不要试图让 DAG 看起来“漂亮”。这些工具并不关心 DAG 是否“丑陋”,您也不应该关心。您应该集中精力选择并正确使用分支工作流程,生成 DAG,让工具为您完成有用的工作。

The artifacts you are seeing in the “network” view are probably traces of your merge-based workflow.

When a merge operation results in a merge commit* (i.e. it is not a “fast-forward”), the DAG model of the repository's history will include portions that represent both branches. When the non-local branch is pushed, its ancestry will include the commits that were made originally on the local branch.
*Either by using git merge --no-ff or because both branches had moved beyond their merge base.

Consider a hypothetical series of events and the resulting history DAG+refs in the central repository:

A$ git fetch && git checkout -b foo central/dev
# A works and commits to her local branch
B$ git fetch && git checkout -b bar central/dev
# A and B work and commit to their local branches
A$ git checkout dev && git pull &&
   git merge --no-ff foo && git push central dev
# B works and commits to his local branch
C$ git fetch && git checkout -b quux central/dev
# B and C work and commit to their local branches
B$ git checkout dev && git pull &&
   git merge --no-ff bar && git push central dev
C$ git checkout dev && git pull &&
   git merge --no-ff quux && git push central dev
D$ git fetch && 
   git checkout master && git pull &&
   git merge --no-ff dev && git push central master

---o---o-------------------------------D  master
        \                             /
         \             o---o---o     /      (was quux in C's local repository)
          \   o---o   /         \   /       (was foo in A's local repository)
           \ /     \ /           \ /
            o-------A---------B---C       dev
             \               /
              o---o----o----o               (was bar in B's local repository)

At no point were the local (foo, bar, quux) branches ever directly pushed to the central repository. However, “their” commits are referenced by the merge commits that are pushed to the dev branch (and later to the master branch) in the central repository.

I suspect that the GitHub network view is showing you these indirectly pushed branches.

If you want to eliminate such topological evidence of branches, you will need to move to workflow that is based on rebase operations instead of merge operations (this implies that the original “fork point” of the local branch will be discarded, which may or may not be important to your overall workflow).

Do not get bogged down trying to make the DAGs look “pretty”. The tools do not care if the DAGs are “ugly”, neither should you. You should concentrate on picking and properly using a branching workflow that produces a DAG that lets the tools do useful work for you.

再见回来 2024-09-10 12:38:13

本地分支不应该出现在 github 上,不。除非有人说过,

git push origin branch_name

origin(在本例中为 github)不可能知道该分支。

如果该分支不再作为本地分支存在,您可以通过以下方式从源中删除它:

git push origin :branch_name

Local branches shouldn't show up on github, no. Unless someone has said

git push origin branch_name

there is no way that origin (in this case, github) can know about the branch.

If the branch no longer exists as a local branch, you can delete it from origin by

git push origin :branch_name
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文