We’ve been using Git internally for quite some time now and have a pretty good work flow within our team. Yesterday we wanted to submit some bug fixes to a project on GitHub. That is something new to us. So this is what we did:
- Cloned their repository
- Forked the upstream
- Added our fork as a remote
- Fixed some bugs in the master branch
- Pushed master to our remote fork
- Sent a pull request
- They pulled the changes
git fetch origin- On master:
git merge origin/master
Is this the correct way to do things? We ended up with an extra “Merge commit ‘origin/master'” message that other developers don’t seem to get. Also in the log we can see our commits twice.
Everything seems to be OK, but it just feels wrong. Are there good GitHub workflow pages? The Git help pages seem to miss the how to do the local changes part.
I figure if we’d rolled back our master branch after pushing the changes to the fork we wouldn’t have this problem, but that does not feel right either.
It is one way.
I prefer cloning my GitHub repo (the one forking a GitHub project “theirRepo”), instead of directly cloning an existing “theirRepo”.
And I would recommend rebasing your master branch on top of “theirRepo”, instead of merging.
I believe that would avoid seeing your commit twice in the log, and would avoid the extra “merge” commit message.
git fetch theirRepogit rebase theirRepo/masterSee also various similar strategies discussed (for another case, but that can give you some ideas) in this SO question: How do I re-play my commits of a local git repo, on top of a project I forked on github.com?