Git is a magnificent tool. Like many other DevOps tools, it save our ton of time when do software engineering.
This post I try to understand and explain some most complex feature (for me): Git rebase
I have used Git for few year, did a lot of merge, handle conflict, install and operate GitLab etc. And I also used SVN, Mercurial. But git rebase is rarely used.
The recommendation for Dev is use Git rebase instead of merge (again it's depend) but in the most case we should use rebase.
My understanding ab rebase is that It does the same thing as merge but it can compress, reduce or edit commit for cleaner, better history (Git log).
And some rules ab using git rebase (some time I forgot because of less use): never rebase on public branch. But this post show one case can use it ?
https://stackoverflow.com/questions/9622131/git-rebase-merge-squash-my-feature-branch-onto-another-branch
In this post, the guy want to deploy feature_branch to master, it fit the rule "not rebase on pulic branch". But some time or by some Team/Project Git flow, we often deploy to master from dev or staging branch. So what if we rebase master when in dev branch ? It's a public branch too ?
...
I think to understand a complex problem, in this case git rebase, merge I have to dig some deeper underlying mathematics and logic problems. To use and follow some best practice is much easier but it is time benefit. So I am going to draw some graph represent Git commit line, tree or whatever it call and try to ask some question what if and why git rebase in here ? What is the benefit of rebase ? How did it perform compress/combine commit ?
And another questions like merge mode: fast-forward, three-way ...
When we really understanding the way a machine, tool or software work, I think we are more confidence and clear ab almost problem and situation instead of follow a mechanic guide... For example, when you have learned some mathematics course about compress algorithm and make some C program to perform it, then I'll be sure that you have a strong idea what going on inside git tracking changes...
This post I try to understand and explain some most complex feature (for me): Git rebase
I have used Git for few year, did a lot of merge, handle conflict, install and operate GitLab etc. And I also used SVN, Mercurial. But git rebase is rarely used.
The recommendation for Dev is use Git rebase instead of merge (again it's depend) but in the most case we should use rebase.
My understanding ab rebase is that It does the same thing as merge but it can compress, reduce or edit commit for cleaner, better history (Git log).
And some rules ab using git rebase (some time I forgot because of less use): never rebase on public branch. But this post show one case can use it ?
https://stackoverflow.com/questions/9622131/git-rebase-merge-squash-my-feature-branch-onto-another-branch
In this post, the guy want to deploy feature_branch to master, it fit the rule "not rebase on pulic branch". But some time or by some Team/Project Git flow, we often deploy to master from dev or staging branch. So what if we rebase master when in dev branch ? It's a public branch too ?
...
I think to understand a complex problem, in this case git rebase, merge I have to dig some deeper underlying mathematics and logic problems. To use and follow some best practice is much easier but it is time benefit. So I am going to draw some graph represent Git commit line, tree or whatever it call and try to ask some question what if and why git rebase in here ? What is the benefit of rebase ? How did it perform compress/combine commit ?
And another questions like merge mode: fast-forward, three-way ...
When we really understanding the way a machine, tool or software work, I think we are more confidence and clear ab almost problem and situation instead of follow a mechanic guide... For example, when you have learned some mathematics course about compress algorithm and make some C program to perform it, then I'll be sure that you have a strong idea what going on inside git tracking changes...
Comments
Post a Comment