[cmake-developers] Topic-based Git workflow for CMake

[Michael Wild]

On 5. Jun, 2010, at 17:46 , Miguel A. Figueroa-Villanueva wrote:

> On Thu, May 13, 2010 at 11:47 AM, Brad King wrote:
>> Hi Folks,
>> 
>> We are about to switch to a branchy, topic-based workflow for CMake
>> development with Git.  The approach is based on a workflow documented
>> in "git help workflows".  We've written a Wiki page to document it:
>> 
>>  http://public.kitware.com/Wiki/Git/Workflow/Topic
>> 
>> along with step-by-step development instructions.  Please read this
>> carefully before doing any development after the transition to the
>> new workflow.
> 
> Hello Everyone,
> 
> I was reading along the wiki page on the new workflow and in an effort
> to understand things better I would like to have someone clarify
> something about the "avoid the urge to merge" statement. That is, I
> understand the concept and why it is necessary to keep the history
> shape cleaner.
> 
> However, one could have a balance that satisfies both the "urge to
> merge" and the clean history by rebasing the topic branch to the
> current master, right?
> 
> That would change the sequence of commands to something like this
> (bear in mind that I'm not familiar with git, but it should be close):
> 
> # create your topic branch
> git checkout master
> git checkout -b topic
> 
> # do work
> git commit
> git commit
> 
> # rebase to make merging to next easier
> git pull
> git rebase master
> 
> # continue work
> git commit
> git commit
> 
> # finally publish your topic branch
> git checkout next
> git merge topic
> git push
> 
> Of course, this is assuming that the topics (next branch) are merged
> into master frequently. Also, it is only worth it if you are working
> on a feature that takes a long time to develop (otherwise the merge
> will be simple enough without rebasing). Does this make sense or am I
> missing something about how git or the new workflow works?
> 
> Thanks,
> --Miguel

IMHO rebasing is great to keep things up to date when developing a topic. But make sure to _NEVER_ rebase a commit you published before. That's going to create a lot of trouble. If you read "man gitworkflows" you will see that this is not a hard rule, e.g. the git developers themselves use a "throw-away" integration branch they call "pu" (proposed updates). At well defined points in the development cycle they clean up its history by rebasing/squashing/splitting and then merge it into "next". After that a new "pu" branch is created.


HTH

Michael