@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.
@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
@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.
@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.
@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.
@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.
@DebugChug.
How often will you be doing these?? This was great!
@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.
@Pictor13
I was a big fan of `rebase` like Primeagen, hated `merge` commits confusing the visual clarity. I also liked to rebase & squash in a single commit. I was kind of OCD on it. With time I started to prefer keeping all those "progression" commits, because they say more "show me how you got there" rather than "show me what you got" (cit). Especially useful re-reading history months/years after, when I forgot 90% of my work. Also, I sometimes tend to ride the flow of the moment, get many parallel ideas and change lot of things, ending up with long-lived branches. On local I ALWAYS rebase, if I am the only contributor of the repo; otherwise I use it as last step to get everything clean and sequencial. However, merge started to be useful a lot when: - working with several colleagues over the same repo; having a separate branch for each small ticket is a godsend, makes the whole interaction on the repo a lot clearer. It makes easier to understand who did what and when and related to what issue, without the noise of having unrelated commits in the way. - using workflow with such colleagues, like `source ticket123-branch from dev-branch` -> `implement & commit` -> `QA ticket123-branch` -> 'merge back into dev-branch` - working on PRs. Yes... unfortunately they don't keep track of old commits that were rebased, ending with code-review comments that refer now commit-SHAs that do not exist anymore. - needing to juggle between deployments that run different versions of the code but that will need to be re-aligned later on. The version on Production can keep adding critical bugfixes, while on Test I can keep evolving in a major/patch version, and merge the critical fixes later on. MY MAIN CONCEPT IS: -- When I work on PRIVATE branches (I prefix them like `pictor/wip/ticket123`), I do ANYTHING with them (apart for merge): wip commits, dirty commits, backup commits, `rebase`, `rebase -i HEAD^^^`, `push --force`, harass commits, beat down branches, slap remotes in da face. And when I'm done, clean everything and swap from "private" to "shared" (what I call a "real commit"): by rebasing in a new `ticket123` branch and pushing it (also caring to delete the now obsolete `pictor/wip/ticket123` ref from remote). -- Once my work become a SHARED branch, if I merge-fast-forward (same result as rebase) I would see only a single sequence of commits and there more thinking load when (in the future) trying to understand the chronology of what happened. While if I merge in a new commit, I can visually see what was merged, related to what, when it started, when it finished, and (in the merge commit) what files were having conflicts). The value of this is great when analysing a repo with lot of parallel work from many contributors. But, yes, IT IS harder to look at, although it is easier to follow. Dunno if all this mess makes sense to anybody else 😁😁😁
@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.
@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.
@f282072
This was stressful to watch, almost wanted to jump in with the opinions sleeves rolled up. Beautiful.
@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
@justinhj1
I like squash merge from feature branch; the main branch has clean history and the feature branch doesn’t have a modified history.
@Lark_
Theo has a very good point. Let's say I'm on a feature branch, and I made commits A, B & C. I, as a single developer on my local machine, I did was working on the past on commits A, B & C. I've read the files while being on those states, I tinkered with the code on these states, and I made some attempts that didn't work on these states. If later on, somebody puts something new on master, and I still didn't finish my feature branch and I want to make a rebase.I will be indeed on commit C with the newest updates on master as my new base. I can see things working properly on my repo and that may seem fine. However, even though I can look at my history and see commits A & B with it's new base, the all things I've tested on the past and didn't get recorded on commits A & B will be no longer valid. YES, the changes will still be the same on commits A & B. But what I REALLY did on the past while tinkering and reading will be gone. Because On the past I was on commits A & B doing some stuff with another base. What if after doing the rebase I merge my branch into master and somebody else does want to return to commit A or B and test something there to see a bug for instance with a tool like bisect: what this person will be doing will not match with what I actually did on the past while being on those commits. This certainly is an issue, that is a strong point for Theo, even more considering that he uses bisect a lot. Somebody using bisect could get to commit A on my rebase and tell me: "hey! I changed a little bit this file on your commit A, and I got this result that solved the bug. It was very simple! Why didn't you catch that?" Well, actually what you tested on commit A was not what I tested, because I did a rebase. So I couldn't see it. When I was in commit A working, I had a different base that didn't let me make the test you did.
@neonraytracer8846