Some notes to describe to team members how I typically work with a github or bitbucket hosted project.
- Fork
- Branch
- Pull Request
Go to the git repo use and find a 'fork' button and click it. It will ask you where to fork it to. I fork repos into my personal account. IE: I fork amaret/pollenc into navicore/pollenc.
Then I open a shell and cd to where I put git stuff and clone that personal fork.
git clone [email protected]:navicore/pollenc.git
Then cd into the new dir:
cd pollenc
I always then set the upstream branch so that I can merge other team members into my work as I work on it.
git remote add upstream [email protected]:amaret/pollenc.git
I often make a branch corresponding to the feature I work on. Note, I'm making a branch in my fork, NOT in the upstream repo. Making feature branches in the upstream is no fun.
git branch websockets
git checkout websockets
Then I edit the code, make changes.
I will often sync upstream changes to my branch before proceeding.
git fetch upstream
git merge upstream/master
then fix any conflicts that the git command spits out
Then commit 'em.
git commit -a -m "my websocket implementation changes"
Then push 'em to your forked repo:
git push
git will complain that the branch has no upstream branch but suggests what to do. Do that.
git push --set-upstream origin websockets
If you are done with the branch and want to get it upstream:
- go to the web UI
- select the branch you just puhsed
- and create a pull request to amaret/pollenc master
If the system is wired for CI (Travis, Shippable, Jenkins) for pull requests - as all mine are - then a CI process will kick off and notify you if you broke something.
Your changes are still not "merged" at this point. It is polite and sane to mark another team member as a reviewer who should do that actual "merge" click if all looks good.
- I sync to upstream often
- I try to be as elaborate as I can in the pull request. Remember it is markdown and you can put lengthy well formated instructions explaining what you are changing and how to use your changes. If it is github, you can include graphics. Well formatted pull requests are archived and easy to refer to later - worth the effort.
- It looks like a lot and tedious but this flow has become so natural to the way I work that I don't think about it. The benefits are huge.
- There is way more to my daily git usage than what is here but this is the starter kit, google for the rest as you need it - ie: fixing bad commits, version branches, webhooks, deploy keys...