我们正在使用Git,我们的工作流程包含一个'dev'和'master'分支,它位于GitHub和每个开发人员的本地存储库中。没有工作直接在'master'或'dev'上执行,而是在本地分支中执行,只在'dev'上进行合并,然后在'master'上进行合并。我们不会将本地分支机构推送到GitHub。
由于某些原因,开发人员的本地分支出现在GitHub的“网络”视图中,这使网络图混乱(我应该指出分支本身不存在于GitHub上的分支列表下)。 / p>
我的问题是这是否是正常行为并自动发生,以显示“dev”和“master”的更改来自或是因为某人错误地推送了本地分支并稍后将其删除?如果是后者,有没有办法清理杂乱?
答案 0 :(得分:9)
您在“网络”视图中看到的工件可能是基于合并的工作流程的痕迹。
当合并操作导致合并提交 * (即它不是“快进”)时,存储库历史记录的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)
本地( foo , bar , quux )分支从未直接推送到中央存储库。但是,“他们的”提交由推送到中央存储库中 dev 分支(以及稍后到主分支)的合并提交引用。
我怀疑GitHub网络视图正在向您显示这些间接推送的分支。
如果要消除分支的这种拓扑证据,则需要转移到基于rebase操作而非合并操作的工作流(这意味着将丢弃本地分支的原始“fork point”,对您的整体工作流程可能有用也可能不重要。)
不要陷入困境,试图让DAG看起来“漂亮”。工具并不关心DAG是否“丑陋”,你也不应该。您应该专注于选择并正确使用生成DAG的分支工作流程,以便工具为您执行有用的工作。
答案 1 :(得分:2)
本地分支机构不应该出现在github上,没有。除非有人说过
git push origin branch_name
原点(在这种情况下,github)无法知道分支。
如果分支不再作为本地分支存在,则可以通过
从原始分支中删除它git push origin :branch_name