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

Miguel A. Figueroa-Villanueva miguelf at ieee.org
Sat Jun 5 11:46:02 EDT 2010


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



More information about the cmake-developers mailing list