Welcome to the Treehouse Community

Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.

Start your free trial

Development Tools Git Basics Why Version Control Matters Introduction to Git Basics

Tahir Imran
PLUS
Tahir Imran
Courses Plus Student 8,788 Points

What does GIT --rebase do ?

I am using GIT in my project. I have few local changes .I performed a local commit. I happen to update my local repo using git pull .

After the gill pull I was unable to push my commit. I got an error : your ahead by 1 commit. use Rebase.

I wanted to understand the meaning and uses of Rebase.

3 Answers

Justin Black
Justin Black
24,793 Points

Tahir, In explanation to your question about rebase: I wouldn't say that it's suggested to 'never do a rebase', as in the professional world you sometimes have to.

Pro's to Rebase:

  • Simplifies your history
  • Is the most intuitive and clutter-free way to combine commits from multiple developers in a shared branch

Con's to Rebase:

  • Slightly more complex, especially under conflict conditions. Each commit is rebased in order, and a conflict will interrupt the process of rebasing multiple commits. With a conflict, you have to resolve the conflict in order to continue the rebase.
  • Rewriting of history has ramifications if you’ve previously pushed those commits elsewhere. In Mercurial, you simply cannot push commits that you later intend to rebase, because anyone pulling from the remote will get them. In Git, you may push commits you may want to rebase later (as a backup) but only if it’s to a remote branch that only you use. If anyone else checks out that branch and you later rebase it, it’s going to get very confusing.

Looking at the above pros/cons, it’s clear that it’s generally not a case of choosing between one or the other, but more a case of using each at the appropriate times.

To explore this further, let’s say you work in a development team with many committers, and that your team uses both shared branches as well as personal feature branches.

With shared branches, several people commit to the same branch, and they find that when pushing, they get an error indicating that someone else has pushed first. In this case, I would always recommend the ‘Pull with rebase’ approach. In other words, you’ll be pulling down other people’s changes and immediately rebasing your commits on top of these latest changes, allowing you to push the combined result back as a linear history. It’s important to note that your commits must not have been shared with others yet.

By taking this approach, when developing in parallel on a shared branch, you and your colleagues can still create a linear history, which is much simpler to read than if each member merges whenever some commits are built in parallel.

The only time you shouldn’t rebase and should merge instead is if you’ve shared your outstanding commits already with someone else via another mechanism, e.g. you’ve pushed them to another public repository, or submitted a patch or pull request somewhere.

However, as a lone developer, you won't be using rebase really at all. Unless you dev on multiple machines, make some changes to done and forget that you've already done some code on the other and pushed it to your remote repository. In this case, you would rebase to bring the remote code into your current code so you can then run your push.

Tahir Imran
PLUS
Tahir Imran
Courses Plus Student 8,788 Points

I have a scenario:

Here is the series of commit in my repo

6thcommit enum added 5thcommit enum added 4thcommit enum added 3rdcommit new mthod added 2ndcommit new mthod added 1stcommit new mthod added

git revert hashvalueof3rdcommit this resulted in a Conflict.

git revert hashvalue4thcommit WORKS fine.

Why is that revert of 3rd commit landed in conflict.