@jimboxx7
Rebase private commits, merge public commits. Never change public history, do whatever you want with private history. By public, I mean 2+ developers depend on it.
@andrewhaeffner6114
“We rebased you out of the chat.” what a way to end a video. pure gold. Appreciate this video, Prime. Things like this always add to my limited perspective
@ThePrimeagen
Devhour deez podcast Hey, give this a like if you like podcast style
@typhoon2099
I've just started using fixups and my commit history looks so much better. I've also been a fan of rebasing on master/main before opening a PR so that I'm up to date with the repo. Squash merges and fast forwards are great too, one commit per feature makes things pretty readable Imo.
@funcmethod
6:12 "You can't come back from a bad rebase because you've changed history." I think this is the key takeaway. I've often thought this about rebasing—I think I'm persuaded to switch to merging. Great arguments.
@Imaltont
Rebasing and Merging is two different tools for different situations though. Refusing either seems wrong. Rebasing keeps things clean before you merge something into the base. You get a clean history that is nice to work with and reason about. Rebase for your local/private branches to keep up to date with exactly what things look like upstream and to clean up messy commits. Merge to combine branches. Torvald's/Linux' policy is not to rebase anything public, and not to rebase anything from your base, only your own unmerged changes. Rebasing and changing recent history/history of your own changes seems to be common in Linux based on the contribution guidelines to clean up commits and commit messages. Personally I use the history a lot when looking for recent errors or obscure errors in large code bases where it's hard to know where to start bisecting, searching for specific files/patterns, authors, keywords etc. Even just to understand how some things evolved in the files I'm currently working in, to see why or how it ended up in it's current state and not repeat previous errors by just doing the simplest fix possible that was maybe patched out at an earlier point for good reasons. Also use rebasing to clean up my work before merging so there are no broken commits, and if several issues are combined into one branch I'll reorder the changes so they fit in one commit each with the issue number. When I look around at the tools some people use with git I can understand why they never bother with any of the things it can do though, and that is why I pray to the tpope shrine every morning before work.
@leviackerman7222
This is actually a very informative podcast and this style is epicc
@akashdeepnandi
I used only git merge until one day I just checked my git tree, it made me cry. From that point on in my life, I knew tough choices have to be made. So git rebase it is.
@gagegolish9306
My personal approach is to rebase in my own branch when I am making changes just to keep my commits at the top of the ref log, and when it gets merged into the main branch my commits are all in a nice group. In my opinion history doesn't matter until it's merged into the main branch. When there are multiple developers working on a branch I avoid rebasing though to prevent accidentally wiping out someone else's commits.
@cheebadigga4092
Rebase your feature branch, merge into the target branch. This way you have merge commits where they need to be and you can rebase freely in your feature branch. The merges Theo is describing here are literally just rebases + his merge commit at the end, mixing up the target branch history, at least in my mind. On the other hand, I should say that I never had the workflow he is describing. We only work on a specific branch 1 developer at a time, maybe this is why rebasing is the way to go for me.
@f282072
This was stressful to watch, almost wanted to jump in with the opinions sleeves rolled up. Beautiful.
@paulbcote
Total greenhorn here. Gotta say that there is something about the banter in this that is very effective expression of "ways to think" about the formerly arcane concepts: rebase and merge. Thanks. Subscribed.
@DebugChug.
How often will you be doing these?? This was great!
@MrDgf97
Personally I prefer rebasing. However, the company I work at uses Theo’s approach in certain products by stating the same reasoning, which makes complete sense for the context of those products and how the workflow is enforced
@mahklo
I generally don't like watching interview videos but this was entirely entertaining 😂 Great job. You guys have great chemistry and both make some valid points without overtalking each other. 👏 Also enjoyed the Unit testing interview. Theo looks like the chillest dude.
@justinhj1
I like squash merge from feature branch; the main branch has clean history and the feature branch doesn’t have a modified history.
@LukeFrisken
One reason in favour of merge over rebase: Rebasing requires you to resolve conflicts for every commit in your branch that you are rebasing. Let's say that number/size of conflicts in the rebase scenario is proportional to N commits * N number of lines changed in each commit. For the merge scenario, you have to resolve N number of lines changed when compared against the branch you are merging in. If all you ever do is add or delete different lines then this will equate to being about the same, but in reality, when working on some new piece of code there may be a lot of churn on a single section of code, the same line may be edited many times across commits in your branch resulting in many more conflicts during a rebase. When resolving complex conflicts on old commits, you need to recall the exact state of your code at that time, which may be very different to the latest commit, making it much more difficult to do correctly without breaking something. For branches with only a few commits, rebase is fine, but if it grows, at some point it seems to become very time consuming and error prone. Another point in favour of short lived branches I guess, but sometimes it's unavoidable.
@earthling_parth
Very interesting discussion. I think I side over Theo and just get chills thinking about rewriting history and the points where there are commits that don't represent the actual state the code was in. I do agree with Prime about the long term feature branches - I merge and squash my very short lived feature branches: Yes, I love and prefer trunk based development for like 99% of use cases.
@smithshelke2036
This is fucking amazing. I would definitely love to see more of these
@neonraytracer8846