<commit_before>---
layout: post
title: pull with rebase
category: advanced
published: false
---

Users of Git are hopefully aware that a @git pull@ does a @git fetch@ to pull down data from the specified remote, and then calls @git merge@ to join the changes received with your current branch's work. However, that may not always be the best case. You can also "rebase":http://gitready.com/intermediate/2009/01/31/intro-to-rebase.html the changes in, and that may end up being a lot cleaner. This can be done simply by tacking on the @--rebase@ option when you pull, like so:

@git pull --rebase <remote name> <branch name>@

So, why is this useful? Sometimes it's easier not to merge in the upstream content and it's better just to reapply your work on top of the incoming changes. For long term changes, it is probably best to merge, but for smaller changesets history will stay cleaner with rebase. So let's say I wanted to use rebase instead of merging to bring in upstream changes from the main "jekyll":http://github.com/mojombo/jekyll repository into my "fork":http://github.com/qrush/jekyll. So the repository looks like this right now:

p=. !/images/pull1.png!

Just for demonstration purposes, I've got mojombo's master checked out so you can see that there's a few new commits that my master branch doesn't have: (The three commits starting at 'mojombo' and going down to 'mojombo/master' aren't in the above graph)

p=. !/images/pull2.png!

So, let's bring in the changes using rebase from the remote for mojombo's repository at his master branch: (warnings removed)

<pre>
$ git pull --rebase mojombo master
From git://github.com/mojombo/jekyll
 * branch            master     -> FETCH_HEAD
 First, rewinding head to replay your work on top of it...

Applying: Making rake test happy on 1.8.7
Applying: Starting on yaml categories
Applying: Adding support for setting post categories...
Applying: Added publish flag to posts, not preventing... 
Applying: Making sure that posts flagged as published...
Applying: Adding explanations for new YAML front matter...
Applying: Removing some bad formatting in the README
</pre>

Now if we look at the master branch's history again:

p=. !/images/pull3.png!

You can see that my work (everything from the 'mojombo' label up) has been rebased on top of the work already in mojombo's repository. Great! So what's the difference between this and a normal pull? Let's find out. 

<pre>
$ git reset --hard origin/master
HEAD is now at 60709da Removing some bad formatting in the README

$ git pull mojombo master
From git://github.com/mojombo/jekyll
 * branch            master     -> FETCH_HEAD
Merge made by recursive.
 VERSION.yml    |    2 +-
 jekyll.gemspec |    7 ++++---
 2 files changed, 5 insertions(+), 4 deletions(-)
</pre>

So first I brought the repository back to where my original state was, then just did a normal pull. Since it's a merge, it appears as such:

p=. !/images/pull4.png!

Now you can see the upstream changes were brought in, and a new commit was made to denote that the merge happened. Sometimes you may want to delineate history like that, but not always. It's really up to you and how you want to build your history. A related note: if you'd like to always use rebase instead of merging when doing @git pull@, check out this "awesome tip":http://tumbl.strelau.net/post/47338904/git-pull-rebase-by-default on how to set your configuration options to do so.
<commit_msg>[de] Translated 2009-02-11-pull-with-rebase<commit_after>---
layout: post
title: Pull mit Rebase
category: advanced
published: true
---

Git-Anwender sind sich hoffentlich bewußt, dass ein @git pull@ ein @git fetch@ zum Herunterladen der Daten aus einem entfernten Repository durchführt und dann @git merge@ aufruft, um die empfangenen Änderungen mit dem aktuellen Arbeitszweig zusammenzuführen. Das mag jedoch nicht immer die beste Wahl sein. Du kannst die Änderungen ebenso mittels "rebase":http://de.gitready.com/intermediate/2009/01/31/intro-to-rebase.html einpflegen, das um ein vielfaches sauberer ist. Das kann einfach durch die Option @--rebase@ des Pull-Befehls erreicht werden, ungefähr so:

@git pull --rebase <remote name> <branch name>@

Aber warum ist das nützlich? Manchmal ist es einfacher, den Inhalt von Upstream eben nicht einzupflegen, sondern deine Arbeit auf die eingehenden Änderungen erneut anzuwenden. Für Langzeitänderungen ist ein Merge wahrscheinlich besser. Aber für kleinere Änderungen wird die Historie mittels Rebase sauberer bleiben. Nehmen wir an, ich möchte Rebase anstelle von Merge verwenden, um ein paar Upstream-Änderungen aus dem Hauptrepository von "jekyll":http://github.com/mojombo/jekyll in meinen "Fork":http://github.com/qrush/jekyll zu übertragen. Das Repository sieht aktuell ungefähr so aus:

p=. !/images/pull1.png!

Zu Demonstrationszwecken habe ich mojombos Master ausgecheckt, so dass du sehen kannst, dass es hier ein paar Commits gibt, die mein Master-Zweig nicht hat: (Die drei Commits, die bei 'mojombo' beginnen und bis 'mojombo/master' gehen, sind nicht in der obigen Grafik)

p=. !/images/pull2.png!

So, holen wir die Änderungen mit Rebase von mojombos entferntem Repository in seinem Master-Zweig: (Warnungen wurden entfernt)

<pre>
$ git pull --rebase mojombo master
From git://github.com/mojombo/jekyll
 * branch            master     -> FETCH_HEAD
 First, rewinding head to replay your work on top of it...

Applying: Making rake test happy on 1.8.7
Applying: Starting on yaml categories
Applying: Adding support for setting post categories...
Applying: Added publish flag to posts, not preventing... 
Applying: Making sure that posts flagged as published...
Applying: Adding explanations for new YAML front matter...
Applying: Removing some bad formatting in the README
</pre>

Jetzt schauen wir wieder auf die Historie des Master-Zweigs:

p=. !/images/pull3.png!

Du kannst sehen, dass meine Arbeit (alles von der Bezeichnung 'mojombo' und aufwärts) schon auf der Arbeit in mojombos Repository aufsetzt. Großartig! Was ist aber der Unterschied zu einem normalen Pull? Wir finden es heraus.

<pre>
$ git reset --hard origin/master
HEAD is now at 60709da Removing some bad formatting in the README

$ git pull mojombo master
From git://github.com/mojombo/jekyll
 * branch            master     -> FETCH_HEAD
Merge made by recursive.
 VERSION.yml    |    2 +-
 jekyll.gemspec |    7 ++++---
 2 files changed, 5 insertions(+), 4 deletions(-)
</pre>

Zuerst habe ich das Repository zu seinem ursprünglichen Zustand zurück gesetzt und dann habe ich einen normalen Pull ausgeführt. Da es ein Merge ist, erscheint es auch als solcher:

p=. !/images/pull4.png!

Du kannst nun sehen, dass die Upstream-Änderungen übernommen worden sind. Ein neuer Commit verdeutlicht, dass ein Merge stattgefunden hat. Manchmal möchte man die Historie genau so gestalten, aber eben nicht immer. Es ist dir überlassen, wie du deine Historie aufbaust. Wenn du immer Rebase anstatt Merge mit @git pull@ ausführen möchtest, hilft dir dieser "Tip":http://tumbl.strelau.net/post/47338904/git-pull-rebase-by-default weiter. Er zeigt, welche Konfigurationsoptionen gesetzt werden müssen.
{'fraction_non_alphanumeric': 0.07377963737796374, 'fraction_numerical': 0.010320781032078103, 'mean_word_length': 4.125804145818441, 'pattern_counts': {'":': 8, '<': 15, '<?xml version=': 0, '>': 19, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2967244', 'n_tokens_mistral': 2260, 'n_tokens_neox': 2184, 'n_words': 1000}