views:

107

answers:

2

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?

+2  A: 

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
deanWombourne
As I mentioned the branch itself doesn't exist on origin (GitHub) but rather it's effect can be seen in GitHub's "Network" view.
Zubin
github can't reach into your developer machine and see what you've got there - if it's on the network view then at some point it must have been pushed into github. There's lots of caching going on in the network view so the tags / branches shown might be out of date?
deanWombourne
Though thinking about it - are you sure it's a branch and not a tag? What does `git tag` output?
deanWombourne
There are no tags as of now on any of the branches, so I'm guessing (as you mentioned) at some point the local branch has been pushed and later deleted.
Zubin
+3  A: 

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.

Chris Johnsen