Hi, About squashing : having a single commit makes it easier to - backport for maintenance - revert - review : you don't review some code that might disappear in the next commit Maybe the task should be divided into multiple sub task thus allowing multiple PRs My 2 cents Emmanuel
---------- Emmanuel Hugonnet http://www.ehsavoie.com http://twitter.com/ehsavoie On Wed, Oct 11, 2017 at 4:47 PM, Wade Chandler <wadechand...@apache.org> wrote: > All > > We are using PRs and Git. I have not seen discussions of the git flow we > might use beyond PRs; maybe I missed it. > > My teams and I use PRs, and that is the atomic operation for merging code. > We do not squash because it obscures the path of how the logic came into > being from our point of view. > > I know some like squashing because it some how makes logs "more clean", but > I don't see it this way as a group of related changes may have some > specific info related to subsets of those changes, and thus the PR is the > atomic item merged to master at once, and not the cohesive set of > iindividual commits. > > On rebasing, when working on a branch, I think that is useful. This does > not remove anyone's messages and log detail, but does keep out an > unnecessary log message when bringing down non-conflicting changes. > > I also think it is crucial to keep feature branches updated with master. > One wants the merge pain on the branch, and not when going to master. Then, > one should be able to validate their changes before going to the master > build. > > I have seen some Apache processes which suggest contradictions to the > above: > > https://cwiki.apache.org/confluence/display/JCLOUDS/Git+workflow > > But, in practice over many years, the above has worked well in highly > collaborative, high traffic, and high profile environments; I do not want > to find the issues on master. > > Next, are we able to merge PRs at the Github side? That is more straight > forward in practice to me. The idea being before that is done, one has > tested and validated locally or on branch ahead of time, and reduces > further manual touches of the merge. For instance, Github, like Bitbucket, > won't accidentally force a merge. The conflicts must first be resolved. > > How do you all feel about these issues? > > Thanks > > Wade >
