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
