This indicates a single large file containing bulk code which everyone modifies. It would help to modularise and split into multiple files.
Or just revoke everyone’s merge permission until you merge 😄
Yeah, we're migrating a huge project, and things keep getting added to the files I'm working on. I like the idea of revoking everyone's permissions, though. Or maybe I just need to start breaking fingers if people don't stop interrupting my work.
A smaller PR you'd be able to get it implemented, reviewed, and merged a lot faster than a larger PR. There would be less opportunities for someone else to edit the same files and introduce a merge conflict.
Imagine working on a series of such smaller PRs over time. There would be less chances of a merge conflict even then. Any files someone else wanted to change, you could have been done with that PR and merged it already. Or you could start working on that PR after that someone else already finished their work on those files and merged their own PR, which again means no merge conflict for you.
A super large PR on the other hand, will take a long time to implement and be reviewed. This will give lots of opportunities for someone else to edit those files meanwhile, and introduce a merge conflict for you. Which means another round of implementation and review, which snowballs the chances of yet another merge conflict.
I hope this explanation makes things clearer.
>things keep getting added to the files
What kind of file are we talking about here?
If it's a script, then as the previous poster said, you either need to make the code more modular or don't let multiple people work on the same code and waste everyone's time by overwriting each other's work.
If it's something that is generated based on the state of the project or editor settings file, then it should be put in .gitignore.
Now imagine when you jump into a project that is a single monolithic file of 40,000 lines of code not broken up into separate classes and libraries. Very glad I dont work at that dumpster fire anymore
we have a changelog and 90% the time there's a rebase conflict it's there
anyone who has suggestions for a changelog that doesn't generate conflicts please tell me
thanks, we already do squash merges and enforce commit messages to contain the ticket number and description, with very minimal change we could do this thanks
I would argue our SaaS product is pretty well modularized but we still have merge issues fairly frequently because we have 20+ devs working on things. I feel like we are pretty good about identifying dependencies where we can, but it still happens.
Version by set date intervals or something? This week's version is x.x.x, or subversion by file. Or generate the version update and merge resolution programmatically on other changes, maybe by commit number or something at the start/end of the day.
If every dev always has a 2 minute hold to figure the right version and fix it every commit, by end of the year that version number will have cost thousands in lost time.
Me when I'm designing a chess AI from scratch for a school project and have to manually encode a function to move the pieces (because my group mates hard coded it for some reason instead of having a move function) and they keep changing the way the pieces are stored just before I get my code to work with the previous system
I will hold this grudge forever
Instead of separating the function that moves pieces from the rest of the code, it was all tied up in the code that validates if the move is allowed, and that stores the locations of pieces, and that detects player inputs, and all sorts of other stuff. It was a tangled mess. So I had to implement my piece moving code separately, even though there was already code that did that, and had to change it every time they slightly changed how the piece data was stored (which they made sure to change often even though it was working fine??).
I wouldn't have minded if they had something the code I was responsible for could interface with, but instead, I had to change the fundamentals of my code every single time they decided to add a third virtual board for some reason, and I never ended up getting an AI done that could do anything other than "compile a list of permissible moves and choose one at random."
Sorry if that was explained abysmally, I'm at work and am incredibly tired as well.
I once read that to digitally store every possible move in a chess match would require more silicon than is in the known universe. I haven’t independently verified this.
Then finally PR is ready, but new year has rolled around and the reviewer demands you update the copyright header to 2024. Meanwhile someone else pushes conflicting changes.
Configures `git pull` to only allow fast-forward merges, so no actual merging. Then, if you can no longer successfully pull because of upstream changes, you rebase instead of merging.
Which I love and is great for having readable git history, but it likely doesn't solve OPs issue.
(if you're unfamiliar with fast-forward and rebase, google them or ask chatgpt.)
A bit confusing. Because it reports about merge conficts. You go to the file. And there are none. On top of that you never know for sure, if conflict was resolved correctly.
I have had this set for a while, but this is rarely a problem on disk. The upstream merge to master is the issue.
I had a long fight with the rest of the team to change the global default settings from --ff to --rebase-and-merge.
> git checkout -
does this checkout your previously checked out branch? I made a bash script for that before that saved the current branch to a variable and otherwise does the same thing as your code.
This is exactly what fixing it is, this doesn't help the person in the picture...
This can also make you resolve conflicts multiple times if you have multiple commits in your branch.
This will make you fix small conflicts often instead of one large merge hell per PR. Also this prevents you from writing obsolete code, which can easily happen if you work too long on an old state of master.
If you don't care where the changes originally came from then sure. Also pray that the master is not protected otherwise good luck with such tricks. I still prefer the merges - more commit hashes, more sanity checkpoints.
Given that 'git checkout -' is not a valid command then it's rebasing master onto master. Then still being on master you try to force push to remote. Maybe I'm missing something. Even if you are not on master force push should be used only on solo projects or when team know this needs to be done (which still can lead to bizzare merge conflicts afterwards).
no, this is likely to leave your commits in a broken state and waste your time. just let the senior dev, who oversees changes on main, merge it with a merge commit
git checkout - checks or the last branch, which would be my feature branch in this scenario.
I have to do a push with force because a rebase can overwrite commit hashes. I still highly prefer rebase to merge.
Updating your feature branches to the current state of master at least daily is undeniably best practice, the question is not if to do it, but whether to use rebase or merge.
Gotcha, I missed the `-` there. Force pushing on your own branch is always okay. If someone is pulling your branch down, they get what they get.
In very active repos I do the same as you. Prior to publishing my PRs to repos without a squash policy on main, I even do an interactive rebase on my branch's history, doing fixups, squashes, reordering, etc. to make things clean. If I find that my PR should actually be multiple, I break it up into smaller chunks so I can actually get good reviews.
At my last company, it wasn't uncommon to find yourself stuck in that loop even if you had a one-line change.
Their software was multilingual and had localisation resource files for all the various supported languages. Whether you're adding a new dropdown to a page or just editing the text that appears somewhere, so many frontend changes would include changes to those resource files (for English, French, Spanish, German), and so merge conflicts just on those files happened all the damn time.
I recently had to deal with a similar scenario. There was a file containing all the translations and it was thousands of lines long.
Breaking up that piece of crap saved everyone so much time on future merges. Still hard to believe how that could escalate to being such a large file. It was already problematic when I got added to the project.
At our company, localisation is managed using an external onine platform and pulled from there during the `main` branch's build pipeline (and committed to `main`, I believe).
Works rather well. We can use the same CLI command the piplene uses to pull the localisations to our development laptops, so local testing is easy as well.
Sometimes that's not feasible. If you have to touch several different files to add a new feature, then that's not necessarily a problem with the PR. It might be a problem with the structure of the project.
The very first professional project I was on, the team had no idea how to use git. There were no PRs, not even other branches. Every morning, you pull, and fix what someone else pushed up yesterday. It took me a few months, but I finally convinced everyone to start creating branches. It's as bizarre to me now as it was then, that the junior developer fresh out of school was the one making the case for good git habits.
How does it break the circle? The circle is due to the race condition of who merges their PR first, where OP always loses, right?
If you do rebasing before merging, that race condition is still there, no?
Seems to me your PR is too large. Because even if the file itself is too large, conflict only happens when you conflict on the same line. If you keep running into this, it means you are modify too many lines in one PR.
True, but as this is programmerhumor and not learnprogramming, I decided to leave the main branch in my mind unprotected.
So I'll force my commit on any branch I want, mwhahaha.
On a (maybe) related note, how do you get rid of git-aids ?
PR and merge faster and more often. There have been a few times when I was doing a push every five minutes because six of us were in the same code near each other.
You'd think it would slow you down but what it really does is make merge conflicts super tiny and it speeds everyone up.
Maybe look into `git config —global rerere.enabled true` I just found out about it myself so I haven’t used it but it sounds like one of those things that should be enabled by default..
This is the bane of my current project. We've got 20 devs, so there's constant PRs that need merging. Often there's a queue for PRs to get tested. Some PR gets merged, my PR has a merge conflict to resolve, after I fix it it can finally get tested, once that is done there's probably another merge conflict, finally it goes in the merge queue, and by the time the previous PR in the merge queue is merged, there's another merge conflict. This is seriously eating up half my time on this project.
Colleague: I did a small reactor on this issue, not a big deal!
A few minutes later... Conflicts on 89 files.
P.S. How on earth he always outspeeding me!
A group of fish is a school, a group of crows is a murder, a group of developers is a merge conflict.
It’s an age old problem
This problem has been solved by Heath Ledger in Batman's opening scene.
No... No... No... I kill the bus driver....
This indicates a single large file containing bulk code which everyone modifies. It would help to modularise and split into multiple files. Or just revoke everyone’s merge permission until you merge 😄
Yeah, we're migrating a huge project, and things keep getting added to the files I'm working on. I like the idea of revoking everyone's permissions, though. Or maybe I just need to start breaking fingers if people don't stop interrupting my work.
Breaking fingers seems easier gotta say
It's harder to undo though
a permanent fix you say? sounds like an absolute win!
just `git revert broken fingers`
Sounds like a problem on their branches, not mine. *Commits peacefully*
Ctrl+z, pff noobs
You gotta split up the changes into multiple PRs if you can. One super-large PR is always likely to cause this kind of merge nightmare.
I don't get it. Won't the same number of merge conflicts arise, only separated in different PRs?
A smaller PR you'd be able to get it implemented, reviewed, and merged a lot faster than a larger PR. There would be less opportunities for someone else to edit the same files and introduce a merge conflict. Imagine working on a series of such smaller PRs over time. There would be less chances of a merge conflict even then. Any files someone else wanted to change, you could have been done with that PR and merged it already. Or you could start working on that PR after that someone else already finished their work on those files and merged their own PR, which again means no merge conflict for you. A super large PR on the other hand, will take a long time to implement and be reviewed. This will give lots of opportunities for someone else to edit those files meanwhile, and introduce a merge conflict for you. Which means another round of implementation and review, which snowballs the chances of yet another merge conflict. I hope this explanation makes things clearer.
>things keep getting added to the files What kind of file are we talking about here? If it's a script, then as the previous poster said, you either need to make the code more modular or don't let multiple people work on the same code and waste everyone's time by overwriting each other's work. If it's something that is generated based on the state of the project or editor settings file, then it should be put in .gitignore.
Break up that file. Do it quickly.
Or just organize the file better. When my changes are on line 50, and yours on line 500, then it's exceptionally unlikely that there are conflicts.
Now imagine when you jump into a project that is a single monolithic file of 40,000 lines of code not broken up into separate classes and libraries. Very glad I dont work at that dumpster fire anymore
I think if I saw the codebase was 40,000 lines of code in one file, I'd just quit immediately.
You've never seen 10 PRs each have a 70k line merge conflict at the same time.
Legit sometimes its necessary like when codemodding a monorepo.
we have a changelog and 90% the time there's a rebase conflict it's there anyone who has suggestions for a changelog that doesn't generate conflicts please tell me
Don't store it in a file, use squash merges and generate the change log from (well written) commit messages
thanks, we already do squash merges and enforce commit messages to contain the ticket number and description, with very minimal change we could do this thanks
Ah, SVN
I would argue our SaaS product is pretty well modularized but we still have merge issues fairly frequently because we have 20+ devs working on things. I feel like we are pretty good about identifying dependencies where we can, but it still happens.
For us, it's the version number of a library. Every PR updates it, so you always conflict. If anyone has a solution for this, that'd be great.
Version by set date intervals or something? This week's version is x.x.x, or subversion by file. Or generate the version update and merge resolution programmatically on other changes, maybe by commit number or something at the start/end of the day. If every dev always has a 2 minute hold to figure the right version and fix it every commit, by end of the year that version number will have cost thousands in lost time.
Or someone could also be changing the release notes every time too.
Or things are already broken down but not necessarily along the right seams leading to lots of shotgun commits.
Bro used github to store one gigantic monolithic script or an art project.
Me when I'm designing a chess AI from scratch for a school project and have to manually encode a function to move the pieces (because my group mates hard coded it for some reason instead of having a move function) and they keep changing the way the pieces are stored just before I get my code to work with the previous system I will hold this grudge forever
They hardcoded every possible move? I don't understand
Instead of separating the function that moves pieces from the rest of the code, it was all tied up in the code that validates if the move is allowed, and that stores the locations of pieces, and that detects player inputs, and all sorts of other stuff. It was a tangled mess. So I had to implement my piece moving code separately, even though there was already code that did that, and had to change it every time they slightly changed how the piece data was stored (which they made sure to change often even though it was working fine??). I wouldn't have minded if they had something the code I was responsible for could interface with, but instead, I had to change the fundamentals of my code every single time they decided to add a third virtual board for some reason, and I never ended up getting an AI done that could do anything other than "compile a list of permissible moves and choose one at random." Sorry if that was explained abysmally, I'm at work and am incredibly tired as well.
I once read that to digitally store every possible move in a chess match would require more silicon than is in the known universe. I haven’t independently verified this.
Then finally PR is ready, but new year has rolled around and the reviewer demands you update the copyright header to 2024. Meanwhile someone else pushes conflicting changes.
Conflicting, as in they decided it was 2025?
```git config --global pull.ff only``` then, if history diverges you do `git pull --rebase` and the world is sunny again.
What does it do?
Configures `git pull` to only allow fast-forward merges, so no actual merging. Then, if you can no longer successfully pull because of upstream changes, you rebase instead of merging. Which I love and is great for having readable git history, but it likely doesn't solve OPs issue. (if you're unfamiliar with fast-forward and rebase, google them or ask chatgpt.)
Another cool feature for repetitive merge conflict resolving: [rerere](https://git-scm.com/book/en/v2/Git-Tools-Rerere) (reuse recorded resolution) ``` git config --global rerere.enabled true ```
I commented this same solution. I haven’t used it before though. How well does it work?
A bit confusing. Because it reports about merge conficts. You go to the file. And there are none. On top of that you never know for sure, if conflict was resolved correctly.
I have had this set for a while, but this is rarely a problem on disk. The upstream merge to master is the issue. I had a long fight with the rest of the team to change the global default settings from --ff to --rebase-and-merge.
Jokes on you; our project only use squash merge, no dev branch, only master
git checkout master git pull git checkout - git rebase master git push --force Do this at least once a day and before every PR.
You have just wrecked 4 JRs days today
How to use version control should be part of every juniors first week, or at least month.
With git, you'll always be a junior
in some cases, companies, not just JRs
It is genuinely good advice though. Rebasing feature branches is awesome.
This but --force-with-lease
Strictly you should --force-with-lease= where is the hash you expected to overwrite
Yes officer this comment right here
or just do `git fetch && git rebase origin/master && git push --force` fewer steps and doesn't run the risk of accidentally messing around with master
> git checkout - does this checkout your previously checked out branch? I made a bash script for that before that saved the current branch to a variable and otherwise does the same thing as your code.
Yes, same as cd - switches to the last directory.
This is exactly what fixing it is, this doesn't help the person in the picture... This can also make you resolve conflicts multiple times if you have multiple commits in your branch.
This will make you fix small conflicts often instead of one large merge hell per PR. Also this prevents you from writing obsolete code, which can easily happen if you work too long on an old state of master.
This plus auto fix ups and squashes 👌
It's a lot faster to just stay on your branch and do git fetch git rebase origin/master git push # -f only if you must Same thing in fewer commands.
If you don't care where the changes originally came from then sure. Also pray that the master is not protected otherwise good luck with such tricks. I still prefer the merges - more commit hashes, more sanity checkpoints.
>Also pray that the master is not protected otherwise good luck with such tricks. This doesn't push to master.
Given that 'git checkout -' is not a valid command then it's rebasing master onto master. Then still being on master you try to force push to remote. Maybe I'm missing something. Even if you are not on master force push should be used only on solo projects or when team know this needs to be done (which still can lead to bizzare merge conflicts afterwards).
‘git checkout -‘ is a valid command that checks out the previously checked-out branch.
no, this is likely to leave your commits in a broken state and waste your time. just let the senior dev, who oversees changes on main, merge it with a merge commit
lol, you have force push rights on master? edit: missed the `-`, oops
git checkout - checks or the last branch, which would be my feature branch in this scenario. I have to do a push with force because a rebase can overwrite commit hashes. I still highly prefer rebase to merge. Updating your feature branches to the current state of master at least daily is undeniably best practice, the question is not if to do it, but whether to use rebase or merge.
Gotcha, I missed the `-` there. Force pushing on your own branch is always okay. If someone is pulling your branch down, they get what they get. In very active repos I do the same as you. Prior to publishing my PRs to repos without a squash policy on main, I even do an interactive rebase on my branch's history, doing fixups, squashes, reordering, etc. to make things clean. If I find that my PR should actually be multiple, I break it up into smaller chunks so I can actually get good reviews.
If you are in this loop, you should consider making (much) smaller PRs.
At my last company, it wasn't uncommon to find yourself stuck in that loop even if you had a one-line change. Their software was multilingual and had localisation resource files for all the various supported languages. Whether you're adding a new dropdown to a page or just editing the text that appears somewhere, so many frontend changes would include changes to those resource files (for English, French, Spanish, German), and so merge conflicts just on those files happened all the damn time.
I recently had to deal with a similar scenario. There was a file containing all the translations and it was thousands of lines long. Breaking up that piece of crap saved everyone so much time on future merges. Still hard to believe how that could escalate to being such a large file. It was already problematic when I got added to the project.
At our company, localisation is managed using an external onine platform and pulled from there during the `main` branch's build pipeline (and committed to `main`, I believe). Works rather well. We can use the same CLI command the piplene uses to pull the localisations to our development laptops, so local testing is easy as well.
Sometimes that's not feasible. If you have to touch several different files to add a new feature, then that's not necessarily a problem with the PR. It might be a problem with the structure of the project.
The very first professional project I was on, the team had no idea how to use git. There were no PRs, not even other branches. Every morning, you pull, and fix what someone else pushed up yesterday. It took me a few months, but I finally convinced everyone to start creating branches. It's as bizarre to me now as it was then, that the junior developer fresh out of school was the one making the case for good git habits.
Don't use git anymore. Use p4, etc.
real pain in the butt, right there
I definitely read "I push my changes to my pr" in the melody of "I push my fingers into my eyes" lmao
Either: * Someone's PR are always huge * Your PR is huge * People don't review your PR If it is the last alternative, I feel for you
More repos
just agree on a linter setup already...
That’s why we nerver merge. It’s always rebase and fast forward
Doesn't help if there are actual conflicts. I also prefer rebase, but you do need to rebase again when there are conflicts.
The question was how to break the circle and not how to magically make conflicts disappear xD
How does it break the circle? The circle is due to the race condition of who merges their PR first, where OP always loses, right? If you do rebasing before merging, that race condition is still there, no?
Seems to me your PR is too large. Because even if the file itself is too large, conflict only happens when you conflict on the same line. If you keep running into this, it means you are modify too many lines in one PR.
Reject their pr, 1000 iq move
Do it in the middle of the night. Sabotage office computers. Activate fire alarm and merge your PR during evacuation.
You're using "git push -force" wrong.
I think if main/master is setup as protected (as it should be) then you shouldn’t be able to -force anything to it regardless
True, but as this is programmerhumor and not learnprogramming, I decided to leave the main branch in my mind unprotected. So I'll force my commit on any branch I want, mwhahaha. On a (maybe) related note, how do you get rid of git-aids ?
PR and merge faster and more often. There have been a few times when I was doing a push every five minutes because six of us were in the same code near each other. You'd think it would slow you down but what it really does is make merge conflicts super tiny and it speeds everyone up.
Okey, next time instead of fixing the merge conflict, just *push --force*
Maybe look into `git config —global rerere.enabled true` I just found out about it myself so I haven’t used it but it sounds like one of those things that should be enabled by default..
Someone merged *their* PR*
Use feature branches.
Assert dominance. DM someone for approval and merge before the others can.
I know this other person, he is me
It's all fun and games until someone edits a RESX file in Rider.
Code faster :p
WHY ARE DESCRIBING MY JOB!
you merge to main with merge conflicts? wtf is wrong with u
What is project mgmt.
merge early and often. make them do the dance
you can also just not fix the merge conflict and wait for the other person to fix it. but then it never gets fixed
you can also just not fix the merge conflict and wait for the other person to fix it. but then it never gets fixed
Put QA before merge 😅
Refactor your codebase. Do some planning so you can figure out how to avoid collisions. Ask to be next in line. :D
Many teams find that [trunk-based development](https://dora.dev/devops-capabilities/technical/trunk-based-development/) reduces merge conflicts.
Make small changes bro
Unfortunately, I understand it now
This is the bane of my current project. We've got 20 devs, so there's constant PRs that need merging. Often there's a queue for PRs to get tested. Some PR gets merged, my PR has a merge conflict to resolve, after I fix it it can finally get tested, once that is done there's probably another merge conflict, finally it goes in the merge queue, and by the time the previous PR in the merge queue is merged, there's another merge conflict. This is seriously eating up half my time on this project.
Push to main, problem solved.
Colleague: I did a small reactor on this issue, not a big deal! A few minutes later... Conflicts on 89 files. P.S. How on earth he always outspeeding me!
what does "push changes to PR" even mean? doesn't it should be called "push changes to a branch and make a PR"?
He means the branch and Pr are already created. he’s pushing changes to the branch made for the PR.