Git Rebase Workflow

Prerequisites and definitions

develop is the integration branch
Redmine is the issue tracker
We are using the project Agile Board on our issue tracker
We are using Gitlab as git server
REPO is our project repository on git server (eg. gitlab@gitlab.sparkfabrik.com:sparkfabrik/company-playbook.git)

Follow these steps to achieve code serenity:

Clone repository: git clone REPO
Pick the feature/user-story to work out from the Agile Board: say it is #12345 - Integrate with billing server
Create a new branch with the following name convention: feature/[#issue-id]_[feature_title-slug] and move on it: git checkout -b feature/12345_integrate_with_billing_server
Working the issue, always add your changes to the stage using git add -p and interactively rewiewing all changes (this is important when code is autogenerated and can overwrite other's work: i.e. a Drupal Feature)
Commit your code with a message following this naming convention: [#issue-id] - Commit message: git commit -m '#12345 - Admins can now store billing-id for a client'
Push it on a remote so that if your PC is blasted by aliens you can avoid being fired

Fetch develop branch, keep integration branch fetched: git fetch
Rebase your branch over develop: git rebase origin/develop
Push to your branch: git push -f or better yet git push -f origin feature/12345_integrate_with_billing_server
Head to Gitlab and open a MR from your branch towards develop
Address possible feedback in your branch and keep pushing over it, Gitlab will update itself with your fixes
When you are done the MR will be merged by a peer or gatekeeper
Switch back on develop and reset to the latest develop: git fetch && git reset --hard origin/develop

Redo from start and live happy! :)

When you open a branch to work out a user-story, and have to name it against the naming convention we exposed, consider that the title part is amendable at need, the issue-id is not!
When you create a new commit, try to keep your message short but significant! #12345 - More love means nothing! A good rule of thumb is: don't write what you did (others can see the code by themselves) but why you did it
If your work spans over a long time (days) we advice you rebase it onto develop at least daily: git fetch && git rebase origin/develop (solve conflicts if they arise and push with -f options).
You can use an optional -i parameter when you rebase your branch onto develop, this way: git rebase origin/develop. In that case, you can pick only the commits you want to rebase, save and quit the interactive editor. Be warned: there shall be dragons!

Last updated on 5 Aug 2019