3 ms·
Two rules of rebasing that I follow strictly: 1. Never rebase a shared branch 2. Never break rule 1
by rednafi 2y ago
Two rules of rebasing that I follow strictly:
1. Never rebase a shared branch
2. Never break rule 1
- rurban 2y agoAlways rebase and push --force. Devs who cannot pull --rebase or reset --hard to latest should quit their jobs, and stop whining.
- osigurdson 2y agoTrue Scotsman. Does it or does it not increase cognitive load?
- rurban 2y agoNo cognitive load. Just just magit and a set of git aliases
- osigurdson 2y agoWhat is your definition of a shared branch? Is it shared the moment you push it (assuming a github like workflow). Is it shared if you check it out on two separate machines just for yourself?
- rednafi 2y agoMy definition of a shared branch is the one where only one person is working. It can be your local branch and the same one after you push it to remote. It's still not shared in the sense that only 1 person is supposed to work on that branch. In this case, you can easily perform rebase and run `git push origin HEAD --force-with-lease` without causing any headache for anyone else.
- osigurdson 2y agoSay you have a checkout on Linux and one on Windows and need to do some bespoke development work on each. I personally would just do git push / pull to avoid any potential for lost work. Maybe after the work is done, I would refactor the commits and rebase them before pushing to the authoritative server (e.g. github, azure dev ops, etc.).
- account42 2y ago> I personally would just do git push / pull So would I, but I have also have pull set to rebase.