curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <>
Subject Re: CURATOR-217?
Date Mon, 24 Aug 2015 16:43:38 GMT
I’ll admit that rebase terrifies me. I’ve f’d up several projects with it so I can’t
even type the letters without breaking into a sweat. "git rebase -i” is a lot safer, though.
Here’s what I’ve been doing - let me know if it’s OK. For branches that are off of CURATOR-3.0,
I never merge master. I only merge CURATOR-3.0: “git merge CURATOR-3.0”. In fact, should
we have a branch naming scheme to enforce this?


On August 24, 2015 at 11:30:50 AM, Scott Blum ( wrote:

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 <> 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 (  
> 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 <>  
> wrote:  
> > Yeah, 217 & 161 were the first two big things in 3.0.  
> >  
> > On Mon, Aug 24, 2015 at 9:53 AM, Jordan Zimmerman <  
> >> 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 (  
> >> wrote:  
> >>  
> >> Yes, I merged it in last week some time.  
> >>  
> >> On Mon, Aug 24, 2015 at 3:25 PM, Jordan Zimmerman <  
> >>> wrote:  
> >>  
> >> > Scott, did CURATOR-217 get merged into the new CURATOR-3.0?  
> >> >  
> >> > -Jordan  
> >> >  
> >> >  
> >> >  
> >>  
> >  
> >  

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message