CODEWITHSUNDEEP
gitrebasepull-request
supun
supun

Reputation: 123

can I rebase more than once?

I'm getting reintroduced to git. I'm not that familiar with rebasing, and I want to start using it.

The team I'm working with does not allow commits into our master branch. We have to create a feature branch and then create a Pull Request.

When I'm the only person working on a feature branch, I'd like to keep my feature branches up to date with master, and I want my commits to be tacked on at the end before I create my pull request.

So, my plan is to work away on my feature branch and periodically rebase with (on?) master. Will that keep all of my commits at the end of the change history when I'm ready to submit my pull request?

Upvotes: 7

Views: 8843

Answers (5)

sumit singh
sumit singh

Reputation: 542

As far as rebasing is concerned, you can do any number of times as you want. But considering your scenario, continuously rebasing feature over master can cause problem in certain situation.

Consider a scenraio Where some other branch say 'A" was merged to your feature branch due to some dependency. Now all the commits that were made into this merged branch( say X number of commits) will be introduced in your feature branch as well along with one additional merge commit. Now, if you try to rebase your feature branch with master, rebasing will happen for all the X commits that were introduced by merging of branch A. Thus, there are chances of conflicts X number of times during this operation.

However, it would be better to just merge master into your feature branch. In this case, conflict can occur only once depending on current statue of your feature branch and master branch.

Upvotes: 3

Eddie Knight
Eddie Knight

Reputation: 29

It seems you have the correct understanding of the process. My team operates similarly to what you described, because our team lead prefers to have all related changes in a single (preferably small) commit.

After I finish making changes on my feature branch, I make sure that my local master matches our upstream branch, then git rebase -i master.

This gets everything up to date with master, and -i allows me to review all my commits- and squash them together as per my team lead's request.

Like you're suggesting, rebasing is always my last step before making a pull request.

Upvotes: 0

sylvain.joyeux
sylvain.joyeux

Reputation: 1699

Rebasing a branch on another "re-applies" (fairly smartly, these days) the commits of the currently checked out branch on top of the tip of the target.

So, yes, if you do it over and over again then you will keep your current branch up to date. I think it's a typo in the question, but you do not want to "rebase master" though, you want to rebase on master.

Sometimes, you might get a lot of conflicts, in which case you probably should rather think about merging from this particular point on. Conflict resolution while rebasing is quite a pain since you have to fix the conflicts from the first commit onwards: the very first merge you will do will create conflicts if further commits modify the same piece of code, and so on and so fort. With a merge you fix all of them at once. But them, once you merge you have to keep on merging.

Upvotes: 1

kabanus
kabanus

Reputation: 25895

Yes, you can rebase as many times as you want. In fact, what you want to do is so common the pull command has a built in flag for it:

git pull --rebase

Upvotes: 1

user743382
user743382

Reputation:

Yes, you can rebase more than once.

After rebasing, you get a fresh set of commits. These commits are exactly like all other commits and hold no record of having been rebased.

The main thing you need to be careful for is the possibility of rebase conflicts. Since you're rebasing more often, you possibly get conflicts more often, and need to resolve them more often. But as long as you're prepared to handle them, you should be fine.

Upvotes: 2

Related Questions