Git Thoughts - Part I - Merge Branch A to Branch B or Rebase B to top of A


I've started a branch, the name is feat A and it was “born” from the main branch. I've started working on my feat A.


Meanwhile Jarvas started feat B, also “born” from the main branch.


Jarvas finished his changes and created a pull request that was approved. His branch was “closed”: reintegrated on the main branch and the old branch reference deleted.

 

Option One - Rebase feat A to the top of Main Branch

  • Re-apply commits from feat A on the top of Main Branch.

This process is done, commit to commit. Following the order of commits in feat A, each commit is applied to the top of the Main Branch. If it detects any conflict that cannot be resolved automatically, the process is paused and it's necessary the user intervention to solve it and continue the Rebase with the next commit.

Gif with visual example of rebasing a branch to top of another
Fig. 2  Rebase feature branch

Option two - Merge from the main branch to feat A

  • Creates new commit on feat A with the new commit refs from Main Branch.

This process is done in one step. If Git detects any conflict that cannot be resolved automatically, it’s necessary the user intervention to solve it and finish the merge.

 

Gif with visual example of merging to update feature branch
Fig. 1 - Merge to update feature branch


I prefer Option one - Rebase. In my opinion it will result in a more clean repository tree and more easy to understand "who comes first" when dealing with feature dependency and repository history.

 

Note:

I've used https://learngitbranching.js.org/ for the Git tree example in the Gif. Both gigures don't represent the example described and the start of the article. The intent was only to give a visual example for the differences between using Rebase or Merge in this use case.

Git Documentation links:

https://git-scm.com/docs/git-rebase
https://git-scm.com/docs/git-merge

Comentários

Enviar um comentário

Mensagens populares deste blogue

Semantic HTML for a conscient Development.

Imagem
In matters of web pages development or construction, there are several approaches: from scratch and implementing everything to modular building with almost drag and drop. The reasons for choosing the strategy for the implementation, in my opinion can be seen as a two way factor: Available budget Complexity of the functionalities in the web page. There are a great number of tools that allow us to build web pages, from static to transactional, without really looking at the HTML generated underneath. On one hand, this is one good thing because it makes web development reachable to a more vast audience. But I would like to ask: are those tools generating complying HTML so assistive technologies can actually understand the structure of the page or event for search engine scraping? Try closing our eyes behind a door. If someone says “Open the door”, you will look for the locker and try to open. If I say “You have a movable obstacle in your front”, you must pull or push it so it can move away
Ler mais

Git Thoughts - Part II - What is rebase?

  Change branch “location” by applying the changes from the commits in another point of the repository tree. How does the process work? The new location for the branch is chosen. The process is done, commit by commit, with the same order they were created. Each commit is applied, starting in the new location and after on the previous commit applied. One commit at a time. If it detects any conflict that cannot be resolved automatically, the process is paused and will need user intervention so it can continue. Until all the commits are successfully applied, all changes are made in a detached Head and the process can be canceled and reverted easily. After applying all the commits and all the eventual conflicts resolved, the head of the branch rebased, now points to the new “last commit”. Every commit has new references so there is now connection between the commits from the original branch and the new one.  There are several variations that can be made controlled by the user, that is call
Ler mais

Testing and automated tests.

"Testing it's not dependable on time constraints, feature delivery is."  There are a great number of test disciplines. The text will focus on automated tests in software development. So I could use a "should" instead of an imperative tone in the title but it seems to get the gap between "I wish" and reality even bigger. Normally, things that stay behind are the ones sacrificed when time gets shorter. The importance of testing implemented/changed chunks of code properly, are difficult when proper planning is done, when time pressure overtakes teams priorities this is neglected at all levels (management and developing). Nowadays, any development framework that wants to honor the title and aspires to completeness, have to include a decent test architecture, facilitators, focus on test reliability and efficiency creating them.   The questions I usually make when I’m thinking about a solution to a problem are: What I want this to do? How will I test it? Wha
Ler mais