Create follow-up commits, and review all commits collectively, and have all commits survive the merge, leading to a very messy, fractured, red and basically useless git history To rephrase the idea is that given a merge request with 3 commits: PS: Did I mention that this will lead to reverts being close to impossible because behavior changes will be spread across multiple commits because only the very last commit (i.e. I really hope the benefits for Ops and CI are truly awesome to be worth all this. All the while some devs are getting even more frustrated as they are dutifully rewriting the history of their merge requests for pointless effort of trying to maintain a meaningful and useful git history. We will _not_ be able to rely on master being green for every individual commit. We'll see chains of commits in our history that are all broken individually (and without tests, because those are added in a follow-up) next to monster commits from feature branches squashed down into a single commit. Rewrite the git history in your merge branch for which GitLab has absolutely crappy UI support and still doesn't allow you to merge individual commits out of that chainĪll of those options are bad, and we will see _all_ of them in practice in our repositories all the time. Create follow-up commits, and review all commits collectively, and squash them all on merge, leading to one single huge commit that does a ton of things and is hard to revert orģ. Create follow-up commits, and review all commits collectively, and have all commits survive the merge, leading to a very messy, fractured, red and basically useless git history orĢ. In such a scenario, if there are any changes needed than you have three options:ġ. (Which is the by-the-book best-practice thing to do.)
This has consequences for how the review and merge of a chain of multiple atomic commits happens, e.g., two refactoring commits and one commit that does the behavior change. That is to be contrasted with Gerrit's approach of reviewing patches individually. GitLab's Core Review workflow is centered around its concept of reviewing Merge Requests, i.e., the entirety of usually multiple commits.
#Squash merge code
GitLab is substantially lacking compared to Gerrit in its central, most important feature: The Code Review Workflow.
0 kommentar(er)
