4 ms·
Rebase rewrites history to an extent. What I do (and this is also the advice in Pro Git for what thats worth) is use rebase when I'm working in local because it
by mirawelner 2y ago
Rebase rewrites history to an extent. What I do (and this is also the advice in Pro Git for what thats worth) is use rebase when I'm working in local because its cleaner, but the moment anything ends up on GitHub, I use merge because I don't want to rewrite history that other people are aware of.
I am fine rewriting my own history on local because I know what I did, but not when its on GitHub because other people don't neccecarily know what I did.
- JohnMakin 2y agoI think this nails the difference in my workflow against people that tend to say it is difficult. In infrastructure commit history, which is often tied to CI CD processes that reach far outside of a repository and org - commit history is sacred. I need the absolute order of when things got merged in, because it provides a clean timeline to backtrack any issues. maybe I’m doing it wrong but every mature sysyem I’ve worked in basically operates this way. I suspect you run into more merge conflicts but I’m by no means a git expert.
- AlotOfReading 2y agoThe best I've found is the kernel development process: use both intelligently and give your branches a clean commit history before they're sent for review. https://docs.kernel.org/maintainer/rebasing-and-merging.html https://docs.kernel.org/maintainer/rebasing-and-merging.html