Simple solution: disallow rewriting history on your server (aka. git push --force MUST not be allowed, ever). This will prevent people from pushing rebased history.
It's considered good behavior to rebase before you create your pull request. Lots of OSS projects will insist on this. You decide this before you push local changes. And in the case of OSS projects it is up to them whether they will pull your changes.
Avoid doing squash merges unless you can afford to get away with them. That means you don't want to have multiple long lived branches having to deal with solving conflicts on insanely huge diffs resulting from somebody squashing huge amounts of changes. With a normal git merge, you solve conflicts commit by commit, this is great because the scope of these is usually fairly limited meaning conflicts are typically straightforward to deal with.
If you squash two weeks of work into one commit, it's like saying "we don't give a shit about versioning here; enjoy this huge diff without any context whatsoever". Don't do that. This will cause lots of work in long lived branches when they need to sync up. So, squash if you absolutely must but be mindful of the havoc you create upstream with your huge diffs. I tend to not use them. Not worth the problems they cause.
Related to that, keep any branches you care about up to speed with what they eventually have to be merged back to. Bi-directional merges just work in git and long lived branches are why you need them. Don't be afraid to use them. Knowing things will merge cleanly because you already merged the upstream changes and solved all the conflicts, is a good thing.
You might argue that feature branches are bad but the reality is that pull requests stay open for hours, days, or in some cases weeks while people collaborate on them. Shit happens in between when you create a PR and when you merge one. The bigger and more complicated your project, the more this will happen. Git was designed to facilitate this, not obstruct it. Use it properly.
Hey, Jilles, thank you for sharing your opinion with the community! Kolosek team mostly works around feature branches and pull requests with weekly sprints. Our goal is to achieve the best results in a timely manner by keeping the features small enough to be completed on time and easy to bug fix in case that is needed.
Simple solution: disallow rewriting history on your server (aka. git push --force MUST not be allowed, ever). This will prevent people from pushing rebased history.
We use strategy where force push is disallowed for main branches (e.g. master) but allowed for individual developer branches. This way developers can commit freely and the history can be cleaned up before the changes are taken to master (while also being able to push the intermediate work to remote).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Simple solution: disallow rewriting history on your server (aka. git push --force MUST not be allowed, ever). This will prevent people from pushing rebased history.
It's considered good behavior to rebase before you create your pull request. Lots of OSS projects will insist on this. You decide this before you push local changes. And in the case of OSS projects it is up to them whether they will pull your changes.
Avoid doing squash merges unless you can afford to get away with them. That means you don't want to have multiple long lived branches having to deal with solving conflicts on insanely huge diffs resulting from somebody squashing huge amounts of changes. With a normal git merge, you solve conflicts commit by commit, this is great because the scope of these is usually fairly limited meaning conflicts are typically straightforward to deal with.
If you squash two weeks of work into one commit, it's like saying "we don't give a shit about versioning here; enjoy this huge diff without any context whatsoever". Don't do that. This will cause lots of work in long lived branches when they need to sync up. So, squash if you absolutely must but be mindful of the havoc you create upstream with your huge diffs. I tend to not use them. Not worth the problems they cause.
Related to that, keep any branches you care about up to speed with what they eventually have to be merged back to. Bi-directional merges just work in git and long lived branches are why you need them. Don't be afraid to use them. Knowing things will merge cleanly because you already merged the upstream changes and solved all the conflicts, is a good thing.
You might argue that feature branches are bad but the reality is that pull requests stay open for hours, days, or in some cases weeks while people collaborate on them. Shit happens in between when you create a PR and when you merge one. The bigger and more complicated your project, the more this will happen. Git was designed to facilitate this, not obstruct it. Use it properly.
😱
Hey, Jilles, thank you for sharing your opinion with the community! Kolosek team mostly works around feature branches and pull requests with weekly sprints. Our goal is to achieve the best results in a timely manner by keeping the features small enough to be completed on time and easy to bug fix in case that is needed.
We use strategy where force push is disallowed for main branches (e.g. master) but allowed for individual developer branches. This way developers can commit freely and the history can be cleaned up before the changes are taken to master (while also being able to push the intermediate work to remote).