Great article and I love your drawings (and cupcakes :) )
I've had many arguments before on the concept of rebase from master vs merge into master as a first step, mainly due to the commit timeline continuity. I'm 100% rebase then merge.
I insist that my team (data scientists who are git newbies) rebase from (an immediately re-pulled) master - this way, any conflicts are kept in their own branches and not master, which is kept pure. Only when their branch has been rebased, conflicts resolved, tested and checked for a rebase again do we merge their code into master.
After a few time consuming sessions de-conflicting master they're starting to see the benefit in doing it the way I impose :D
Autosquash is my "one thing I've learned today" - thanks :)
Thank you! Glad you liked the drawings, and honored I could be the daily thing something learned today. I can't ask for much more than that :D (well I suppose I could ask for my laptop battery replacement to be covered by my warranty, but I try to stay realistic haha)
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.