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

  • Revert one change from the diff
  • What makes merging in DVCS easy?
  • What's so great about git?
  • Git remove directory
  • ISO a version control tool that can manage files that are NOT under a directory tree marked as managed by the VC tool
  • How can I learn to understand how Mercurial works, as an experienced git user?
  • 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?

  • cannot run hooks/post-update: No such file or directory
  • How can I use Git locally in an SVN+Visual Studio environment
  • Separate git branch into multiple branches to merge to master
  • Git push hook to disable push to branch
  • how to create pull request if jenkins job running on feature branch is successful
  • Dynamic version from git with go get
  • 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.