Git users are likely familiar with the git pull command, which fetches data from a specified remote repository and merges it with the current branch. However, there’s an alternative approach: pulling changes with rebase. This can often result in a cleaner, more linear history. You can achieve this by adding the --rebase option to your pull command:
git pull --rebase <remote name> <branch name>
But why is this beneficial? Sometimes, instead of merging in the upstream changes, it’s cleaner to reapply your work on top of them. While merging may be preferable for long-term changes, rebasing can keep the history tidier, especially for smaller changesets. Let’s illustrate this with an example.
Suppose I want to incorporate changes from the main Jekyll repository into my fork using rebase instead of merging. Here’s the current state of the repository:
For demonstration, I have Mojombo’s master branch checked out, showing new commits that my master branch doesn’t have.
Now, let’s bring in the changes using rebase from Mojombo’s repository at his master branch:
git pull --rebase mojombo master
After applying the rebase, we can see that my work has been reapplied on top of the changes in Mojombo’s repository.
What’s the difference compared to a normal pull? Let’s find out.
git reset --hard origin/master
git pull mojombo master
With a normal pull, the changes are merged, resulting in a merge commit denoting the merge.
Ultimately, whether to merge or rebase when pulling changes depends on your preference for history organization. If you prefer always using rebase instead of merging during git pull, you can configure this behavior using appropriate configuration options.
In summary, pulling changes with rebase can help maintain a cleaner commit history, particularly for smaller changesets. Experiment with both methods to find the workflow that best suits your needs.