The problem with (B) is it makes a blanket decision to squash all commits into one commit. While this is often appropriate for a number of feature branches, separate logically compounding commits is also often appropriate for merged feature branches.
I teach my teams to rebase their feature branches and to use fast-forward merges so we can create linear histories in our destination branches.
We aren't anal about it, because sometimes it is just easiest to accept merge commits, but sometimes developers don't have the patience or experience to pull off clean histories while they're still learning, so a little bit of social pressure always helps to accelerate adoption and learning of best practices.
Checking out the prevailing habits in Linus's Linux repo or Junio's Git repo is always insightful.
Cheers,
Derek
Hi,
I also have a slight preference towards (B), but I don’t feel strongly about it. Let’s just decide on one strategy, we can always review this later.
Hi,
we are mostly using (B) in the MVC specification which works great. However, if the individual commits are well structure and the pull request is nontrivial, I also use (C) from time to time.
Christian
_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jaxrs-dev
_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jaxrs-dev