To produce 1 commit, I end up rebasing the damm thing at least 3 times. If there is an problem, it’s at least 2³ times.
I like the idea of it and there were times i used it correctly, but most of the time i do it wrong i guess.
Anyone mind explaining to me how
git rebaseis worth the effort?git mergehas it’s own issues but I just don’t see any benefit to rebase over it.The way I structure my commits, it is usually (but not always) easier and more reliable for me to replay my commits one at a time on top of the main branch and see how each relatively small change needs to be adapted in isolation–running the full test suite at each step to verify that my changes were correct–than to be presented with a slew of changes all at once that result from marrying all of my changes with all of the changes made to the main branch at once. So I generally start by attempting a rebase and fall back to a merge if that ends up creating more problems than it solves.
Well, rebase allows you to resolve the same conflict ten times in a row instead of doing it once. How cool is that?
Squash your branch first
Doesn’t this defeat the purpose, may as well merge then no?
Do not merge your unfinished stuff into main.
I don’t like merging main into my branch because I don’t understand git, and I feel like that can make a confusing history.
Nope, you just need to do it once: https://git-scm.com/book/en/v2/Git-Tools-Rerere.
Why would I ruin all the fun?
Only before you collaborate with anyone else. After that, don’t ever use rebase, or they’ll get an error, and will have to overwrite their local history with the one you’ve rewritten.
I use interactive rebases to clean up the history of messy branches so they can be reviewed commit by commit, with each commit representing one logical unit or type of change.
Mind you, getting those wrong is a quick way to making commits disappear into nothingness. Still useful if you’re careful. (Or you can just create a second temporary branch you can fall back onto of you need up your first once.)
This 100%. I hate getting added to a PR for review with testing commits in the history, and I’m expected to clean those up before merging into main.
I feel like squash and merge on GitHub/GitLab is nicer for that anyway though, it makes the main branch so much cleaner automatically
If you’re using “trunk-based development” (everything is a PR branch or in main), this works great.
If you’re using GitFlow, it can make PRs between the major prod/dev/staging branches super messy. It would be nice if GitHub would let you define which merge strategies are allowed per-branch, but that’s not a thing (AFAIK). So you’re probably better off not squashing in this situation.
I’ve been using merge, and I hate that I don’t even know what rebase really does
Merge takes two commits and smooshes them together at their current state, and may require one commit to reconcile changes. Rebase takes a whole branch and moves it, as if you started working on it from a more recent base commit, and will ask you to reconcile changes as it replays history.
I’m relatively new to git and rebase looks like a mess to me? Like it appears to be making duplicate commits and destroys the proper history?
If you use rebase to get a more readable history, isn’t the issue the tool you use to view the history?
I guess I have to try it out a few times to get it.
What you probably mean by duplicate commits is that it assigns new commit IDs to commits that have been rebased. If you had already pushed those commits, then
git statuswill tell you that the remote branch and your local branch have diverged by as many commits as you rebased.Well, and what is the “proper history”? If your answer is “chronological”, then why so?
For the rare times that it matters when exactly a commit was created, they’ve got a timestamp. But otherwise, the “proper history” is whatever you make the proper history. What matters is that the commits can be applied one after another, which a rebase ensures.When you’re working on a branch and you continuously rebase on the branch you want to eventually merge to, then the merged history will look as if you had checked out the target branch and just made your commits really quickly without anyone else committing anything in between.
And whether you’ve done your commits really quickly or over the course of weeks, that really shouldn’t matter.What is really cool about (supposedly) making commits really quickly is that your history becomes linear and it tells a comprehensible story. It won’t be all kinds of unrelated changes mixed
randomlychronologically, but rather related commits following one another.
And of course, you also lose the merge-commits, which convey no valuable information of their own.you also lose the merge-commits, which convey no valuable information of their own.
In a feature branch workflow, I do not agree. The merge commit denotes the end of a feature branch. Without it, you lose all notion of what was and wasn’t part of the same feature branch.
Agreed, you also lose the info about the resolved merge conflicts during the merge (which have been crucial a few times to me).
Well, with a rebase workflow, there should be no merge conflicts during the final merge. That should always be a fast-forward.
Of course, that’s because you shift those merge conflicts to occur earlier, during your regular rebases. But since they’re much smaller conflicts at a time, they’re much easier to resolve correctly, and will often be auto-resolved by Git.
You’re still right, that if you’ve got a long-running feature branch, there’s a chance that a conflict resolution broke a feature that got developed early on, and that does become invisible. On the flip-side, though, the person working on that feature-branch has a chance to catch that breakage early on, before the merge happens.
The commits aren’t duplicated, but applied to the main branch. Since git has commit ids, they won’t be re-rebased either.
This diagram seems wrong to me. Isn’t the second image a squash merge? Also why would rebasing a feature branch change main?
The only difference between a *rebase-merge and a rebase is whether main is reset to it or not. If you kept the main branch label on D and added a feature branch label on G’, that would be what @andrew@lemmy.stuart.fun meant.
Yeah, the image (not mine, but the best I found quickly) kinda shows a rebase+merge as the third image. As the other commenter mentioned, the new commit in the second image is the merge commit that would include any conflict resolutions.
why would rebasing a feature branch change main?
the image does not update the feature branch. It merges the featurebranch into main with a regular old merge-commit on the main branch.
That’s pretty cool, might actually do that. Tho, we currently don’t use the history as much anyways, we’re just having a couple of small student projects with the biggest group being 6 people. I guess it’s more useful if you’re actually making a real product in a huge project that has a large team behind it
Just remember to not combine it with force push or you’re in for some chaos (rewriting history team members have already fetched is a big no-no).
deleted by creator
Facts. Force push belongs in Star Wars, and nowhere else.
Or, you know, on your own feature branch to clean up your own commits. It’s much, much better than constantly littering your branch’s history with useless merge commits from upstream, and it lets you craft a high-quality, logical commit history.
Of course it has its uses. I didn’t mention them because the guy just learned about rebase - it’s unlikely to be applied flawlessly from the start.
I was replying to the other comment, not yours. Though there’s not really a way of using rebasing without force pushing unless it’s a no-op.
Rebasing is really not a big deal. It’s not actually hard to go back to where you were, especially if you’re using
git rebase --interactive. For whatever reason people don’t seem to get that commits aren’t actually ever lost and it’s not that hard to point HEAD back to some previous commit.
You can do all that without force push. Just make a new branch and do the cleanup before the first push there. Allowing force push just invites disaster from junior developers who don’t know what they’re doing. If you want to clean up after them, that’s your business, I guess.
That’s exactly the same thing. A branch is nothing more than a commit that you’ve given a name to. Whether that name is your original branch’s name or a new branch’s name is irrelevant. The commit would be the same either way.
A junior cannot actually do any real damage or cause any actual issue. Even if they force push “over” previous work (which again, is just pointing their branch to a new commit that doesn’t include the previous work), that work is not lost and it’s trivial to point their branch to the good commit they had previously. It’s also a good learning opportunity. The only time you actually can lose work is if you throw away uncommitted changes, but force pushing or not is completely irrelevant for that.
Force pushes are perfectly safe if you’re working on your own branch, and even if you’re sharing a branch, you can still force push to it as long as you inform and coordinate with whoever else is working on that branch.
I wouldn’t recommend it. The Git documentation itself doesn’t recommend rebase for more than moving a few unpushed commits to the front of a branch you are updating. Using it by default instead of merge requires you to use --force-push as part of your workflow which can lead to confusing situations when multiple developers end up commiting to the same branch, and at worst can lead to catastrophic data loss. The only benefit is a cleaner history graph, which is rarely used anyway, and you can always make the history graph easier to read with a gui without incuring any of the problems of rebase.
Bad take IMO,
At 10+ YOE, I use rebase almost exclusively. Branch from main, rebase to clean up commit history before putting up a PR. If commits are curated properly you don’t run into conflicts very often. Branches really shouldn’t be shared too often anyway, and the ones that are should be write protected.
Catastrophic data loss isn’t really possible either with git since it’s all preserved and you can
git reflogeven if you mess up.The meme is right. Git good
Years of experience don’t really matter here, that’s just call to authority, in this case yourself. You might as well be the worst git user ever after 20 years of usage, or the best after 2. We don’t know that.
Anyway, what you’re saying basically requires a perfect world to be true. Feature branch flow is perfectly fine, but you do end up with merge conflicts constantly, unless you have cordoned off areas of the repo for certain users. Two people working on unrelated features, both change a signature of some helper/util method, merge conflict. Nothing serious, can be fixed in a minute, and rebasing or merging won’t help for either.
Merge is perfectly fine. And arguing about which strategy to use is one of those autistic debates we as an industry seemingly love to have. It doesn’t matter, but you’ll find people screaming at each other about it. See Emacs vs. Vi. Same crap.
Merge is fine, but not knowing both rebase and merge is dumb. And I guess I’ve been in a perfect world this whole time in huge technical orgs lol.
When rebasing, it applies the changes without the commit history?
Does that mean that when you fast forward your main/dev branch and commit, you then add a single commit that encompasses every changes that were rebase?
No, there are no fast-forwards with rebasing. A rebase will take take the diff of each commit on your feature branch that has diverged from master and apply those each in turn, creating new commits for each one. The end result is that you have a linear history as though you had branched from master and made your commits just now.
If you had branched like this:
A -> B -> C (master) \ \ -> D (feature)It would like this after merging master into your feature branch:
A -> B -> C (master) -> E (feature) \ / \ -> D -------------------> /And it would like this if you instead rebased your feature branch onto master:
A -> B -> C (master) -> D' (feature)This is why it’s called a “rebase”: the current state of master becomes the starting point or “base” for all of your subsequent commits. Assuming no conflicts, the diff between
AandDis the same as the diff betweenAandD'.
This a really bad take and fundamentally misunderstands rebasing.
First off, developers should never be committing to the same branch. Each developer maintains their own branch. Work that needs to be tested together before merging to master belongs on a dedicated integration branch that each developer merges their respective features branches into. This is pretty standard stuff.
You don’t use rebasing on shared branches, and no one arguing for rebasing is suggesting you do that. The only exception might be perhaps a dedicated release manager preparing a release or a merge of a long-running shared branch. But that is the kind of thing that’s communicated and coordinated.
Rebasing is for a single developer working on a feature branch to produce a clean history of their own changes. Rebasing in this fashion doesn’t touch any commits other than the author’s. The purpose is to craft a high quality history that walks a reader through a proposed sequence of logical, coherent changes.
Contrary to your claim, a clean history is incredibly valuable. There’s many tools in git that benefit significantly from clean, well-organizes commits.
git bisect,git cherry-pick… Pretty much any command that wants to pluck commits from history for some reason. Or even stuff likegit log -Lorgit blameare far more useful when the commit referenced is not some giant amalgamation of changes from all over the place.When working on a feature branch, if you’re merging upstream into your branch, you’re littering your history with pointless, noisy commits and making your MR harder to review, in addition to making your project’s history harder to understand and navigate.
1000 times this
Merge is taking all the code from the master branch and combining it with the task branch, resulting in a commit for just the merge itself.
Rebase is “re-basing” where your task branch was created from off the master branch. It essentially takes all the commits from master that happened since you branched, REWRITES THE HISTORY of your task branch by inserting those master branch commits before all your existing commits, and effectively makes your task branch look like it was branched yesterday instead of like 4 weeks ago. You changed where your task branch originated on the master. You moved its base.
Atlassian does a fantastic writeup on this.
So, with a merge you basically shuffle in the changes from both branches, but a rebase takes only the changes from one branch and puts it over the other? Edit: no. Read wrong. I should probably watch a vid about it or something
It inserts the master changes before the task branch ones.
So kinda like as if you had kept your branch synced the whole time?
Kind of. Both merge and rebase result in the branches “synced up” but they do it in different ways.
Merge is making a batter for cookies, having a bowl for dry ingredients (task branch) and a bowl for wet ingredients, (master branch) making them separately and then just dumping the dry bowl into the wet bowl (merge).
Rebase is taking a time machine back to before you started mixing the dry ingredients, mix all the wet ingredients first then add the dry ones on top of that in the same bowl.
It’s really hard to create an analogy for this.
I personally prefer “git off my lawn”
Ah, yes, the good old
git off --my lawncommand.
Rebasing is for noobs.
git reset head~42 git push -fHoly shit
I think this is a fake quote that somebody made up for an Internet comedy bit, since it seems unlikely for Hollywood actress Sydney Sweeney to have such uncharacteristically strong opinion on software version control, of all things.
Because she of all people would know that there isn’t anything wrong with using
git merge, and it ultimately comes down to personal preference to what you are used to.I mean, it’s posted in programming humor so yeah.
A bit of the old on the internet no-one knows you’re a dog, I think. Therefore I am a webdev dog too.
But esteemed Academy Award nominated character actress and film director, Margot Robbie, if it’s unlikely that Hollywood actress Sydney Sweeney said this… wouldn’t it be just as unlikely that Margot Robbie would be here? Adding her own comment?
… are you projecting? Is there something you want to tell us esteemed Academy Award nominated character actress and film director Margot Robbie?
I think this is a fake quote that somebody made up for an Internet comedy bit
You can tell by the pixels
No, the tweet is real. Just not the quote.
Margot Robbie, I was about to agree with you and thought that was a very reasonable take, until you tried to argue that
git mergeis better thangit rebase, then I simply had to disregard the whole thing.But they were arguing that it’s personal preference not that one is better than the other
This is why Sydney Sweeney isn’t on Lemmy.
She probably is, just anonymous. It would be crazy to expect anyone to post on lemmy under their real name.
Fair point, Margot Robbie
That’s esteemed Academy Award nominated character actress Margot Robbie to you!
She’s modest too!
And successful Hollywood film producer – props on getting into the stakeholder end of the business so early in your career!
“Don’t always trust what you read on the internet.”
- Benjamin Franklin
Wait a second, there wasn’t even any social media sites back when Benjamin Franklin lived. Did he write that in his newsletter or something?
I think he was a senior contributor for the underground cracker mag 1600 back in the late 80s.
They called em zines.
Truly he was ahead of his time.
Fuck a merge commit! Rebase ervray day bay bayyy.
ITT: people who have no idea how rebasing works.
Skill issue tbh
No doubt.
git rebaseis like a very sharp knife. In the right hands, it can accomplish great things, but in the wrong hands, it can also spell disaster.As someone who HAS used it a fair amount, I generally don’t even recommend it to people unless they’re already VERY comfortable with the rest of git and ideally have some sense of how it works internally.
Yeah it is something people should take time to learn. I do think its “dangers” are pretty overstated, though, especially if you always do
git rebase --interactive, since if anything goes wrong, you can easily get out withgit rebase --abort.In general there’s a pretty weird fear that you can fuck up git to the point at which you can’t recover. Basically the only time that’s really actually true is if you somehow lose uncommitted work in your working tree. But if you’ve actually committed everything (and you should always commit everything before trying any destructive operations), you can pretty much always get back to where you were. Commits are never actually lost.
True, the real danger is using git reset with the --hard flag when you haven’t committed your changes lol
You can get in some pretty serious messes, though. Any workflow that involves force-pushing or rebasing has the potential for data loss… Either in a literally destructive way, or in a “Seriously my keys must be somewhere but I have no idea where” kind of way.
When most people talk about rebase (for example) being reversible, what they’re usually saying is “you can always reverse the operation in the reflog.” Well yes, but the reflog is local, so if Alice messes something up with her rebase-force-push and realizes she destroyed some of Bob’s changes, Alice can’t recover Bob’s changes from her machine-- She needs to collaborate with Bob to recover them.
Pretty much everything that can act as a git remote (GitHub, gitlab, etc.) records the activity on a branch and makes it easy to see what the commit sha was before a force push.
But it’s a pretty moot point since no one that argues in favor of rebasing is suggesting you use it on shared branches. That’s not what it’s for. It’s for your own feature branches as you work, in which case there is indeed very little risk of any kind of loss.
If “we work in a way that only one person can commit to a feature”, you may be missing the point of collaborative distributed development.
No, you divide work so that the majority of it can be done in isolation and in parallel. Testing components together, if necessary, is done on integration branches as needed (which you don’t rebase, of course). Branches and MRs should be small and short-lived with merges into master happening frequently. Collaboration largely occurs through developers frequently branching off a shared main branch that gets continuously updated.
Trunk-based development is the industry-standard practice at this point, and for good reason. It’s friendlier for CI/CD and devops, allows changes to be tested in isolation before merging, and so on.
Ah, you’ve never worked somewhere where people regularly rebase and force-push to master. Lucky :)
I have no issue with rebasing on a local branch that no other repository knows about yet. I think that’s great. As soon as the code leaves local though, things proceed at least to “exercise caution.” If the branch is actively shared (like master, or a release branch if that’s a thing, or a branch where people are collaborating), IMO rebasing is more of a footgun than it’s worth.
You can mitigate that with good processes and well-informed engineers, but that’s kinda true of all sorts of dubious ideas.
Pushing to master in general is disabled by policy on the forge itself at every place I’ve worked. That’s pretty standard practice. There’s no good reason to leave the ability to push to master on.
There’s no reason to avoid force pushing a rebased version of your local feature branch to the remote version of your feature branch, since no one else should be touching that branch. I literally do this at least once a day, sometimes more. It’s a good practice that empowers you to craft a high-quality set of commits before merging into master. Doing this avoids the countless garbage
fix typocommits (and spurious merge commits) that you’d have otherwise, making both reviews easier and giving you a higher-quality, more useful history after merge.
Tbh, we just don’t hire people if they can’t operate git.
Did she just tell people up git good?
i like to create ten different checkouts of main, rebase them all slightly differently and then no fast forward merge them all back into each other
I’ll go one further: use
git rebase --interactiveI remember learning about how to use this back in the day and what a game changer it was for my workflow.
Today I like to do all of the commits as I’m working. Maybe dozens or more as I chug along, marking off waypoints rather than logging actual changes. When I’m done a quick interactive rebase cleans up the history to meaningful commits quite nicely.
The fun part is that I will work with people sometimes who both swear that “rewriting history” is evil and should never be done, but also tell me how useful my commit logs are and want to know how I take such good notes as I go.
Argh. I hate that argument.
Yes - “Rewriting history” is a Bad Thing - but o argue that’s only on ‘main’ (or other shared branches). You should (IMHO) absolutely rewrite your local history pre-push for exactly the reasons you state.
If you rewrite main’s history and force your changes everybody else is gonna have conflicts. Also - history is important for certain debugging and investigation. Don’t be that guy.
Before you push though… rebasing your work to be easily digestible and have a single(ish) focus per commit is so helpful.
- review is easier since concerns aren’t mixed
- If a commit needs to be reverted it limits the collateral damage
- history is easier to follow because the commits tell a story
I use a stacked commit tool to help automate rebasing on upstream commits, but you can do it all with git pretty easily.
Anyway. Good on you; Keep the faith; etc etc. :)
The only other time rewriting history might be bad is when you’re working on a shared branch, which is the point of not rewriting main. If you are working solo on a branch, its history is only what you merge into main so it doesn’t fucking matter at all. If you’re not working solo, maybe you need to adopt a similar process or look at how you’re not working solo. The only time I touch another dev’s branch is at the PR stage and only for quick corrections or missing knowledge so it doesn’t matter if they rebased before or honestly rebase after before the final merge.
At my company we just use a squash policy in gitlab. Every merge request becomes a single commit to the main branch. Super easy to read the commit log because all commits are descriptive instead of a bunch of “fix MR comments” or “fix pipeline errors”.
Another advice:
git reset [commit-id]followed with agit commit -ais a quick way to squash all your commits.Another advice …quick way to squash all your commits
in your IDE select the commits you want to squash. Then rightclick. Then “squash”. All done.
I am still mystified by IDE VCS tools. It’s usually faster for me to do a quick CLI shuffle than use the IDE.
I use like 3 of the git-feature from intellij (out of 100 or so). But these 3 features save me a lot of time.
(the other 2 being the 3-way-merge-view and the commit-view where I can select changes for staging)
Even better, master creating fixup and squash commits and maintain logical commits as you work with
git rebase -i --autosquash
This is really the only sane way to do it. I have run into some wonkyness with the commit history of the target branch commits not resembling
git log, but that’s usually for commits outside of what I’m trying to merge.Edit: squashing commits down this way also helps reduce problems with replaying commit history on the actual rebase. In most cases you don’t need all your “microcommits” in the history, and fewer commits just takes less time to reconcile.
Okay this is the second time I’ve seen Sydney Sweeney referenced in a meme in less than half a day. I had never heard of her before. Who is she, and why is she suddenly attracting so much meme attention?
She’s an American actress who was in Handmaid’s Tale and a few other things and then blew up thanks to her role in Euphoria. She’s become a bit of a meme recently because online conservatives think that her boobs are anti-woke
What a bizarre story. Mr. W is me right now:
Two reasons.
She’s an
AustralianAmerican actress who blew up last year (she was in euphoria I think?), expect to see her in a ton of upcoming blockbusters.She is from Spokane Washington not Australia. She got a lot of recognition for her role in Euphoria and is blowing up a bit right now because she is a young, attractive, talented actress.
She also has a pair of massive blockbusters
Her blown up remains you mean?
Yeah, I had a feeling that was not the best way to put it but I was in a hurry :)
She was excellent in the first season of White Lotus on Sky too. Great show.
You are probably thinking of another talented blonde Australian actress.
Pretty sure Radha Mitchell only does front end development.
How dare you speak to Margot Robbie like that
Why is anyone using X in 2024?
I tried it for a moment, made games stutter like hell, switched back. I know I need to go in and figure it out at some point, but it’s hard to muster the energy when X, for the most part, works fine.
From what I’ve seen, it probably has to do with my Nvidia GPU.
Odd, when i switched to Wayland the stuttering stopped! Also on Nvidia
Depends on a few things with your setup: age of your GPU, the resolution/refresh rate of your monitor. I think even the choice of DP/HDMI can have an impact too
On nvidia, it definitely feels much smoother, but some GPU accelerated programs like games become flickery, i think it’s an xwayland issue
I’m currently at the point where I blame everything that works on my Laptop but not on my PC on Nvidia, because that’s literally the biggest difference between those two. Like currently my getty isn’t displaying properly, which is surely NVidias fault.
Wayland really doesn’t like RDP/remote access, so X is the only way to go if you want that to work properly.
I actually never had an issue on my wayland system. I used remmina for rdp but never had an issue.
I do, I have yet to switch to Wayland
It’s called Twitter now, by conservation of names. /s
You didn’t hear of wayland.social?
OFC it’s real https://wayland.social/explore
Shit, I unironically thought they were talking about this, and I unironically haven’t switched because Barrier is broken on Wayland
because some of the hardware I use is too old to run Wayland
I use X because Cinnamon on Wayland has no option to change the keyboard layout
I tried their experimental Wayland session and it’s still super buggy on high refresh rate/high DPI screens (loads of graphical errors and artifacts) so still a ways to go imo
No censorship tbh
But there is blatant censorship
Nothing even remotely compared to any of the other platforms mate
Platforms of the same nature like Mastodon.social ? Because no.
Actually, internal reports seem to indicate Twitter under Musk complies with much more takedown requests than it did previously, numbers seem to range from 80% to 98%, including requests from countries like China, Ethiopia, Turkey, etc. When people mention censorship by big tech the top three names are Twitter, Facebook, and Google. The only time I know of that twitter fought censorship was when India wanted them to takedown news about farmers’ protests, and Twitter lost in court, probably owing largely to the fact that he cut staff by 80% and ran the company’s finance into the ground by endorsing hate speech.
No, I did not include mastodon in the “other platforms” because 99% of the normies aren’t on decentralized platforms anyway.
Very small pond we’re discussing, as sad as that is.
All I did was answer why THEY think Twitter is worth using. I personally don’t use Twitter, nor do I disagree w/ your take on censorship.
Idk I hang out on Mastodon.social
If yall don’t like the chronological feed then find a hashtag you like and start following people.
Because my new intel integrated graphics cause Wayland to run like a slideshow.
Because their name is Elon Musk.
I used to only merge. Now I rebase. The repo is set up to require squash and rebase when going to main.
All the garbage “spelled thing wrong” and “ran formatter” commits go away. Main is clean and linear.
Squash and rebase or squash or rebase?
…and? You squash so all your gross “isort” “forgot to commit this file” “WIP but I’m getting lunch” commits can be cleaned up into a single “Add endpoint to allow users to set their blah blah” comment with a nice extended description.
You then rebase so you have a nice linear history with no weird merge commits hanging around.
You squash so all your gross “isort” “forgot to commit this file” “WIP but I’m getting lunch” commits can be cleaned up
The next step on the Git-journey is to use interactive rebasing in order to never push these commits in the first place and maintain a clean history to be consumed by the code reviewer.
Squashing is still nice in order to have a one-to-one relationship between commits on the main branch to pull requests merged, imo.
Okay honest question, when you merge a PR in GitHub and choose the squash commits box is that “rebasing”? Or is that just squashing? Because it seems that achieves the same thing you’re talking about.
There’s two options in the green button on a pr. One is squash and merge, the other is squash and rebase.
Squashing makes one commit out of many. You should IMO always do this when putting your work on a shared branch
Rebase takes your commit(s) and sticks them on the end.
Merge does something else I don’t understand as well, and makes a merge commit.
Also there was an earthquake in NYC when I was writing this. We may have angered the gods.
You should IMO always do this when putting your work on a shared branch
No. You should never squash as a rule unless your entire team can’t be bothered to use git correctly and in that case it’s a workaround for that problem, not a generally good policy.
Automatic squashes make it impossible to split commit into logical units of work. It reduces every feature branch into a single commit which is quite stupid.
If you ever needed to look at a list of feature branch changes with one feature branch per line for some reason, the correct tool to use is a first-parent log. In a proper git history, that will show you all the merge commits on the main branch; one per feature branch; as if you had squashed.Rebase “merges” are similarly stupid: You lose the entire notion of what happened together as a unit of work; what was part of the same feature branch and what wasn’t. Merge commits denote the end of a feature branch and together with the merge base you can always determine what was committed as part of which feature branch.
I don’t want to see a dozen commits of “ran isort” “forgot to commit this file lol” quality.
Do you?
Having the finished feature bundled into one commit is nice. I wouldn’t call it stupid at all.
Note that I didn’t say that you should never squash commits. You should do that but with the intention of producing a clearer history, not as a general rule eliminating any possibly useful history.
Lmao I’m in the NYC area and my whole house shook. I’m right there with you. Thanks for the explanation!
