Resolve simple merge conflicts on GitHub(github.com) |
Resolve simple merge conflicts on GitHub(github.com) |
The standard git workflow (and this github feature) seems to promote resolving the conflicts alongside all of the other changes in the merge working copy. This make me nervous, as there's no way to differentiate the new lines that were introduced to resolve merge conflicts from the thousands of lines of (previously reviewed) code from the feature branch.
If you're not careful, completely unrelated working-copy code and behavior can be introduced in a "merge commit" and neither you or any of your reviewers will notice. "Looks good to me."
On the other hand, with your approach you are going to have revisions that won't even build/compile.
If you have automatic builds or/and unit/integration tests, then you'll have failed builds every time you have a merge conflict.
Also, you are kind of 'polluting a well': what if meanwhile someone merges that revision into his/her branch? Or what if you have automatic merges configured?
It can be a bit noisier at first but once you learn to read it, I find it makes resolving conflicts so much easier.
For those of you who haven't used it, try switching it on and/or read https://psung.blogspot.com.au/2011/02/reducing-merge-headach... for more details.
tl;dr it shows
FYI: If anyone is interested in the section about git rerere (reuse recorded resolution), the link at the bottom of that article leads to a 503; a repost can be found here: https://git-scm.com/2010/03/08/rerere.html
But not everyone is working on big projects with tests, and not every merge conflict is actually complex code modification.
Sometimes it's just two commits adding something at the end of the file and there's not real conflict, or maybe you modified the same line twice and forgot to pull before doing your 2nd edit.
Also, I haven't used it extensively since its release, but doesn't the Reviews feature resolve this now?
Yes and no. Build in your CI server that's set up to mirror your prod environment after pushing, but before merging. That's what the whole industry of CI providers and integrations built into and around GitHub and GitLab is for.
I agree I don't like it either.
As far as I know, git bisect does a binary search along the commits; `good` tells it to look at the latter half, `bad` to look at the former.
So suppose you have five commits (1,2,3,4,5), where 1 is the working state, and 3 is a conflict commit. It will start by asking about the middle commit (3), automatically choose `good`, and determine that 3 was the latest working commit (after checking 4, which says `bad`).
----
EDIT: Obviously this is simplified to explain the issue with marking "good" those commits.
That's a terrible idea and would completely break bisect. You should signal "skip" (return code 125) if the commit can not be tested at all.
Depends on just how resource intensive a build is, and how often commits are made to master.
Here at work, we don't do that, but it wouldn't be a complete clusterfuck if we were to.