Branch management when you cannot merge due to holidays

Question

I’m working on a small project with two other developers. Our work is on Gitlab. Our general workflow is that we create feature branches by branching off development which get merged back into development after review by one of the other team members.

Recently, the other two team members were on holiday for several weeks simultaneously which meant that I could not merge into development. However, the first change on my list was an internal API change (on the branch new-api) that would affect all other work. Obviously, I didn’t want to base the rest of the work on the old API only to adapt it to the new one once it was reviewed and merged. So I created my feature branches off the head of the new-api branch. I then pushed my branches to Gitlab, as I wanted my team members to see my work during my holidays.

The problem is that the history now shows the unusual branching. Would there have been a cleaner way of organizing this?

Answer 1

You could have rebased before merging or before making the pull requests:

Development work while teammates are on holyday:

*      feature-c
| *    feature-b
| | *  feature-a
| |/
|/
*      new-api
*
*      develop
|

Pull requests/merges after new-api was reviewed and merged:

*     feature-c
| *   feature-b
| | * feature-a
| |/
|/
*     develop
|\
| *   new-api
| *
| *
|/

You use git rebase to move the branches and reattach them to a different base.

• git switch feature-a
• git log to find the last commit of (the old pre code review) new-api-branch on which feature-a was based
• git rebase {commit-hash} --onto develop {commit-hash} is the hash of new-api you found with git log

Note:
hopefully the review of new-api led to some improvements to new-api. When rebasing the commits of the feature-branches they have to adapt to the improved new-api.
This might result in merge conflicts and worse succesful merges silently resulting in broken code.
Don't fear the merge conflicts: you know very well what you intented to do in the commits of the new features and how that should work with the improved new-api.
To have git rebase detect when merging leads to broken code see the -exec-option of git rebase, with it you can have git compile and run the unit tests on your code and pause/break when either detects an error.

Advise:
Use small steps when doing a complicated rebase; don't try to fix all problems at once.
You can use git reflog to find old branch HEADs can use git reset to undo a rebase (when takimg small steps you do not have to redo so much work). Even easier to mark the branch HEAD before starting a rebase git branch -c {my-backup}. Where {my-backup} is a branch name that helps you find it when you want to undo a failed rebase.