Hello,
I actually like more commits vs single merge commits as their is a more
verbose history of what was changed.
At work we have been using the -no-ff option on merges so that each
dev's work appears in the history on its own line (for both separate
topic branches and for work done directly on master).
See this link: http://nvie.com/posts/a-successful-git-branching-model
(We don't use the branches described but the shape of the git history
that the --no-ff option provides).
For example: I make 3 changes on my master branch (commits B, C, D)
A
\
B-->C-->D
If I just git pull origin master it will fast forward merge and the
history will look like this:
A-->B-->C-->D
Which sort of hides the fact that I worked on B, C and D in tandem.
But git pull --no-ff origin master creates a merge commit (E) like this:
A ---------- E
\ /
B-->C-->D
So looking back into the past it is easy to see the units of work done
by the different developers.
The way I read the article is that they would end up with:
A--> B'
(B-->C-->D is squashed into B')
A key part of the described process is to use rebase to update the dev's
changes but I'm not sure that this will work properly with our model.
If your changes are only local to your repo then it can work but if you
have a public fork of wicketstuff/core you can't just rebase all the
time as it would break anyone who has cloned your fork.
I mean you have to rebase and then test your branch works or you can
just do the merge commit back into master and then test that your
changes still work. And by using the merge vs rebase you can see the
true start date of the work.
Thanks for posting the initial link Bruno, I find these different work
flows interesting now that we have some commits of our own to compare with.
Regards,
Mike
It is a good article on feature branches. Thanks! I smiled on this one:
"will allow us to pretend that we wrote the tests first…" :)
Attila
2011/4/8 Bruno Borges<[email protected]>
http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html
<http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html
Seems
to be a good idea to squash commits into one single commit, before merging
a
feature branch to master.
Except when there are API changes on Wicket core that needs to be tracked
on
single commits. Michael O'Cleirigh talked about this on a previous
post<http://goo.gl/AaNMX>
.
Cheers,
Bruno Borges
www.brunoborges.com.br
+55 21 76727099
"The glory of great men should always be
measured by the means they have used to
acquire it."
- Francois de La Rochefoucauld
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
