Re: workflow for working on feature branches and incrementally incorporating "master" changes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]