git workflow draft
Stephen Kelly
steveire at gmail.com
Wed Feb 16 21:10:52 GMT 2011
Aaron J. Seigo wrote:
> Open questions / topics for further discovery:
>
> * documenting best practices for keeping a topic branch in sync with
> master, keeping in mind that later a merge from the topic branch to master
> needs to be done and the git history sould be kept as clean as possible
As one of the people asked to describe my idea of the workflow (which should
focus on rebasing, not merging) I put write up here:
http://community.kde.org/20110213_GitWorkflowAgenda/StevesIdea
http://thread.gmane.org/gmane.comp.kde.scm-interest/2007
The emphasis is on creating a 'nice' stream of commits which it is possible
to review (if applicable) and which apply against the target branch. This
way a reviewer (or archeologist looking for the source ofg a bug) doesn't
have to analyse commits in the branch which are workarounds for bugs in
master, find the merge from master and the removal of the workaround,
analyse the master branch in the same timeframe to see what needed to be
merged in etc etc.
The topic branch is an addition to the master branch. It should be relevant
against the current master and 'clean' and nice. Happy and good. No useless
merges. There should be no recommendation in documentation to 'merge a topic
branch into master'. The recommendation should be to rebase instead. This is
my recommendation. There has been some discussion on the scm interest list,
but I wouldn't call it concensus at this point.
Stefan Majewsky wrote:
> As far as I'm concerned, the only problem with such branch moves is
> the potentially epic number of commit notification mails. If so, the
> email hook should check if the push generates a new branch, and send
> only one mail then, like "100 commits have been pushed into the new
> branch foobar; see >>here<< for a complete log vs. master and >>here<<
> for the diff".
The idea in the irc meeting was to not enable notifications and other such
hooks on the topic branches, but only on release branches.
That means there's only notification when master gets updated to include the
branch. That means you get a 100 commits becoming relevant within 10 seconds
instead of over the course of the 3 months or whatever that they were
written.
I fail to see why that would be a big deal. Reading the kde commits mailing
list is actually easier because I can skip a large amount of commits that
I'm not interested in at once.
All the best,
Steve.
More information about the kde-core-devel
mailing list