←back to thread

Oh Shit, Git?

(ohshitgit.com)
464 points Anon84 | 3 comments | | HN request time: 0.001s | source
Show context
javier_e06 ◴[] No.42730659[source]
Lately I've been asked to avoid merge-commits. They pollute the logs? If my push is blocked I am too far behind I create a new temp branch of master and do a "merge --squash" to it and then a "reset --hard" from temp branch back to my original branch. Heck sometimes I rather keep my changes in patches to void does darn merge CONFLICTS...specially when rebasing.
replies(4): >>42730740 #>>42730864 #>>42731305 #>>42732035 #
1. nuancebydefault ◴[] No.42731305[source]
The thing is if you merge immediately into master and have conflicts, you solve the conflict and only then you can merge. But then the conflict resolution sits at the merge point with a weird default commit message and is hard to decipher.

A nicer way is merge master into your branch, with the rebase option (you can set that option as the default). This will put your changes on top of the master changes that happened during populating your own branch. There you solve any conflicts and those usually immediately show you what happened in the meantime, making it easier to do so. The latest greatest now sits in your branch.

Then as a plus, you can retest that merge and if necessary, fix the merge.

Optionally you can do a pull request for reviewing. The diff the reviewers see is conflict-less and makes sense, has only your changes.

Then simply merge to master, which should be trivial if you don't wait for long.

replies(1): >>42732698 #
2. Nullabillity ◴[] No.42732698[source]
Merge main into your branch, then merge --no-ff your branch into main. No need to rebase or squash anything.
replies(1): >>42732993 #
3. Izkata ◴[] No.42732993[source]
> Merge main into your branch

The same problem GP was trying to avoid is created here, the merge conflict resolution being on the merge commit.