Local branches show-up on GitHub's “Network” view

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).

  • Mercurial diff not working after move/rename
  • How to restore shelved changes in Intellij when the shelf tab is not shown?
  • Delete all local changesets and revert to tree
  • Git pull from another repository
  • is `hg forget` the same as `git rm --cached`?
  • git-svn rebase “File name too long”
  • 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?

  • How to commit a long Git merge in the middle of resolving conflicts
  • How to `pip install` a package that has Git dependencies?
  • git clone error : fatal: git upload-pack: aborting due to possible repository corruption on the remote side
  • Eclipse luna - Internal error, trying to import from git
  • Git: duplicate commits after local rebase, then pull
  • git can I speed up committing?
  • 2 Solutions collect form web for “Local branches show-up on GitHub's “Network” view”

    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.

    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
    Git Baby is a git and github fan, let's start git clone.