In the final step, the new commits on branch-A are now reapplied - but on a new position, on top of the integrated commits from branch-B (they are re-based). At this point, both branches look exactly the same. Next, it applies the commits from branch-B that we want to integrate. However, of course, it won't discard them: instead you can think of those commits as being " saved away temporarily". The command for this is very plain: $ git rebase branch-Bįirst, Git will "undo" all commits on branch-A that happened after the lines began to branch out (after the common ancestor commit).
The scenario is the same as in the previous examples: we want to integrate the changes from branch-B into branch-A, but now by using rebase. Let's walk through a rebase operation step by step. No indication remains that it had been split into multiple branches at some point. Instead, they want the project's history to look as if it had evolved in a single, straight line. Some people prefer to go without such automatic merge commits. If you want to understand a merge operation later, you need to take a look at the history of both branches and the corresponding commit graph. And instead of wrapping a set of related changes, its purpose is to connect two branches, just like a knot. It's a meaningful unit that wraps only related changes and annotates them with a comment.Ī merge commit is a bit different: instead of being created by a developer, it gets created automatically by Git.
Normally, a commit is carefully created by a human being. To make an integration, Git will have to create a new commit that contains the differences between them - the merge commit. In a lot of cases, however, both branches moved forward individually. Both branches then share the exact same history. In Git, this simplest form of integration is called a "fast-forward" merge. In this case, performing the integration is dead simple: Git can just add all the commits of the other branch on top of the common ancestor commit.
In very simple cases, one of the two branches doesn't have any new commits since the branching happened - its latest commit is still the common ancestor. Therefore, their respective latest revisions are of special interest.Ĭombining these three commits will result in the integration we're aiming for. The goal of an integration is to combine the current states of two branches. If you follow the history of two branches in a project, they always have at least one commit in common: at this point in time, both branches had the same content and then evolved differently. When Git performs a merge, it looks for three commits: Understanding Merge a Little Betterīefore we can dive into rebase, we'll have to get into a little more detail about merge. Another option is to return to this chapter after you've had some practice with the basic workflow in Git. While rebasing definitely has its advantages over an off-the-shelf merge, it's also a matter of taste to a great extent: some teams prefer to use rebase, others prefer merge.Īs rebasing is quite a bit more complex than merging, my recommendation is that you skip this chapter unless you and your team are absolutely sure you want to use it.
0 kommentar(er)
