3 ms·
Don't use push --force, use push --force-with-lease. Then you avoid accidentally undoing unexpected new commits on the remote.
by 0x0 8y ago
Don't use push --force, use push --force-with-lease. Then you avoid accidentally undoing unexpected new commits on the remote.
- stygiansonic 8y agoMore information on this option, as well as caveats: https://developer.atlassian.com/blog/2015/04/force-with-lease/ https://developer.atlassian.com/blog/2015/04/force-with-leas...
- fcarraldo 8y agoBetter yet, don’t use push —force at all unless you specifically intend to undo commits on the remote. Resolve conflicts locally and never force push to a shared branch.
- jeremyjh 8y agoThis forces you to merge master into your shared topic branches instead of rebasing them on master, which makes the history harder to follow.
- u801e 8y agoYou can always run something like: git diff origin/your-branch..your-branch to check whether you have made any unintentional changes to the code. For the commits themselves, you can do something like: git log origin/master..origin/your-branch and git log origin/master..your-branch to see if the commits differ. You can use the -p switch on the git log commands to see if the diffs have changed. If you do this before pushing up to the remote, then it's much easier to see what you're going to change before you run git push -f.
- pjc50 8y agoCould you explain this and why it requires --force? (One of the features of git that I struggle to understand isn't a deal-killer for its adoption is the lack of repo access control; if you want this you have to implement it manually through PRs)
- bostonvaulter2 8y agoOh, that's pretty neat! Didn't realize that was an option with git!
- stormbrew 8y agoI really wish they'd switch these around so --force used the lease logic by default and you had to turn it off. I don't think backward compatibility is anywhere near worth the problems this default causes. :/