4 ms·

Some people however see using features like amend, squash, and force push as potentially destructive actions in the hands of a novice, which can lead to loss of

by wdfx 2y ago

Some people however see using features like amend, squash, and force push as potentially destructive actions in the hands of a novice, which can lead to loss of not only the author's work but also other people's. Using merge almost never results in any sort of loss and is easier to work with for those who still don't quite understand the risks.

pjc50 2y ago
"Force push" is something that should be restricted to a very few senior people anyway; once you do that, you can't rewrite shared history any more and a lot of the worries go away.
- vundercind 2y ago
  This is a great way to get me to clutter the shared repo with throwaway branches that I’ll later replace (deleting the old one—if you let me).
  - pjc50 2y ago
    This is fine! This is a normal part of several popular git workflows. After all, a branch is just a pointer to a commit. (Our workplace has a mix of github flow, which is one branch per PR: https://docs.github.com/en/get-started/using-github/github-flow https://docs.github.com/en/get-started/using-github/github-f... ; Atlassian Gitflow https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow https://www.atlassian.com/git/tutorials/comparing-workflows/... ; and the completely different Gerrit flow which ends up very rebase and amend heavy: https://gerrit-review.googlesource.com/Documentation/intro-gerrit-walkthrough.html https://gerrit-review.googlesource.com/Documentation/intro-g... )
    - vundercind 2y ago
      I thought you meant blocking all force-push. Shared branches should absolutely be protected (with an “in case of emergency, break glass” option)
skywal_l 2y ago
You are associating the use of `amend` and `fixup` with force push. It's perfectly fine to rework your commit history locally and even force push to your own local branch. It should never be possible (except to people administrating your repo) to force-push to any public or even shared branch. Nobody should be able to force-push to master (or any public branch) except on specific occasion. In that case, someone is authorized, performs their specific action and then get de-authorized. This is pretty basic.
Izkata 2y ago
Meanwhile the biggest issues I actually see in novices are when their IDE presents them with buttons that don't coincide with a single version control action (can you guess what "sync repo" will do?) and using those puts their checkout into a weird state. Usually when using the commands directly they're more careful, but have the mindset "an IDE wouldn't intentionally break something so this button must be safe to click".
- Groxx 2y ago
  Custom terms on top of git is a bafflingly bad decision. IDEs in particular should expose the details all the time, and show the command that's being run, so it can teach people passively instead of misleading them and leaving them stuck when it breaks.

by wdfx 2y ago

pjc50 2y ago

"Force push" is something that should be restricted to a very few senior people anyway; once you do that, you can't rewrite shared history any more and a lot of the worries go away.

vundercind 2y ago
This is a great way to get me to clutter the shared repo with throwaway branches that I’ll later replace (deleting the old one—if you let me).
- pjc50 2y ago
  This is fine! This is a normal part of several popular git workflows. After all, a branch is just a pointer to a commit. (Our workplace has a mix of github flow, which is one branch per PR: https://docs.github.com/en/get-started/using-github/github-flow https://docs.github.com/en/get-started/using-github/github-f... ; Atlassian Gitflow https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow https://www.atlassian.com/git/tutorials/comparing-workflows/... ; and the completely different Gerrit flow which ends up very rebase and amend heavy: https://gerrit-review.googlesource.com/Documentation/intro-gerrit-walkthrough.html https://gerrit-review.googlesource.com/Documentation/intro-g... )
  - vundercind 2y ago
    I thought you meant blocking all force-push. Shared branches should absolutely be protected (with an “in case of emergency, break glass” option)

skywal_l 2y ago

You are associating the use of `amend` and `fixup` with force push. It's perfectly fine to rework your commit history locally and even force push to your own local branch. It should never be possible (except to people administrating your repo) to force-push to any public or even shared branch. Nobody should be able to force-push to master (or any public branch) except on specific occasion. In that case, someone is authorized, performs their specific action and then get de-authorized. This is pretty basic.

Izkata 2y ago

Meanwhile the biggest issues I actually see in novices are when their IDE presents them with buttons that don't coincide with a single version control action (can you guess what "sync repo" will do?) and using those puts their checkout into a weird state. Usually when using the commands directly they're more careful, but have the mindset "an IDE wouldn't intentionally break something so this button must be safe to click".

Groxx 2y ago
Custom terms on top of git is a bafflingly bad decision. IDEs in particular should expose the details all the time, and show the command that's being run, so it can teach people passively instead of misleading them and leaving them stuck when it breaks.