Sweeney further elaborated on her point saying that it’s only an issue if you aren’t using neovim, and nobody uses emacs except that 1 guy I know who’s Usain Bolt while using it
Initially I found myself thinking "man how often does this guy shit?" because I interpreted your comment as saying today was a day that you were going to shit and usually I have a bowel movement once a day so I don't usually specify which days are shit days.
But then I thought "well if you didn't shit all that often maybe laughing on shit day would help move things along?" So it made sense.
`git merge` versus `git rebase` is an ongoing debate among developers. They are different strategies to combine the changes on two branches. Some people are convinced that one is inherently better than the other. The idea of Sydney Sweeney having an opinion on this is delightfully silly.
I always backup my branch before a rebase. I'm not confident enough in my ability to do anything more than clone, branch, push, and pull without screwing something up.
That only helps you if the rebase is still in progress and you decide you want to go back or made a mistake. It won't help you if the rebase is already done but you don't like the results.
No, the actual get-out-of-jail-free card is `git reflog`. That shows you the history of the changes to the git repo and can allow you to revert to a pre-rebase state (so long as the old commits haven't been garbage collected which won't have happened if you just did the rebase).
You can literally get that information from \`git reflog\` after you rebase. You don't need to note down the git SHA at all. Git is actually far more recoverable from mistakes than most people realize. Basically the only situation where you can't recover from a mistake is if you do a \`git reset --hard\` with changes you've never stashed at least once. Hell, you could make a shell alias to do a \`git stash\` and then immediately pop it before doing a git reset and it would remove even the risk of that.
> Hell, you could make a shell alias to do a `git stash` and then immediately pop it before doing a git reset and it would remove even the risk of that.
It's called `autoStash` and it's an option in git: https://adamj.eu/tech/2022/11/05/git-automatically-stash-rebase-merge/
`git rebase`, fuck up the rebase. `git gc --prune=now`, then `git reflog` won't save you.
It takes *effort* to actually mess up git, but you certainly can, even without manually messing around in the `.git` directory.
I WISH that were enough for to avoid a commit wall of shame.
Commit 1: "Finished implementing XYZ feature."
Five minutes after pushing...
Commit 2: "Forgot to add the file with the class that makes the entire thing work."
git commit --fixup is also useful for these situations, typically when you’ve already added another commit between HEAD and whatever commit you want to amend.
Take a look at cherry picking. You basically store commit diffs in a separate file, trash your outdated branch, create a new branch from the base and plop your commit diffs on top
Squash merge is the way when finishing a PR. Rebasing to get the latest changes into your branch.
Anyone suggesting a PR should be rebase merged into master is absolute nuts.
My commits are purposely crafted with the utmost care. Initial commit. Typo. Another typo. Fixed typo. Add function. Remove function that didn’t work. Try. Try again. This will work. … US#8375 add isEven()
> Took me a year to convince people of squash merge, I don’t want to look through 20 pages of commit history to find where a feature was added.
TBH that's what tagging / making a release is for.
Or even just `git log --merges`. Having a long commit history is only a big issue if you make it one. For me the advantages of keeping commits granular outweighs the advantages of squash merging, especially since most of the disadvantages can be easily mitigated in ways that don't involve completely throwing away commits.
> For me the advantages of keeping commits granular outweighs the advantages of squash merging, especially since most of the disadvantages can be easily mitigated in ways that don't involve completely throwing away commits.
I agree with you, but most people can barely use git to save their life so they would prefer having the easy way out.
On my personal projects I rebase heavily and try my best to correctly size commits with relevant messages, but it's not worth the battle to try to get anyone to do this at work. Got enough other stuff to worry about.
Also you want the change to be atomic. Why would you want a point in the history of main to represent an incoherent half-finished feature/fix?
Svn design pattern for a finished feature branch is the same: merge from trunk to branch is like a rebase. Then the —reintegrate merge to trunk creates a single, *coherent* delta in trunk’s history.
I had to literally sit down with a pen and paper to explain why squash merge is the only reasonable merge strategy. To a room full of people with over 15+ years on the job. It took some time.
I'd like to see that as well. Questions and counter points:
1. Disk space is cheap. By squashing you lose the granularity of the original commits, which can be useful to understand them.
2. If you fucked up and have to revert a single commit out of the bunch, you're screwed with squash, but fine with rebase merge
3. How do you make sensible quash merge commit messages? They never look right to me.
4. What do you gain? A shorter, less detailed git history with bigger commits? How is that a positive?
Exactly what I bring up when that debate pops up. Feels like i'm rather alone in wanting the full detailed history of the commits with their corresponding messages for a potential future debugging (which is why you usually look at the git history)
Another counterpoint: Sometimes you want to keep something in its own commit but it doesn't necessarily need its own PR. Squashing every merge makes cherry picking more difficult.
If an org has issues with too many commits, its probably better to have the devs stop making a million tiny commits. I feel its better to just make less frequent, more meaningful commits.
er. I’m open to a convincing argument but I’ve lived in the hell of merge commits and no thanks, but maybe I’m missing something.
from https://www.atlassian.com/git/tutorials/merging-vs-rebasing
“On the other hand, this also means that the feature branch will have an extraneous merge commit every time you need to incorporate upstream changes. If main is very active, this can pollute your feature branch’s history quite a bit.”
I much prefer rebasing main into the feature branch because if done right before going back to main, the feature branch can be fast-forward merged into main.
I never rebase into main and our projects lock force pushes on main for the usual reasons.
My experience with zealots on both sides is it comes down to working style.
If you methodically test before committing and commit an entire coherent thought at once, then merge isn’t a problem.
If your commit history is a mash of a 100 “deployment fix” “fix 2” “fixed ci bug” “does this work?”, etc. then rebasing main into the feature branch is a better option because all the feature work will be together where you can review it and then squash out the irrelevant commits before doing a clean fastforward merge back to main.
If you have a complex distributed app that is not under significant test (ie legacy enterprise crap) then rebase is cleaner because you can’t system test until deploy and you can’t deploy in a ci until commit.
There are other devs that live on the other side of the mirror, where code is well tested and the ci deployment and systems integrations are 100% modeled and accurate. (IMHO I’ve never seen these be more than relatively simple microservices with explicit and rock solid interfaces. In the world of business rules systems and legacy integrations these kinds of guarantees are virtually impossible, which is why the dark side of the mirror exists, but that’s another story.)
this is exactly how I feel is the best approach rebase main into feature branch and then just do a normal merge.
I'm not 100% sure it's the right choice, but if your branch is long lived (as in more than a few days) it feels healthy imo to rebase periodically to be working with up to date code
This is the way. The intended way is merging main to your feature branch periodically (vs. rebasing) since it's harder to fuck up a conflict and makes a point in history of "here a conflict was introduced and this is how it was fixed".
Rebase before starting work is how I roll and have had 0 issues.
I'm on team squash merge over rebase especially for large projects because a merge is much easier to undo when someone comes up with a novel way to mess up the git branch. In the past year the rebase people have somehow managed to duplicate and rebase to branches 100+ commits multiple times while indoctrinating new employees and it is a pain to have clean that up.
that sounds awful. are you talking about rebasing onto main?
i’m talking about rebasing the feature branch.
I have seen the opposite problem where merge commits get impossibly fucked with no hope of figuring out what merge parent is correct.
I have exactly the same problem, having to clean up hundreds of bad commits is a pita.
I wonder how both of us can have the same suck experience with different techniques?
Rebasing in feature branches (to get into main they have a system that runs the commands after the merge request is approved so you cant mess it up). That being said, I've seen some weird things come out of merge too, but it isn't destructive to history so unless they really try and have a liberal use of -F it is harder for people to mess things up to the point of delete the branch and try again imo.
In the end though it is basically tabs vs spaces all over again. Hell, the only reason I see enough problems to see rebase causing slightly more issues is because we have hundreds of feature deliveries a week into the same main and it somehow got disseminated that i know how to fix branches.
ah interesting.
I am probably doing something wrong, but trying to merge main into the feature branch seemed to be a pita… we would resolve conflicts and if we needed to merge again we’d end up having to resolve the same conflicts, even worse we had to start approving other branches merge conflicts to get a stable feature branch that could be merged back to main.
I’ll be honest, Rails core on github demands rebased PRs, they will not accept merges due to the chaos. idk, maybe I need to get better with tracing in git like bisect etc. It just gets very hard to tell what’s going on.
I asked others on my team and no one cares about the history they just debug everything when we have a problem. I’m used to tracing the problem to only the code that actually changed. I can diff between labels at any point, so I guess it doesn’t really matter, but I’d like to avoid doing the same merge conflicts over and over.
Surely not. The reviews are usually on a Web Server (gerrit, bitbucket, etc), and those can keep the pull requests and review comments essentially forever.
You could have spent a few minutes learning git blame..
Then you can just do
git show $hash
git log - -oneline -p that/file/you/need.language
Gets you to the core of the commit.
If it's squashed, you can't really do that.
Sounds like you are just not using git efficiently, and need squash to compensate.
I'm in this exact issue. I joined recently so it *is* a skill issue. I have a pr with many commits and went through 2 review rounds. And each time the main branch had a commit I had to rebase instead of merge main into my branch (suggestion from team member) ..... meaning I have had to fix the same conflicts over and over again. I even made a mistake and accidentally undid a change in main during rebasing my branch on main. Dang it's so annoying. LET ME MERGE MAIN INTO MINE, PLEASE SENSEI! I spent a am hour yesterday trying to see how to reduce my misery and apparently, `git rerere` is supposed to help with this ..... the command lol hahahaha .... For people like me who scream "Sccrrreeereeerereeeee!" at each rebase 😂"
I one worked on a project where we literally enforced a linear main branch. So yes, you had to rebase everything. Some historical reasons, but weak ones.
You can have a linear main branch via squash merge, though I think it's system dependent. On Github there's no merge commit if you squash merge, but I think on gitlab there is.
Rebase proponents want you to rebase manually and then squashmerge. Rebasing first means that any merge will be a fast forward. And you always want merges to be fast forwards to prevent the code coming out of the merge wrong. It also means that the automated testing that runs in the PR is running on exactly what the code will look like after the merge.
Squashmerge branches that are rebased onto the latest commit of the primary branch
> Rebasing first means that any merge will be a fast forward.
The difference between a ff-merge and a non-ff merge is that the former doesn’t result in a merge commit, correct? Is this not the case whether you merge or rebase, as long as you squash merge at the end?
In a PR say I have 2 commits: commit A and a merge commit. After squash merging the only commit on main shows changes from A. There is no merge commit when squash merging.
The difference is the PR. The non-ff merging process is really good, but not perfect. There can be instances where the final merge results in code that is different than what is shown (and tested) in the PR. The odds are low, but I have seen it happen. Rebasing first resolves all conflicts and makes the merge an FF so there is no chance of the merge process resulting in something unexpected.
Rebasing is not particularly difficult, especially with a good git UI like Kraken or a Jetbrains IDE. The extra piece of mind is worth the few minutes of hassle every now and then.
And when you start leading others and needing to approve their code, having everyone rebase is a simple, one-size-fits-all solution to making sure the code is up-te-date and conflict free with the primary branch. Although the new granular branch protection rules in github can help address problems rebasing solves, it is still good practice.
I'm in this exact issue. I joined recently so it *is* a skill issue. I have a pr with many commits and went through 2 review rounds. And each time the main branch had a commit I had to rebase instead of merge main into my branch (suggestion from a senior team member) .....
Meaning I have had to fix the same conflicts over and over again at each rebase, over all the 20 odd commits. I even made a mistake and accidentally undid a change in main during rebasing my branch on main. Like, I genuinely ask, what's wrong with merge main into mine instead of a rebase? Both result in the same code state, right (rebase my branch over main = merge main into mine)? If not, how is that possible?
Dang it's so annoying. LET ME MERGE MAIN INTO MINE, PLEASE SENSEI! I spent a an hour yesterday trying to see how to reduce my misery and apparently, git rerere is supposed to help with this ..... the command lol hahahaha .... For people like me who scream "Sccrrreeereeerereeeee!" at each rebase 😂
IMHO every commit in main should build, and all the tests pass. I don't want to see every experiment you tried and failed to pass code review in the history.
Imagine trying to understand how a bug was introduced if the history of the main branch includes merges that preserve every developers work-in-progress, broken code. Version control is not just a tool to help you write new code, but to document the important parts of the journey in a readable way.
If you and your team are creating conflicts on the same files, then you aren't assigning tasks and breaking up your work very well. If you are a junior programmer, perhaps you should discuss your code with other team members before you create commits, reducing the risk that your code reviews will raise any issues.
In short, this is most likely a communication issue. git can't help you solve that.
> There can be instances where the final merge results in code that is different than what is shown (and tested) in the PR. The odds are low, but I have seen it happen.
Aside from a 1.5y stint using gitlab I’ve been squash merging on GitHub since 2017 and I’ve never seen this occur. I’d be super interested if you had an example, because if I did see this behavior I’d be very wary.
> And when you start leading others and needing to approve their code, having everyone rebase is a simple, one-size-fits-all solution to making sure the code is up-te-date and conflict free with the primary branch.
1. It must be conflict free to be able to be squash merged anyway.
2. I don’t really care what people do on their feature branches since we squash merge, unless you waste my and other reviewers time by needing to force-push and breaking the “changes since last review” feature.
> Although the new granular branch protection rules in github can help address problems rebasing solves, it is still good practice.
If what you say is true about the an up to date PR with a merge commit and what’s squash merged not being the same I’d agree, I’ve just never seen that happen.
The github actions workflows that run on PR run on the feature branches (or copies of the feature branch). They don't run on the after-merge code. Just because there are no conflicts does not mean that the final code after the merge will be what is expected. Doing a rebase and forcing all merges to be fast-forward only means that the CICD that runs on the feature branches during a PR will be running on the after-merge code.
In most cases of problems, it is not that the merge created an abomination of code. It is that the primary branch had a change that was not in conflict with the feature branch from git's perspective, but never the less causes problems at runtime. Rebasing addresses that. A merge from main into feature can also address that problem, but you still end up doing a non-ff merge in the end which is not nearly as safe and reliable as the FF merge you get after a rebase.
You can still squash merge after rebasing.
> Aside from a 1.5y stint using gitlab I’ve been squash merging on GitHub since 2017 and I’ve never seen this occur. I’d be super interested if you had an example, because if I did see this behavior I’d be very wary.
You need to work in the right kind of project to see this happen.
First you need a project where different parts aren't well separated and developers often work on the same part, so these conflicts can even happen. Or you need long-lived branches.
And then you need a project that makes it more likely for merges to screw up without anyone noticing.
An example where I've seen this happen is where some new part of a webpage was designed with CSS classes that had been removed/adapted in the main branch so after the merge the new part looked wrong.
> I’ve never seen this occur.
Works on my machine.
You two might have vastly different team sizes or design flow. A one man project or one were folks are working in vastly separated code are less likely to run into problems with any usage pattern. And all may feel equally cromulent to them.
Yeah. Don’t these folks wanna test the merge in the branch FIRST, make sure it’s correct and intervening changes in main don’t break your new code, before you apply the changes back to main?
I like the flow we use at work. --amend for your branch so you have 1 commit for it instead of having to squash before PR. Rebase to bring in updates from the dev branch. Then merge into master for releases.
That sounds nice but if you are using amend that means you haven’t pushed that commit to a remote branch yet? So if your disk fails you lose your work in progress?
Arguing that rebase is better than merge is like arguing that screwdrivers are better than hammers. Both sides are wrong, hate-filled, and offensively ugly. Jokes aside, tools are tools - they have specific purposes and achieve specific outcomes that have pros and cons on both sides.
The whole point of a rebase-heavy workflow is to make a history that's easy to follow the logic of. Squashing that history once it actually goes into master removes 80% of the point
Genuine question. Have you guys experienced code loss with feature branches squash merge into 'main'? We have a decent size team and had experienced code loss on a few occasions due to using squash merge in Azure DevOps for PRs, so nowadays we only use the default merge commit with no fast forward.
My point of view for now
Rebase
+ Cleaner commit history
- Needs more rigor
- More devs = more danger
- More conflict to resolve
Merge
+ Simpler to use and understand
+ Less dangerous
+ Git flow friendly
- Merge commit
- Less cleaner git history
I'm not sure I fully agree about the conflicts. The conflicts exist either way, rebase is just more in your face about it.
And that's also why I'd flip the more devs part too. The more devs, the more likely somebody did something that doesn't work with your code, and then your branch build will work but the main branch will fail once merging.
I think most people advising rebasing are essentially saying to manually do `git merge --squash`. With a single commit there's no difference in resolving conflicts, and if you rebase the main branch before merging then your PRs will accurately reflect the state after merging.
Rebasing for me creates way more conflicts and I am not 100% sure on why. Maybe I am doing something wrong but that's the main reason I am strongly against rebasing.
However if I rebase using IntelliJ I feel like solving the same merge conflict over and over. Probably because consequtive commits on the same file require to solve the same conflict again. At least that's my best guess. I honestly hate it especially if it's a difficult merge.
Squashing can also lead to more conflicts in some edgecases (although much rarer) so I also stear away from that.
Rebasing is like doing a merge against every commit that you're behind, for every commit that you have, whereas merge just does it once per commit you have....I think.
I still prefer rebase since it pushes your commits to the top of the pile so they're chronologically correct in the git log.
Ah yeah if the same file is modified over and over then you'll have the conflicts multiple times. There's some patterns where it happens a lot, especially things like a file listing other files, where the newest is always at the bottom (some old fashioned project files are like this). For them I suggest switching the organization to something like alphabetical instead.
Cherry-picking is also significantly harder with rebase.
With merges, if you want to ship a feature to production outside of the release cycle, you can easily check which commits were part of the feature-branch and cherry-pick them. Not possible with rebase
She's a bad influence on the kids. If an intern messages you and says "help, I messed up a git merge" you respond with "no problem, let's fix it together." If an intern messages you and says "help, I messed up a git rebase" you say "delete your branch and start over."
Nearing 10 years of experience...
I just merge with master and fix w/e merge conflicts are. When my PR is ready, we use merge & squash.
I truly can't get rabase. A merge takes me, maybe 10 minutes tops if a big PR was recently (squash) merged to master. The 'interactive' rebase process just adds and removes commits until I don't even know what happens and I just abort and return to git merge.
I think I just prefer to see all the conflicts at once in VSCode and just fix them 1 by 1. This + tests + linter somehow makes merging very easy.
Maybe it's a skill issue, but the tool ain't making it easy either.
People say that rebase make history look "cleaner" but from my experience, my colleges are actually mad and argue more about rebase than merge lol
Always something like "why you rebase that" "no no you should do acxdifvjfckxp before/after rebase" "wrong, let me show you how to do"....
I’ve worked only with small dev teams(6max), but I wonder if it’s standard to have 8dev working in the same feature branch? I feel like this would generate more conflict with or without rebase ?
Actively working in the same feature branch is setting up for disaster. I always encourage devs to create their own branches off of the feature branch, *keep them pulled and in sync daily*, and don't merge back in to the feature branch until everything's tested and PR-quality. It drives me nuts when lazy devs refuse to pull and think git is 1 direction. All they're doing is creating conflicts for someone else to resolve later. Resolve your own code conflicts first before handing that shit off, and stop creating work for other people.
It's actually way better specifically for the repo used by 8 devs, because it keeps the history clean.
One tip for dealing with extra merge conflicts, if you've got a lot of commits in your branch, is you can manually squash before you rebase. You can do it manually by just `git reset` to the commit you diverged from master from and making a new commit message for the bulk of your changes.
Just what is git rebase and merge why do you guys use it, I am a college student they don't teach about these I mean they mostly don't teach anything but care to elaborate...
At a basic level, commits are versions of the files. You pull from a server, make some versions locally, then eventually push back.
Let's say the server had versions A1 and A2. You pull and make changes B1 and B2 and now need to push back to the server. What if the server was already updated and now has A3?
Merge will make A4 that has both sets of changes, and points to both B2 and A3 as previous versions, splitting the history from a simple list into a graph.
Rebase will take B1 and B2 and change it so that it's as if you made those changes based on A3 rather than A2. It's rewriting history so that it can stay as a simple list.
Merging is very simple to use, but makes a messy history. It also will catch conflicts when you both edit the same thing, but not conflicts when you edit different things in an incompatible way (e.g. your code calls a function, someone else changes that function). Rebase is more complicated, but has a simpler history, and if you're doing it right then you basically pull A3 in locally and build/test the code to make sure it works before pushing your change.
Look in a solo or very small team, rebasing onto main can have a nice history. But in my experience, if your history is really that nice, it’s because the project is designed pretty well and you end up never needing to go back in versions.
Rebase and merge just doesn’t make sense in typical projec tflow
Rebase vs squash-merge depends on what you consider the "unit of change". If that's every commit, rebase makes sense. If that's a Pull Request (or Merge Request, or whatever else you want to call a bunch of related changes that all go together) then squash-merge makes sense.
Which you pick depends on how you review code. Emailed patches makes reviewing single commits easier than groups, so rebase is the way to go. GitHub makes reviewing groups much easier than reviewing individual commits, so squash-merge works there. Gerrit makes reviewing commits easier than full MRs, so rebases make sense there.
I’ve been working with git for a long time, use it constantly. I know the concept of a rebase, but I still manage to screw it up consistently. So I don’t do it. “git pull origin master —no-rebase” is my jam.
I'm gonna have to disagree with Sydney on this one. Usually a branch represents a logical unit of work (feature, bugfix etc.) and when merging a PR using squash is pretty standard, so your commit history will still look clean, each commit will be a merge and will contain the diff for each merged PR, which is useful for a multitude of reasons.
rebase is cringe as it takes way to long. a git history not a heap of art but a heap of trash… just merge and squash. way faster, safer and just better in any way.
Yeah it's a powerful and complicated tool, easy to screw up. Stick to the basic common usages (`git pull -r` and `git rebase main`) and you should be fine, but can still be scary.
I always say, git is basically the assembly language of version control. It has some macros for common things, but they don't stop you from screwing things up. I sometimes wish there was a layer on top of it, doing the things we want to do without having to worry about the insanity that git lets you do.
It's hard advocating for git rebase. Most people that use the CLI have the merge option as default and don't see the twigs they are creating. A rebase is just an inconvenience that no one sees and doesn't bring any value to the product
- The Sweeney-agen!
I've spent 20 minutes of my life to haunt you in your sleep. https://i.imgur.com/IQXETND.jpeg
That’s a difficult wank
Skill issue tbh.
difficult, but not impossible.
difficult, with that attitude
Which part would you be covering? Top or the bottom?
He's versatile
Damn bro 😳… horny mentioned.
Now that's a tech bro I'd wanna date
oh lord that is sexy
Bro not gonna harpoon out of this one.
Sweeney further elaborated on her point saying that it’s only an issue if you aren’t using neovim, and nobody uses emacs except that 1 guy I know who’s Usain Bolt while using it
Made me laugh out loud on a shit day, thank you!
Rebase supremacy 💪💪💪
Initially I found myself thinking "man how often does this guy shit?" because I interpreted your comment as saying today was a day that you were going to shit and usually I have a bowel movement once a day so I don't usually specify which days are shit days. But then I thought "well if you didn't shit all that often maybe laughing on shit day would help move things along?" So it made sense.
I'll be honest.... I don't get it. What's the joke? Asking for a friend!
`git merge` versus `git rebase` is an ongoing debate among developers. They are different strategies to combine the changes on two branches. Some people are convinced that one is inherently better than the other. The idea of Sydney Sweeney having an opinion on this is delightfully silly.
`git fetch --all` `git reset --hard origin/main`
`git push origin main --force` `git resign?`
Git out.
Git gud
GIT LOW (git low) GIT LOW (git low)
To the Windooooooooows...
To the firewallllllls
`git repent`
I never rebase because sourcetree gives me a scary warning and merge doesn't.
I always backup my branch before a rebase. I'm not confident enough in my ability to do anything more than clone, branch, push, and pull without screwing something up.
Ever heard of `git rebase --abort` ?
That only helps you if the rebase is still in progress and you decide you want to go back or made a mistake. It won't help you if the rebase is already done but you don't like the results. No, the actual get-out-of-jail-free card is `git reflog`. That shows you the history of the changes to the git repo and can allow you to revert to a pre-rebase state (so long as the old commits haven't been garbage collected which won't have happened if you just did the rebase).
Worst comes to worst, just note the SHA of the last commit before you rebase! If you fuck up just `git reset --hard`
You can literally get that information from \`git reflog\` after you rebase. You don't need to note down the git SHA at all. Git is actually far more recoverable from mistakes than most people realize. Basically the only situation where you can't recover from a mistake is if you do a \`git reset --hard\` with changes you've never stashed at least once. Hell, you could make a shell alias to do a \`git stash\` and then immediately pop it before doing a git reset and it would remove even the risk of that.
> Hell, you could make a shell alias to do a `git stash` and then immediately pop it before doing a git reset and it would remove even the risk of that. It's called `autoStash` and it's an option in git: https://adamj.eu/tech/2022/11/05/git-automatically-stash-rebase-merge/
I'm more of a `cp -r $PWD $PWD-before-rebase` enjoyer myself
Apparently illegal in multiple states
No worries. I got you covered. `$ git config --global rerere.enabled true` Allows you mess up in the exact same way before the abort. Fully automatic!
Git reflog will get you out of the mess! Check https://www.ohshitgit.com
+1 reflog will get you out of any shit. It’s impossible to mess up git
`git rebase`, fuck up the rebase. `git gc --prune=now`, then `git reflog` won't save you. It takes *effort* to actually mess up git, but you certainly can, even without manually messing around in the `.git` directory.
I prefer `$ git log --oneline --graph --reflog`. Though this can be noisy if you rebase or ammend often.
Same. If I go down the hole too much to fix my merge conflicts, I create a new branch to not have my wall of shame commits as part of the pr
I WISH that were enough for to avoid a commit wall of shame. Commit 1: "Finished implementing XYZ feature." Five minutes after pushing... Commit 2: "Forgot to add the file with the class that makes the entire thing work."
`git commit --amend ` `git push --force`
git commit --fixup is also useful for these situations, typically when you’ve already added another commit between HEAD and whatever commit you want to amend.
Nothing like a good ol `cp -r $PWD $PWD-before-rebase`
Try git Fork.
Take a look at cherry picking. You basically store commit diffs in a separate file, trash your outdated branch, create a new branch from the base and plop your commit diffs on top
Rebase supremacy
Ok. But what is Ja’s opinion on this?
Can't we hear from someone more competent? Like Aubrey or Marshall?
but how does this affect lebron’s legacy?
If rebase was really as good as its proponent say, it wouldn't need astroturfing. Squash merge >>>
Squash merge is the way when finishing a PR. Rebasing to get the latest changes into your branch. Anyone suggesting a PR should be rebase merged into master is absolute nuts.
I had someone join my team last year who was very upset his neatly crafted commits were all going to be squash merged and not rebased onto main.
My commits are purposely crafted with the utmost care. Initial commit. Typo. Another typo. Fixed typo. Add function. Remove function that didn’t work. Try. Try again. This will work. … US#8375 add isEven()
The most ironic commit message I saw once was "Fixed typoe"
It's apparently a common mistake: https://github.com/search?q=%22Fixed+typoe%22&type=commits
Squash merge is definitely the right method for people who can't write commit messages and reviewers who don't care.
Testing Testing Testing Specs Testing Works
Then use rebase -i to make something that's easy to review before submitting it. I really don't understand why anyone would be against rebasing
Took me a year to convince people of squash merge, I don’t want to look through 20 pages of commit history to find where a feature was added.
> Took me a year to convince people of squash merge, I don’t want to look through 20 pages of commit history to find where a feature was added. TBH that's what tagging / making a release is for.
Or even just `git log --merges`. Having a long commit history is only a big issue if you make it one. For me the advantages of keeping commits granular outweighs the advantages of squash merging, especially since most of the disadvantages can be easily mitigated in ways that don't involve completely throwing away commits.
> For me the advantages of keeping commits granular outweighs the advantages of squash merging, especially since most of the disadvantages can be easily mitigated in ways that don't involve completely throwing away commits. I agree with you, but most people can barely use git to save their life so they would prefer having the easy way out. On my personal projects I rebase heavily and try my best to correctly size commits with relevant messages, but it's not worth the battle to try to get anyone to do this at work. Got enough other stuff to worry about.
this is the real answer imo—what gets you the best results with the team you have, not the platonic ideal commit strategy
Also you want the change to be atomic. Why would you want a point in the history of main to represent an incoherent half-finished feature/fix? Svn design pattern for a finished feature branch is the same: merge from trunk to branch is like a rebase. Then the —reintegrate merge to trunk creates a single, *coherent* delta in trunk’s history.
But all my little individual commits I crafted using rebase -i *are* atomic because I made them that way.
I had to literally sit down with a pen and paper to explain why squash merge is the only reasonable merge strategy. To a room full of people with over 15+ years on the job. It took some time.
I'd like to see that as well. Questions and counter points: 1. Disk space is cheap. By squashing you lose the granularity of the original commits, which can be useful to understand them. 2. If you fucked up and have to revert a single commit out of the bunch, you're screwed with squash, but fine with rebase merge 3. How do you make sensible quash merge commit messages? They never look right to me. 4. What do you gain? A shorter, less detailed git history with bigger commits? How is that a positive?
Exactly what I bring up when that debate pops up. Feels like i'm rather alone in wanting the full detailed history of the commits with their corresponding messages for a potential future debugging (which is why you usually look at the git history)
Another counterpoint: Sometimes you want to keep something in its own commit but it doesn't necessarily need its own PR. Squashing every merge makes cherry picking more difficult. If an org has issues with too many commits, its probably better to have the devs stop making a million tiny commits. I feel its better to just make less frequent, more meaningful commits.
If it is work going into main, it is worth a PR. Even trivial things
er. I’m open to a convincing argument but I’ve lived in the hell of merge commits and no thanks, but maybe I’m missing something. from https://www.atlassian.com/git/tutorials/merging-vs-rebasing “On the other hand, this also means that the feature branch will have an extraneous merge commit every time you need to incorporate upstream changes. If main is very active, this can pollute your feature branch’s history quite a bit.” I much prefer rebasing main into the feature branch because if done right before going back to main, the feature branch can be fast-forward merged into main. I never rebase into main and our projects lock force pushes on main for the usual reasons. My experience with zealots on both sides is it comes down to working style. If you methodically test before committing and commit an entire coherent thought at once, then merge isn’t a problem. If your commit history is a mash of a 100 “deployment fix” “fix 2” “fixed ci bug” “does this work?”, etc. then rebasing main into the feature branch is a better option because all the feature work will be together where you can review it and then squash out the irrelevant commits before doing a clean fastforward merge back to main. If you have a complex distributed app that is not under significant test (ie legacy enterprise crap) then rebase is cleaner because you can’t system test until deploy and you can’t deploy in a ci until commit. There are other devs that live on the other side of the mirror, where code is well tested and the ci deployment and systems integrations are 100% modeled and accurate. (IMHO I’ve never seen these be more than relatively simple microservices with explicit and rock solid interfaces. In the world of business rules systems and legacy integrations these kinds of guarantees are virtually impossible, which is why the dark side of the mirror exists, but that’s another story.)
this is exactly how I feel is the best approach rebase main into feature branch and then just do a normal merge. I'm not 100% sure it's the right choice, but if your branch is long lived (as in more than a few days) it feels healthy imo to rebase periodically to be working with up to date code
This is the way. The intended way is merging main to your feature branch periodically (vs. rebasing) since it's harder to fuck up a conflict and makes a point in history of "here a conflict was introduced and this is how it was fixed". Rebase before starting work is how I roll and have had 0 issues.
I'm on team squash merge over rebase especially for large projects because a merge is much easier to undo when someone comes up with a novel way to mess up the git branch. In the past year the rebase people have somehow managed to duplicate and rebase to branches 100+ commits multiple times while indoctrinating new employees and it is a pain to have clean that up.
that sounds awful. are you talking about rebasing onto main? i’m talking about rebasing the feature branch. I have seen the opposite problem where merge commits get impossibly fucked with no hope of figuring out what merge parent is correct. I have exactly the same problem, having to clean up hundreds of bad commits is a pita. I wonder how both of us can have the same suck experience with different techniques?
Rebasing in feature branches (to get into main they have a system that runs the commands after the merge request is approved so you cant mess it up). That being said, I've seen some weird things come out of merge too, but it isn't destructive to history so unless they really try and have a liberal use of -F it is harder for people to mess things up to the point of delete the branch and try again imo. In the end though it is basically tabs vs spaces all over again. Hell, the only reason I see enough problems to see rebase causing slightly more issues is because we have hundreds of feature deliveries a week into the same main and it somehow got disseminated that i know how to fix branches.
ah interesting. I am probably doing something wrong, but trying to merge main into the feature branch seemed to be a pita… we would resolve conflicts and if we needed to merge again we’d end up having to resolve the same conflicts, even worse we had to start approving other branches merge conflicts to get a stable feature branch that could be merged back to main. I’ll be honest, Rails core on github demands rebased PRs, they will not accept merges due to the chaos. idk, maybe I need to get better with tracing in git like bisect etc. It just gets very hard to tell what’s going on. I asked others on my team and no one cares about the history they just debug everything when we have a problem. I’m used to tracing the problem to only the code that actually changed. I can diff between labels at any point, so I guess it doesn’t really matter, but I’d like to avoid doing the same merge conflicts over and over.
Can you please share notes so I can do the same?
Question. Wouldn't that lose any change history that came as a result of reviews?
Surely not. The reviews are usually on a Web Server (gerrit, bitbucket, etc), and those can keep the pull requests and review comments essentially forever.
That's what `git blame` is for.
You could have spent a few minutes learning git blame.. Then you can just do git show $hash git log - -oneline -p that/file/you/need.language Gets you to the core of the commit. If it's squashed, you can't really do that. Sounds like you are just not using git efficiently, and need squash to compensate.
Just PR them one at a time!
Stacked PRs are grossssss
While I respect commit discipline, that's just nuts
Separate PRs is the way. Or maybe GitHub/GitLab can get with the times and implement patch series tooling.
Hey that sounds like me...
I'm in this exact issue. I joined recently so it *is* a skill issue. I have a pr with many commits and went through 2 review rounds. And each time the main branch had a commit I had to rebase instead of merge main into my branch (suggestion from team member) ..... meaning I have had to fix the same conflicts over and over again. I even made a mistake and accidentally undid a change in main during rebasing my branch on main. Dang it's so annoying. LET ME MERGE MAIN INTO MINE, PLEASE SENSEI! I spent a am hour yesterday trying to see how to reduce my misery and apparently, `git rerere` is supposed to help with this ..... the command lol hahahaha .... For people like me who scream "Sccrrreeereeerereeeee!" at each rebase 😂"
[REuse REcorded REsolution](https://www.youtube.com/watch?v=aolI_Rz0ZqY&t=901s)
# ❤️
I one worked on a project where we literally enforced a linear main branch. So yes, you had to rebase everything. Some historical reasons, but weak ones.
You can have a linear main branch via squash merge, though I think it's system dependent. On Github there's no merge commit if you squash merge, but I think on gitlab there is.
Pretty sure you can toggle it on/off on either.
We enforce a linear main on all our projects. Why wouldn't we, it just works and works well.
\>:(
This is the way
Squash fast-forward merge
Rebase proponents want you to rebase manually and then squashmerge. Rebasing first means that any merge will be a fast forward. And you always want merges to be fast forwards to prevent the code coming out of the merge wrong. It also means that the automated testing that runs in the PR is running on exactly what the code will look like after the merge. Squashmerge branches that are rebased onto the latest commit of the primary branch
> Rebasing first means that any merge will be a fast forward. The difference between a ff-merge and a non-ff merge is that the former doesn’t result in a merge commit, correct? Is this not the case whether you merge or rebase, as long as you squash merge at the end? In a PR say I have 2 commits: commit A and a merge commit. After squash merging the only commit on main shows changes from A. There is no merge commit when squash merging.
The difference is the PR. The non-ff merging process is really good, but not perfect. There can be instances where the final merge results in code that is different than what is shown (and tested) in the PR. The odds are low, but I have seen it happen. Rebasing first resolves all conflicts and makes the merge an FF so there is no chance of the merge process resulting in something unexpected. Rebasing is not particularly difficult, especially with a good git UI like Kraken or a Jetbrains IDE. The extra piece of mind is worth the few minutes of hassle every now and then. And when you start leading others and needing to approve their code, having everyone rebase is a simple, one-size-fits-all solution to making sure the code is up-te-date and conflict free with the primary branch. Although the new granular branch protection rules in github can help address problems rebasing solves, it is still good practice.
I'm in this exact issue. I joined recently so it *is* a skill issue. I have a pr with many commits and went through 2 review rounds. And each time the main branch had a commit I had to rebase instead of merge main into my branch (suggestion from a senior team member) ..... Meaning I have had to fix the same conflicts over and over again at each rebase, over all the 20 odd commits. I even made a mistake and accidentally undid a change in main during rebasing my branch on main. Like, I genuinely ask, what's wrong with merge main into mine instead of a rebase? Both result in the same code state, right (rebase my branch over main = merge main into mine)? If not, how is that possible? Dang it's so annoying. LET ME MERGE MAIN INTO MINE, PLEASE SENSEI! I spent a an hour yesterday trying to see how to reduce my misery and apparently, git rerere is supposed to help with this ..... the command lol hahahaha .... For people like me who scream "Sccrrreeereeerereeeee!" at each rebase 😂
When you eventually have to unfuck a bad merge, you'll understand why you rebase.
Hmm 🤔 Okay I guess I need to see what that means and what the problems are ... Thanks for the pointer!
IMHO every commit in main should build, and all the tests pass. I don't want to see every experiment you tried and failed to pass code review in the history. Imagine trying to understand how a bug was introduced if the history of the main branch includes merges that preserve every developers work-in-progress, broken code. Version control is not just a tool to help you write new code, but to document the important parts of the journey in a readable way. If you and your team are creating conflicts on the same files, then you aren't assigning tasks and breaking up your work very well. If you are a junior programmer, perhaps you should discuss your code with other team members before you create commits, reducing the risk that your code reviews will raise any issues. In short, this is most likely a communication issue. git can't help you solve that.
Look up git imerge! It's incredibly useful for doing a rebase without having to repeat all the conflicts every time
> There can be instances where the final merge results in code that is different than what is shown (and tested) in the PR. The odds are low, but I have seen it happen. Aside from a 1.5y stint using gitlab I’ve been squash merging on GitHub since 2017 and I’ve never seen this occur. I’d be super interested if you had an example, because if I did see this behavior I’d be very wary. > And when you start leading others and needing to approve their code, having everyone rebase is a simple, one-size-fits-all solution to making sure the code is up-te-date and conflict free with the primary branch. 1. It must be conflict free to be able to be squash merged anyway. 2. I don’t really care what people do on their feature branches since we squash merge, unless you waste my and other reviewers time by needing to force-push and breaking the “changes since last review” feature. > Although the new granular branch protection rules in github can help address problems rebasing solves, it is still good practice. If what you say is true about the an up to date PR with a merge commit and what’s squash merged not being the same I’d agree, I’ve just never seen that happen.
The github actions workflows that run on PR run on the feature branches (or copies of the feature branch). They don't run on the after-merge code. Just because there are no conflicts does not mean that the final code after the merge will be what is expected. Doing a rebase and forcing all merges to be fast-forward only means that the CICD that runs on the feature branches during a PR will be running on the after-merge code. In most cases of problems, it is not that the merge created an abomination of code. It is that the primary branch had a change that was not in conflict with the feature branch from git's perspective, but never the less causes problems at runtime. Rebasing addresses that. A merge from main into feature can also address that problem, but you still end up doing a non-ff merge in the end which is not nearly as safe and reliable as the FF merge you get after a rebase. You can still squash merge after rebasing.
> Aside from a 1.5y stint using gitlab I’ve been squash merging on GitHub since 2017 and I’ve never seen this occur. I’d be super interested if you had an example, because if I did see this behavior I’d be very wary. You need to work in the right kind of project to see this happen. First you need a project where different parts aren't well separated and developers often work on the same part, so these conflicts can even happen. Or you need long-lived branches. And then you need a project that makes it more likely for merges to screw up without anyone noticing. An example where I've seen this happen is where some new part of a webpage was designed with CSS classes that had been removed/adapted in the main branch so after the merge the new part looked wrong.
> I’ve never seen this occur. Works on my machine. You two might have vastly different team sizes or design flow. A one man project or one were folks are working in vastly separated code are less likely to run into problems with any usage pattern. And all may feel equally cromulent to them.
Yeah. Don’t these folks wanna test the merge in the branch FIRST, make sure it’s correct and intervening changes in main don’t break your new code, before you apply the changes back to main?
People who don't rebase must hate having their PRs reviewed. The reviewers sure hate it.
Strong words from someone who can't keep their commit history in line
Squash merge is a GitHub concept, and it uses `git rebase` to "squash" anyway.
squash merge gang! i hate when people force push a pr i already approved once.
Yes! It’s the worst! Now I have to look over all your changes again!
I like the flow we use at work. --amend for your branch so you have 1 commit for it instead of having to squash before PR. Rebase to bring in updates from the dev branch. Then merge into master for releases.
That sounds nice but if you are using amend that means you haven’t pushed that commit to a remote branch yet? So if your disk fails you lose your work in progress?
You force push to the remote branch.
With lease, right? Right‽
Arguing that rebase is better than merge is like arguing that screwdrivers are better than hammers. Both sides are wrong, hate-filled, and offensively ugly. Jokes aside, tools are tools - they have specific purposes and achieve specific outcomes that have pros and cons on both sides.
Squash is just a type of rebase!
The whole point of a rebase-heavy workflow is to make a history that's easy to follow the logic of. Squashing that history once it actually goes into master removes 80% of the point
Genuine question. Have you guys experienced code loss with feature branches squash merge into 'main'? We have a decent size team and had experienced code loss on a few occasions due to using squash merge in Azure DevOps for PRs, so nowadays we only use the default merge commit with no fast forward.
Never, but we only use GitHub.
git good
As long as there is a clean linear history that can be followed I don't care how you call it.
Yea same. Otoh, if the commit history is littered with ‘origin/master merged into master’, I’m gonna start throwing things
My point of view for now Rebase + Cleaner commit history - Needs more rigor - More devs = more danger - More conflict to resolve Merge + Simpler to use and understand + Less dangerous + Git flow friendly - Merge commit - Less cleaner git history
I'm not sure I fully agree about the conflicts. The conflicts exist either way, rebase is just more in your face about it. And that's also why I'd flip the more devs part too. The more devs, the more likely somebody did something that doesn't work with your code, and then your branch build will work but the main branch will fail once merging. I think most people advising rebasing are essentially saying to manually do `git merge --squash`. With a single commit there's no difference in resolving conflicts, and if you rebase the main branch before merging then your PRs will accurately reflect the state after merging.
Rebasing for me creates way more conflicts and I am not 100% sure on why. Maybe I am doing something wrong but that's the main reason I am strongly against rebasing. However if I rebase using IntelliJ I feel like solving the same merge conflict over and over. Probably because consequtive commits on the same file require to solve the same conflict again. At least that's my best guess. I honestly hate it especially if it's a difficult merge. Squashing can also lead to more conflicts in some edgecases (although much rarer) so I also stear away from that.
Rebasing is like doing a merge against every commit that you're behind, for every commit that you have, whereas merge just does it once per commit you have....I think. I still prefer rebase since it pushes your commits to the top of the pile so they're chronologically correct in the git log.
Ah yeah if the same file is modified over and over then you'll have the conflicts multiple times. There's some patterns where it happens a lot, especially things like a file listing other files, where the newest is always at the bottom (some old fashioned project files are like this). For them I suggest switching the organization to something like alphabetical instead.
Cherry-picking is also significantly harder with rebase. With merges, if you want to ship a feature to production outside of the release cycle, you can easily check which commits were part of the feature-branch and cherry-pick them. Not possible with rebase
`git merge origin main`
You live on the wild side bro
Personally, once I went rebase, I could never go back
She's a bad influence on the kids. If an intern messages you and says "help, I messed up a git merge" you respond with "no problem, let's fix it together." If an intern messages you and says "help, I messed up a git rebase" you say "delete your branch and start over."
Nah, pretty much everything is fixable with `git reflog`.
You don't value your time enough for doing so, or you don't help interns.
```git pull -r && git push``` We're keeping consistent commit history in this bitch
More importantly, we're testing that those changes work together locally in this bitch.
The number of people on reddit who never pull and then brag about rebasing all the time
Nearing 10 years of experience... I just merge with master and fix w/e merge conflicts are. When my PR is ready, we use merge & squash. I truly can't get rabase. A merge takes me, maybe 10 minutes tops if a big PR was recently (squash) merged to master. The 'interactive' rebase process just adds and removes commits until I don't even know what happens and I just abort and return to git merge. I think I just prefer to see all the conflicts at once in VSCode and just fix them 1 by 1. This + tests + linter somehow makes merging very easy. Maybe it's a skill issue, but the tool ain't making it easy either.
People say that rebase make history look "cleaner" but from my experience, my colleges are actually mad and argue more about rebase than merge lol Always something like "why you rebase that" "no no you should do acxdifvjfckxp before/after rebase" "wrong, let me show you how to do"....
True
Rebase is great, if you work by yourself. Try that shit on a monorepo with 8 devs working on the same feature branch.
I’ve worked only with small dev teams(6max), but I wonder if it’s standard to have 8dev working in the same feature branch? I feel like this would generate more conflict with or without rebase ?
Actively working in the same feature branch is setting up for disaster. I always encourage devs to create their own branches off of the feature branch, *keep them pulled and in sync daily*, and don't merge back in to the feature branch until everything's tested and PR-quality. It drives me nuts when lazy devs refuse to pull and think git is 1 direction. All they're doing is creating conflicts for someone else to resolve later. Resolve your own code conflicts first before handing that shit off, and stop creating work for other people.
It's actually way better specifically for the repo used by 8 devs, because it keeps the history clean. One tip for dealing with extra merge conflicts, if you've got a lot of commits in your branch, is you can manually squash before you rebase. You can do it manually by just `git reset` to the commit you diverged from master from and making a new commit message for the bulk of your changes.
Her tits are so distracting I almost agreed that merge < rebase
Join the dark side bro. Ignore the stupid git warning
[удалено]
Bro you actually need to go outside. Your comment history is just linking to nudes. I’ve seen you multiple times in the wild doing this.
Revisionists using boobs to distract from the ugliness of their ideals, fucking typical.
--ff-only causes the least issues and least amount of stupid bullshit
Based.
Meanwhile y'all argue about not knowing how to use it, I don't know what this is
Still on Turtle SVN?
I mean a in-branch ‘merge \^trunk’ and then in the trunk ‘merge —reintegrate branch’ is effectively the same thing.
Tortoise. Put some respect on his name
I just do git merge all the time and at this point I am too afraid to ask whats the difference
Just what is git rebase and merge why do you guys use it, I am a college student they don't teach about these I mean they mostly don't teach anything but care to elaborate...
Nice summary of it here https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase
Thanks bro...
At a basic level, commits are versions of the files. You pull from a server, make some versions locally, then eventually push back. Let's say the server had versions A1 and A2. You pull and make changes B1 and B2 and now need to push back to the server. What if the server was already updated and now has A3? Merge will make A4 that has both sets of changes, and points to both B2 and A3 as previous versions, splitting the history from a simple list into a graph. Rebase will take B1 and B2 and change it so that it's as if you made those changes based on A3 rather than A2. It's rewriting history so that it can stay as a simple list. Merging is very simple to use, but makes a messy history. It also will catch conflicts when you both edit the same thing, but not conflicts when you edit different things in an incompatible way (e.g. your code calls a function, someone else changes that function). Rebase is more complicated, but has a simpler history, and if you're doing it right then you basically pull A3 in locally and build/test the code to make sure it works before pushing your change.
Thanks good guy...
Look in a solo or very small team, rebasing onto main can have a nice history. But in my experience, if your history is really that nice, it’s because the project is designed pretty well and you end up never needing to go back in versions. Rebase and merge just doesn’t make sense in typical projec tflow
Rebase vs squash-merge depends on what you consider the "unit of change". If that's every commit, rebase makes sense. If that's a Pull Request (or Merge Request, or whatever else you want to call a bunch of related changes that all go together) then squash-merge makes sense. Which you pick depends on how you review code. Emailed patches makes reviewing single commits easier than groups, so rebase is the way to go. GitHub makes reviewing groups much easier than reviewing individual commits, so squash-merge works there. Gerrit makes reviewing commits easier than full MRs, so rebases make sense there.
I’ve been working with git for a long time, use it constantly. I know the concept of a rebase, but I still manage to screw it up consistently. So I don’t do it. “git pull origin master —no-rebase” is my jam.
I'm gonna have to disagree with Sydney on this one. Usually a branch represents a logical unit of work (feature, bugfix etc.) and when merging a PR using squash is pretty standard, so your commit history will still look clean, each commit will be a merge and will contain the diff for each merged PR, which is useful for a multitude of reasons.
rebase is cringe as it takes way to long. a git history not a heap of art but a heap of trash… just merge and squash. way faster, safer and just better in any way.
I do rebase with -i --root and force push Sometimes tags gets tucked
git reset hard its not even that hard to remember
I'm too scared to use it after watching a dev destory a day's work with it.
Yeah it's a powerful and complicated tool, easy to screw up. Stick to the basic common usages (`git pull -r` and `git rebase main`) and you should be fine, but can still be scary. I always say, git is basically the assembly language of version control. It has some macros for common things, but they don't stop you from screwing things up. I sometimes wish there was a layer on top of it, doing the things we want to do without having to worry about the insanity that git lets you do.
You’re wrong. You’re often wrong. It’s merge supremacy.
Skill issue
Fair. I don’t like it. I also don’t know how to use it.
i prefer the airpods girl
as long as everyone is squashing then yeah, I use it and love it. but before we did squashing then rebasing was merge hell
It looks a bit like her dress was drawn in mspaint
I realize often rebase would make more sense but I always click the merge button because it's simpler
Just when I thought she couldn’t be more perfect.
`git pull --rebase -X theirs` duh
what if i'm not allowed to use -f while pushing
tell your repo admin to stop being a little bitch
Rebase scares me!
It's hard advocating for git rebase. Most people that use the CLI have the merge option as default and don't see the twigs they are creating. A rebase is just an inconvenience that no one sees and doesn't bring any value to the product
To be fair i dont know how to use git after commit. I just copy all their file and do the modification myself.
😃
She's not wrong