How does git rebase work?

28

What happens when you override the following situation:

  • Branch master with 3 commits (A, B and C).
  • After commit C, I created a new branch named design.
  • I made a commit (D) in the branch design and went back to the master branch.
  • I made a commit (E) in the master branch.
  • Currently my commits history is:

    • master: A, B, C, E
    • design: A, B, C, D

    After rebase in the master branch, will the history be as follows?

    • master: A, B, C, D, E
    • design: A, B, C, D

    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.

        
    asked by Filipe Moraes 18.08.2015 в 13:14
    source

    3 answers

    18

    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:

    • Security and traceability: If you do not follow the 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:

    Merging vs Rebasing

    I also leave here images that summarize a good example application:

    Repository Initial State

    Dev-B:SourceSynchronization

    Dev-B:Rebase

    Dev-B:finaloverride

    Dev-B:FinalSynctoSource

        
    answered by 18.08.2015 / 14:23
    source
    14

    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).

    Understanding the step-by-step scenario

    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:

    • master: A, B, C, D, E
    • design: A, B, C, D
    answered by 18.08.2015 в 15:14
    12

    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 ).

        
    answered by 18.08.2015 в 13:57