0

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?

6
  • 4
    This seems to be primarily a (lack of) management problem, not really a software engineering one. Aug 29 at 9:18
  • 4
    Your branch history exactly reflects your branches. As it should.
    – gnasher729
    Aug 29 at 10:01
  • It seems there is a lack of "dev rotation". Otherwise you could also temporarily switch to missing dev's seat and make things work.
    – S.D.
    Aug 29 at 11:14
  • If you can't develop on the develpoment branch, arguably that shouldn't be called development. Perhaps you need a master branch to deploy from, and a development branch that can rush ahead during code freezes, and be merged into master at the end of each code freeze.
    – Alexander
    Aug 29 at 13:24
  • Well, normally I can develop on development; this was just due to the special situation of all other team members being on vacation. Requiring code review for merges into development (not just master) seems normal to me. Aug 29 at 14:05

1 Answer 1

5

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.

5
  • I shied away from rebasing because the branches were already pushed (because I wanted my colleagues to be able to use them) and I was under the impression that rebasing a pushed branch is a bad idea. Aug 29 at 14:01
  • @EikeSchulte What makes you think that rebasing a pushed branch is a bad idea? As long as either nobody else is using that branch, or if they are, then as long as you communicate properly with the people who are using it to make sure they hold off making any changes (ensure they push all their current changes first) and then they pull after you've rebased, then rebasing a pushed branch is generally rather benign. It's mostly a communication/coordination headache so not something you'd want to do very often when other people are working on it since miscommunication and accidents can happen. Aug 30 at 5:55
  • I interpretted your question "...would there have been..." as reflecting on the past for alternatives you could have chosen in the past. In order to learn for the future. Aug 30 at 6:32
  • Generally it is not recommended to rebase public branches and certainly not main. My personal opinion differs from the common recommendations. I think it depends on how many people have checked out you public branch. My guideline is that if you create rebase work for others you should be willing to sit next to each and every one for whom you created rebase problems and personally assist them with rebasing. That means in a popular open source project where thousands have the branch, it is weeks of boring work and you should not rebase public branches. For a team of 3 it is doable. Aug 30 at 6:43
  • Yes, I was hoping to learn for the future. I did think about rebasing but rejected it; maybe that was too dogmatic, as your rule-of-thumb seems reasonable. I will consider it should this come up again. Thank you for the extensive answer! Aug 30 at 6:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.