I feel like I often would prefer to get the merge conflict. So many times my coworkers will somehow mess up the code I committed when resolving the conflict.
This way I can wreck their shit instead! Enjoy debugging this one Tim, you obtuse bastard!
Dear god yes. Please just let me deal with the conflict before the kids make it worse.
Inschools project, I once used the flag ours.
git push --force
Problem?
Not for you!*
*Since you’ll be unemployed
Dam, hate to work where you work. People do it here all the time and never get fired. Fucking drove me to save backups of my changes and literally would have to push my changes again afterwards. Good thing I finally found a place to work where this shit isn’t practiced.
I’m usually the one managing merge conflicts, and honestly that’s how I’d prefer it. I’ve had so many instances where my code was bungled because someone didn’t take the time to actually check the conflicts.
Two new files wouldn’t create a merge conflict though (unless they have the same name)?
Git won’t let the second person push if their commit history doesn’t line up with the origin branch.
It should be trivial to do a
git pull --rebase
to move your new commit after the upstream version, but as far as I can tell, no one on my current project remembers this (or perhaps they’re using gui tools or something). Our log is full of “merge origin/main onto main”.God I fucking hate merge commits.
If you use vscode, try out the merge editor. It’s a lot clearer to me when the merge diffs are huge.
I would also say to check out the latest branch for each file you commit. If your file is file.tsx checkout file.tsx in the main branch to make sure you know what you’re changing.
Thanks! I’ve been tinkering with VS Code (migrating from IntelliJ) recently - I’ve found that they’re at pretty-much feature parity. VS Code makes it much harder to attach a debugger (IME, though I might just not grok it yet), but is more customizable and a lot less of a memory-hog. I think I’m comfortable adopting it as my daily driver. And, as you say, any IDE’s Merge Editor is usually clearer than the equivalent direct from the CLI!
However, I wasn’t complaining about Merge Conflicts - I do dislike them, but they’re a necessary evil (well, until AI can resolve all conflicts itself :P ). Rather, I was complaining about Merge Commits. See my comment here for more context.
I’m guessing you don’t mean commits that actually bring updates from a different branch in? I’m responsible for a bunch of commits that catch my feature branch up to main and a couple that bring my branches into main.
If we were working on the same project, what would you want to see for those? This is hosted on a private gh repo, but it’s a small shop and we were working on a tight deadline for an MVP release and were not using PRs for the stuff I was working on.
The boss (co-owner of the business) is the Sr dev on the project and until recently was the only sr dev in the whole shop. I actually don’t think he has experience with using git in a team context.
One of my other tasks is working on internal docs (which didn’t exist before I joined the team) that would include git best practices for branching strategies and commit messages, so I’m interested in what folks who have more experience than I do would like to see as I try to nudge the team practices.
I’m guessing you don’t mean commits that actually bring updates from a different branch in?
No, fast-forward merges only
merge commits that catch my feature branches up to main
You’d be squashing those when you merge back down into main anyway, no?
You’d hope so - and if one does, I have no concerns about whatever one chooses to do in the privacy of their own branch - but some people insist on directly merging to
main
(preserving two parallel histories), rather than squashing their change into a single commit. Savages ;)
I’m guessing you don’t mean commits that actually bring updates from a different branch in?
Yep, in part, I do. Say I’m working on
feature
which branched off frommain
. Time’s gone by, and there have been commits on bothfeature
andmain
. I want to integrate (not I am very carefully not using the wordmerge
!) the commits that exist onmain
into myfeature
branch so that I can use them. You can make a merge commit to do so, but there’s no point in doing so - agit pull --rebase
will have the same effect (“My local branch contains both the changes from the upstream, then the changes that I myself have made ‘on top of’ them”) without requiring a merge commit.But really, what one chooses to do in the privacy of one’s own branch is no concern of mine. I can advise and opine, but it doesn’t really affect me. What does affect me is when people insist on merging into
main
. That really irritates me, because it results in horrible tangled non-linear history like this. Ideally, the history ofmain
should be a linear history of changes which each follow on from one another, and a commit and a change are in 1:1 correspondance:- the question “which commit is the parent of this one?” should have one answer, not potentially-multiple.
- there is no value in seeing the development history of the change (all the random “bugfix”, “maybe this will work lol”, “correct typos” commits) in the history of
main
. They are maybe useful in the PR, but the change as seen inmain
should only contain the finished polished-up result.
GitHub’s confusingly named “Squash And Merge” (it’s a “merge” in the
git merge
sense, but it doesn’t create a Merge Commit! “Squash and commit” or “Squash and push” would be more accurate) results, I think, in the outcome - a single commit on theHEAD
of the target branch containing the result of the change. And if that happens, then I don’t care if you’ve been pulling in changes frommain
tofeature
via Merge commits or (correctly IMO) viagit pull --rebase
- because, whatever you’ve done, your development history will be (correctly) invisible from the commit onmain
.(I say “I think” there because I’ve only recently started using GitHub in a professional capacity. For the decade prior to this I worked at a Big Tech company which had its own in-house Code Review tools which - probably not by coincidence - aligned a lot more closely with how I think about how Git history should be structured)
While we’re at it, I like to use
--autostash
in addition.i have autostash set up as part of global config
Uuh, thanks for that hint! I’ve been using git over CLI for over 10 years now and never came across that flag.
I think the idea is both are adding new files and also making changes to various files but his commits to the non-new files caused the conflict. Also, if both new files affect the same deliverable (like a DLL) then that could create a conflict in some cases (though I think that all depends on the build system).
Sometimes git just hates you
I always rush to finish first when I learn someone else is working on the same files. Ain’t nobody got time to figure out how to merge your shit with my beautiful, perfect, new feature.
Committing code like an a duel in an old western movie.
Not if you upload different files lol
Exactly. I was going to share this with colleagues but it’s wrong
Pulling changes should be trivial after you’ve done it a few times.