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 trialTahir Imran
Courses Plus Student 8,788 PointsWhat 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
24,793 PointsTahir, 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
Courses Plus Student 8,788 Pointswhy is it suggested "never do a rebase".
Tahir Imran
Courses Plus Student 8,788 PointsI 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.