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 _______________________________________________ cmake-developers mailing list [email protected] http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
