Correct. When I say "main" branch vs. "feature" branch I just mean the stable branch everyone is working against (3.0 or master) vs. a feature branch where you're actively working.
You'll get to a point in development where you'll think "Hey, there are changes on the main branch I'm working against that I really need to pull into my feature branch." At that point (particularly if you have an svn background) you'll be tempted to merge the main branch into your feature branch. I would suggest not doing that, as it makes the history very muddy to follow. Instead, my workflow is usually more like this: Suppose I'm working on CURATOR-218. It was originally branched off 3.0, and I want to pull in new changes. git remote update git rebase -i origin/CURATOR-3.0 This pulls up an editor that gives me the list of commits to rebase. I would typically exit out of the editor to at this point to accept the commit list, but if I'm so inclined, I'll do things like reorder the list, or squash commits like like "wip" or "minor reformat" into a more curated set of logical commits. Once you exit the editor, git goes through and applies each commit, one at a time, to the head of the target branch. It's like picking up your commit chain and dumping it at the end of the target branch, as if all your work had been done against what's now the head of that branch. You'll may have to fix conflicts along the way, but usually not much more than if you did it as a merge. I'd encourage us to try this out a couple times and get a feel for the rebase flow. It's a little more to get your head around at first, but the upside is you end up with really easy to follow commit histories, which makes it way easier to untangle problems later if they crop up. On Mon, Aug 24, 2015 at 12:17 PM, Jordan Zimmerman < [email protected]> wrote: > Can you explain this in detail? For me, I have some features that are > 3.0.0 based so I’m treating CURATOR-3.0 as a kind of master. The true > “master” is Curator 2.x only, right? > > -Jordan > > > > On August 24, 2015 at 11:10:08 AM, Scott Blum ([email protected]) > wrote: > > BTW: I noticed a couple of new commits > (ba4b5d8cb1f9733d3901b0b619528454d3dbf8c8 > & 2343daf29388566b0efa0b0a2ad21574fb534a27) where 3.0 is getting merged > into feature branches. Almost every project I've been on we don't tend to > do that as it leads to confusing history (this isn't just aesthetic, it > can > get harder for tooling to figure out what happened). If I want to pull > changes from the main branch into my feature branch, I would typically > *rebase* my feature branch against the main branch. > > On Mon, Aug 24, 2015 at 12:05 PM, Scott Blum <[email protected]> > wrote: > > > Yeah, 217 & 161 were the first two big things in 3.0. > > > > On Mon, Aug 24, 2015 at 9:53 AM, Jordan Zimmerman < > > [email protected]> wrote: > > > >> OK - Also, is CURATOR-161 complete? The issue is still open in Jira. > >> > >> > >> > >> On August 24, 2015 at 12:47:21 AM, Cameron McKenzie ( > >> [email protected]) wrote: > >> > >> Yes, I merged it in last week some time. > >> > >> On Mon, Aug 24, 2015 at 3:25 PM, Jordan Zimmerman < > >> [email protected]> wrote: > >> > >> > Scott, did CURATOR-217 get merged into the new CURATOR-3.0? > >> > > >> > -Jordan > >> > > >> > > >> > > >> > > > > > >
