It’s one of the eternal questions that ignite all dev discussions, on par with:
- Tabs vs Spaces
- Statically typed vs Dynamically typed
- Han Solo vs Greedo
- Jacob vs Edward
To make things simpler, I’m going to use an analogy. Let’s step away from code and programming for a while.
Integrating a paper research team
- You recently integrated a group of people who are working on a big article or thesis. As you can imagine, you won’t do all the work and neither will the rest of your team. The work will be divided into fairly equal parts, so that each member of the team can focus on their branch of work.
- A given member of your team is the lead researcher. This means that their decisions and comments carry more weight; in case of a draw, they are the ones who have the final say. Therefore, we can say that your lead researcher’s work is the source of your truth.
- You have been assigned a new chapter on the research. You Google some existing papers on the subject (based on the main research document), find some images, plot some graphs, draw some conclusions, etc. A few days later, the lead researcher says some other colleague finished their part of the work and that piece has been merged into the main document (which, as I mentioned earlier, is your source of truth).
How should you continue your work from now on? How will you incorporate the newest additions into the research you’ve done so far? What if it clashes with what you currently have? Since the main document is your source of truth, you know it was approved by your peers and by the lead researcher, so you have to do you work starting from there!
Adding new information / Getting updates
How you think it will happen:
How it will most likely happen (with fewer deaths and injuries, hopefully):
Before the YOU’RE A REBASE PURIST accusations start pouring in, let me say that git merge has its advantages (of course it does!), the same way that git rebasehas its disadvantages. People who’ve been through it know that solving merge conflicts is easier and a lot less cumbersome when you use git merge.
However, what I want to focus is not which one is better, but rather which should be used in which situations.
Going back to the research paper analogy, once you get the updated version of the main document, rebasing your work on it will produce a more coherent work. If you were to merge everything together, you’d probably end up with clashing definitions and mixed up pages (if you started your work on page 20, and the latest document has 23 pages, your work does not belong on page 20 — the same way your commits will be spliced in-between the main branch’s commits).
Furthermore, when checking the log, we will see changes on both sides (main branch and our branch). If we place our changes on top of the most recent commit, there’ll be a straight line detailing in which order everything was done, and so we end up with a more coherent and clearer log history (and we don’t have to read through all the Merge branch develop into dl/feat-123/example commit messages as well).
Merging your research back into the main document
Now that you have your work sorted out and cleaned up, it’s time for the final review before merging it into the main document. By doing this, the moment your work was added to the main research will stand out, because everyone will know when what you did was introduced.
Back to code
I think that most of what I explained before was self-explanatory. Either way, here’s a quick recap, with code:
- You’re added to a repo
- Someone assigns you a feature (let’s assume the main branch is develop)
- Someone updates develop, so you should rebase your branch
- Once you’re finished, open a pull request, get your code reviewed, and merge it into develop
Summing everything up
If in the future you have any doubts about whether you should merge or rebase, remember the following:
- Always rebase from parent branch: this way your work will always be on top of the most up-to-date version of the work (and you avoid having multiple merge commits, keeping you branch history cleaner and clearer)
- Always merge into parent branch: when you merge your branch, you will know when that was done, since there will be a merge commit stating it!
Whether it’s frontend, backend, mobile or DevOps, at Runtime Revolution we have a spot for you!
Top comments (2)
I feel that I couldn't understand how the paper example provides clarity on the benefit of rebase.
To target this same subject I choose to focus the discussion towards communication. Rebase provides a means to work out your chapter before you tell anyone about it.
Git is a Communication tool
Jesse Phillips
Hey Jesse, thanks for you reply!
I understand your point, I knew this metaphor wouldn't resonate with everyone. I tried to approach this subject from an "history of events" point of view, but also seeing commits as pages of a research paper.
Your metaphor sounds interesting, definitely gonna read your post!