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)
Steps
Follow these steps to achieve code serenity:
Daily work
- 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
When your issue is done
- 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 yetgit 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! :)
Pro-tips
- 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!
Useful resources
- Force history rewriting on push: https://www.atlassian.com/git/tutorials/rewriting-history