1

I'm developing a feature in a local branch. I just rebased it, and merged my changes back into the main branch. If I want to continue to develop in a local branch, can I continue to develop in the existing one? If I rebase with that branch, will it rebase the commits since the last merge, or will it once again rebase all the commits that have been made to that branch?

Or should I just delete it and start a new one?

Thanks.

Catherine
  • 13,588
  • 9
  • 39
  • 60

2 Answers2

1

You don't have to rebase each time. You will potentially have many more conflicts to resolve as a rebase applies your commits one at a time. So consider just merging instead.

The second rebase will only move the commits since you merged if you point your topic branch onto the new merge commit. Rebase goes down to the last common commit in history and moves that range on top of the branch you specify.

Notes:

  1. Rebasing changes history effectively of that branch. If someone else is working on that branch as well, you will give them a nasty surprise when they try to push their changes up and git tells them they can't! This is for a good reason. They will have to rebase THEIR work to push it up. As you can see, this can go on in circles the more people work together.

  2. Merging is not as evil as some people think. Because a lot of people are used to trunk-based development, they like to see a nice linear history. When everyone is merging, it can look quite different! The answer to this is that eventually we outgrow needing to look at lines joining commits and can simply rely on the tooling to tell us what is merged already and what still needs merging - regardless of the hairy lines connecting everything together. Merging is probably what you will appreciate more as you get more experience.

  3. Since you are doing a branch for you feature, this is a good read about a process that I work with and hope it can shed a bit of light on the pros and cons of branch-per-feature. Hope you keep them short lived! link: https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

user229044
  • 232,980
  • 40
  • 330
  • 338
Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
  • From everything I've heard, the best way to merge in new development is via a rebase. http://stackoverflow.com/questions/457927/git-workflow-and-rebase-vs-merge-questions I'm just trying to figure out what point the rebase takes as its starting point. – Catherine Oct 18 '11 at 01:18
  • not necessarily. Both have pros and cons. As for your question. If your branch points to the second parent of the merge you did, the rebase will take everything and cause headaches. Checkout your branch and `git merge --ff-only master` to point it to the merge. The next rebase will only consider your commits since that merge. – Adam Dymitruk Oct 18 '11 at 01:22
  • By the way, when I started with git, for the first few months, I thought rebasing was the bees' knees too. ;) – Adam Dymitruk Oct 18 '11 at 06:54
1

Yes, you can carry on working on your local branch (let's say it's called feature) and whenever you like do a git rebase master while on feature. The one point of caution about this is that in general you shouldn't rebase your branch once you've made it public (i.e. pushed it to another repository or allowed someone to fetch it from your repository). You should only merge your feature branch into master when you consider the feature that you've been developing to be complete and tested. After that, if you want to add another feature, I would create a new branch for that.

When you run git rebase master while you're on feature, git starts by considering every change in feature that isn't in master. (This is approximately the set of commits you see from git log master..feature.) It then tries to reapply the changes introduced by each of those commits onto master, but skipping any that seem to have already been applied. The implication of this in your situation is that if you've merged feature into master and then made some more commits on feature, it's only those since the merge that will be reapplied in a subsequent rebase.

Mark Longair
  • 446,582
  • 72
  • 411
  • 327