Thanks for the explanation Chris! That definitely helps. > > If you're working on a feature branch by yourself, what is a good > > workflow for keeping the branch in up-to-date with "master" as you're > > developing on the feature branch or is this unnecessary? Should you > > just wait until you want to officially integrate the feature branch > > into the "master"? > > > > We were doing: > > > > commit to local feature branch > > push to remote feature branch > > ... repeat.... > > rebase from master (occasionally) > > push to remote > > > > but at this point the branches have diverged. > > > > We're coming at this from SVN, so we might just be thinking about this > > the wrong way. > > Git's rebase feature is a *very* nice, clean way to keep a feature > branch up to date with the master branch. But, as you've seen, > rebasing can make things a bit confusing you need to push that feature > branch to other people. > > I've found that a good rule of thumb is to never rewrite (i.e. rebase) > branches that have already been shared with others. Of course there's > nothing impossible or fundamentally bad about pushing rewritten > branches like this. But, unless people are expecting it to happen and > know how to deal with it when they pull, it can cause confusion, > particularly on teams that are just getting acquainted with Git. Two questions here. First, the command to rebase based off another branch that is *not* the upstream branch involves --onto, correct? For example, if I've been working on branch awesome_feature and I want to rebase using all the work that's been done in master since my branch was created, would I use: "git rebase --onto master <upstream_repo_name>" Secondly, as someone pulling a branch that has been rewritten, do I use the --force flag: "git pull --force" or will rebasing suffice? > Instead, if a feature branch is going to be shared with others, and > it's going to be long-lived, then we keep it up-to-date by merging > from master every now and again, rather than rebasing. > > On the other hand, if I'm working on a feature branch by myself, and I > haven't shared it with anyone yet, I frequently rebase against master > to keep things clean. I also use interactive rebase a lot to tidy up > commits. But as soon as I've shared my branch with the team, I no > longer do any rebasing/rewriting. > > If there are Git wizards on your team, it is true that they may find > this an inflexible way of working. But I've found it to be a good > compromise between ease of pulling and maintaining a clean commit > history. > > Chris -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html