What happens when you override the following situation:
Currently my commits history is:
After rebase in the master branch, will the history be as follows?
If the answer is yes, what is the purpose of redoing the history when one of the advantages of the GIT is to be able to see the history as it is? If I can manipulate the history, then I may not see what actually happened.
The main benefit of rebase is that it gets a much cleaner approach.
First, it eliminates unnecessary merge, which is required by git merge .
Secondly, rebasing also results in a perfectly linear project history where you can track the start of the entire project path without any problems. This makes it easier to navigate your project with commands like git log , git bisect and gitk .
But there are two compromise solutions to this story:
rebasing rule of thumb, rewriting project history can potentially be catastrophic for your collaborative workflow. And, less importantly, rebasing loses the context provided by merge commit , if you can not see when the upstream changes have been incorporated into the resource. The best way to understand the whole process is to read the following article:
I also leave here images that summarize a good example application:
Answering your questions.
1 - After rebase in the master branch, the history will be following way?
Yes
2 - If yes, what is the purpose of redoing the history when one of the advantages of GIT is to be able to see the history as it is?
The problem with rebase is that it changes history, as well as other git commands (such as those with the --hard attribute). This is why it is recommended only in very specific cases . Git does not have the premise of protecting the change history at any cost but by default preserving it.
Here's what happened in each% of% you did.
Remembering that commit is where your repository is currently pointing (can be HEAD , branch or tag specific).
Next, I'll detail what happened in each step you described to commit .
Come on:
Branch master with 3 commits (A, B and C).
A<---B<---C
|
|
|Master|
|
HEAD
Command:
git checkout master
After commit C, I created a new branch named design.
HEAD
|
|design|
|
|
A<---B<---C
|
|
|Master|
Command:
git commit -m "Commit C"
git checkout -b design # cria a branch design a partir da branch atual (master)
I made a commit (D) in branch design
HEAD
|
|design|
|
|
.---D
/
A<---B<---C<--´
|
|
|Master|
Command:
git checkout design
git commit -m "Commit D"
and returned to the master branch.
|design|
|
|
.---D
/
A<---B<---C<--´
|
|
|Master|
|
HEAD
Command:
git checkout master
I made a commit (E) in the master branch.
|design|
|
|
.---D
/
A<---B<---C<--´-----E
|
|
|Master|
|
HEAD
Command:
git commit -m "Commit E"
And doing rebase :
|design|
|
|
.---D<----E'
/ |
A<---B<---C<--´ |
|Master|
Command:
git checkout design
git rebase master
As you can see, with the rebase of the master in the rebase branch, the design commits go to the top of the E branch.
So, as you may notice in the end, the commits were as you said:
That's exactly what happens. The main advantage of rebase compared to merge is that you will have a much cleaner (and what it really is) history than a merges project, since it will first apply all commits to the branch that is "overflowing ", then apply the commits of the branch that is being" rebased ". However, rebase can lead to some code losses that will not happen in merge , so it is advisable for beginners not to use rebase , but merge .
In addition, the gold rule of rebase defines when to do or not rebase . rebase is only advisable for private branches, ie it should be avoided on public branches , such as master , for example. This prevents you from messing up public branches by reorganizing your commits.
In summary, rebase is just to maintain a cleaner and more linear history, avoiding "unnecessary" commits caused by a merger conflict. Note that some tools work only with rebase , as is the case of gerrit , which creates a dependency line for the sent commits to the main branch (usually master ).