views:

98

answers:

2

So I have cloned a project at github and fixed a patch. Since this is the first time Im working in git Im trying to figure out the best way to put it online.

Upon checking out my own (cloned) repository on github there was only one branch: master. I created a branch, myfix, which now holds one commit, which is the fix for the bug.

  • Should I now push everything to my cloned project on github? I assume that this would create the branch myfix on my github project containing that single fix commit.
  • Should I merge myfix into the master branch, remove myfix and then push everything?

When searching online, it seems that the common/good practice is to leave master untouched, using that purely for pulling from the real/original public project repository (that is, others accepted contributions and such). But others suggest other strategies:

  • Create an upstream branch, put your clean and ready contributions there so others can find them easy, not mixing it up with my other incomplete/experimental branches (I wonder why these would even be online if they were so incomplete).
  • Create a downstream branch, pull others changes in here for offline merging.

If I follow the above two (currently feels a bit overkill though) what purpose would the master branch fill?

Git can do any combination (or all) of the above. This leaves me a bit confused as to how to easy show my work to others. Is there such a "common" workflow? Or is it every man for himself and you post a specific revision in a specific branch (thats pushed) in the issue tracker for the fixed bug?

+2  A: 

Github lets you send pull requests to owners of other repositories, and a request says where to find your interesting changes. This means you don't have to keep all your changes in a particular well-known branch.

Making it easy on the other person will increase your chances of your patch being accepted, so keep a clean master as a common reference point and make changes in branches off of the master. Keep your branches narrow in focus: rather than piling up eleventy-three new features in a single branch, keep them separate where you can do so cleanly.

Greg Bacon
So its not uncommon for branches to be created, pushed, pulled by someone else, merged and then removed?
mizipzor
Correct. After a topic branch has been merged into the project's master, keeping it around provides little benefit.
Greg Bacon
+5  A: 

When you clone a repository, Git automatically creates remote tracking branches that do what you describe for the master branch. You can list these remote tracking branches with:

git branch -r

Because tracking the upstream repository is already done for you, you would normally use your master branch for mainline changes to the project. Here's what I would do in your particular situation:

  • Merge the myfix branch into master in your clone. (Having done this in a "topic branch" is good practice.)
  • Push the master branch to Github. (It's unclear whether you forked the original repository, or just cloned from it. You will need to fork the original repository, creating your own copy, for the next step to work.)
  • Send a Github pull request to the owner of the repository you forked.
Greg Hewgill
Just did that, except that I pushed before merging the badly named "topic branch" back into master. The pull request is from my pushed branch myfix.
mizipzor
That's fine, the branch name doesn't really have any meaning. A commit is just a change from one state of the tree to another, no matter how many names it has.
Greg Hewgill