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

  • Why might git log not show history for a moved file, and what can I do about it?
  • In short, what are the advantages of git and mercurial over subversion?
  • Is it safe to use the same ignores file for Git, Mercurial, and Bazaar?
  • What is the Difference Between Mercurial and Git?
  • Convert svn to git using git svn clone
  • Does Git treat add/remove as a rename?
  • 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?

  • When you clone a repo like Laravel into an existing project do you pull it in as submodule even if you're not planning to contribute?
  • git website update strategy - how to sync dev and live repositories?
  • Troubleshooting misplaced .git directory (nothing to commit)
  • Git Remove unwanted commits from a Pull Request
  • How to cleanly get (“copy”) a remote git branch to local repository
  • Do I need Git to use Github in JetBrains IntelliJ IDEA?
  • 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.