git rebase - Why, When & How to fix conflicts
Vložit
- čas přidán 25. 06. 2024
- Why, when and how to do git rebase. How to fix merge conflicts during git rebase.
If you like my style of teaching, I'd love to see you at a workshop!
philomatics.com/git-workshop/
Fixing merge conflicts:
• Never fear merge confl...
Video on `git pull --rebase`:
• Never* use git pull
How to change your default editor in git:
• 10 useful git aliases
Use the following command to change your default editor to VSCode:
git config --global core.editor "code --wait"
If you use a different editor, just Google "git set text editor to $yourEditor", it's usually easy to find.
Git Graph Extension for VSCode:
marketplace.visualstudio.com/...
If you don't use VSCode, you can also use SourceTree, which is free.
www.sourcetreeapp.com/
0:00 - Why rebase?
1:54 - Squash vs Rebase
2:11 - How to rebase
3:22 - Downsides of rebasing
4:37 - Fixing conflicts
5:28 - Conflict resolution example
8:15 - Interactive rebase
Thank you to Jonas Geiler and Bruno Paulino for giving great feedback on drafts of this video!
LEGAL DISCLAIMER
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
Everything here is for informational purposes only. All non-licensed clips used for fair use commentary, criticism, and educational purposes. See Hosseinzadeh v. Klein, 276 F.Supp.3d 34 (S.D.N.Y. 2017); Equals Three, LLC v. Jukin Media, Inc., 139 F. Supp. 3d 1094 (C.D. Cal. 2015). - Věda a technologie
I'm working on a free git cheatsheet that will (hopefully) put all other cheatsheets to shame. It'll have animations like in this video, and will be interactive. If you want to get notified when it's released, please leave your email here: philomatics.com/
can you also please make a video that explains everything in the cheatsheet?
@@AhmedGamal-mm4sp Hah, working on it! :D
I know a guy who, upon having been fired, committed his changes but never pushed them 😁
I'll add a tip that you lightly touched on: never rebase on another branch without *first* squashing your branch on itself. That way lies madness.
Picture this - you've got 20 commits and you're rebasing on main (or whatever) that has several commits. If you get a conflict, that's *not* a conflict between the current state of your branch and the current state of the other. It's a conflict between the state of your branch 20 commits ago, 19 commits ago (plus changes from last conflict resolution), 18 commits ago (plus changes from previous conflict resolutions), etc. So you have to mentally time-travel back in time to fix what the conflicts would've been at each point in time, for each and every commit, including between code that you didn't write back then but modified during previous conflict resolutions. Possibly introducing more conflicts and/or bugs all along the way. In the end, you haven't rebased the current state of your branch on the current state of the other, you've added all kinds of changes along the way. Now you have tons of changes and untested code that you're pushing.
In a merge commit, *or* if you've squashed your branch into a single commit and *then* rebase, in that case you're only dealing with conflicts between the current state of the two branches. Which is *vastly* easier to wrap your head around and understand and test. No time-traveling needed, no accumulating bugs.
That of course means that you lose your commit history of how you got here from there, since you only have 1 commit instead of 20. But at least you have your sanity.
This is a great suggestion! I would add that you can at least attempt the rebase once before squashing, and only if you get conflicts, abort it using git rebase --abort, then squash, and then rebase again.
I explained squashing in detail on my video on interactive rebase.
git interactive rebase - Undo, Edit & Squash git commits with a single command
czcams.com/video/42392W7SgnE/video.html
The first two minutes I was like "our team squashes the commits so the merge commits don't matter"
But of course you pointed it out as an option
Same. Problem with that, you lose track of what you did for 2 weeks while working on a feature
I have been doing this for years professionally and just learned about cherry picking.
Thats why your channel is important. Git education sucks.
I'm using rebase for many years now. It's the best way to deal with history and conflicts.
This channel is a gold mine. Please keep it up. 😅😅
Thank you for the nice comment, made my day :)
I need more content like this, it's very useful and it keeps me focused while programming
You tell beginners to switch away from vim!?!? The learning curve is GOOD for ya!! It made me what I am today!
"A good beating never hurt anyone" - Albert Einstein
You explain it so easy
I hope you keep with this type of git videos 😅
Beautiful explanation. I haven't found some good guides earliers, and now found perfect
Funny that your video was uploaded yesterday and i just today had to do a rebase for my company's project and referred to your video. Thanks!
"never push if" - you can do anything on your branch (rebasing + force pushing, etc.) until any other users not connected or touching your branch
That's the true golden rule of rebasing. I would add that only use "merge" when two branches should become one - leaving one of them to be permanently discarded. Technically both branches become discarded because they have been "merged" into a new one.
Otherwise, collaborative feature branches should just cherry-pick any critical code that appears on the main / master branch.
exactly what I do as well; I don't think we should be discouraging pushing, even at the cost of conflicts.
Also, --force-with-lease instead of --force resolves the risk of losing work.
@@squishy-tomato To paraphrase The Simpsons: "I'm just going to sit here and push my commits and rebase as I like, and if you get hit, it's your own fault".
But I do use "with lease" just in case. I don't really consider my feature branch "public" until I've made a pull request or have asked someone to branch off of it and make use of my work. And by that point I'm only cherry-picking anyway, in the rare event I need to pull code from higher up in the flow.
Agreed, for the video I thought I'd rather make the rule a bit more restrictive than not, so people don't mess up their repos accidentally. But yeah, as long as you know that nobody else is pulling/pushing your branch, you're fine.
I have always used git merge and yes it creates a messy history, but I have never found that to be a problem.
Really good video, it tells exactly why I am hesitant to ever recommend rebasing. I'm glad you mentioned you were working on it in the replies.
git pull origin main -rebase gang
Wow! Such a clear explanation. I should have watched it before I started fighting the Lord of Branches myself. 😅
I like your videos! Really informative!
Please make more videos! I'm learning proper git and very interesting in Squash and other best practices
Thank you! Now I know why doing rebase for my remote branch doesn't work. Please explain git merge squash as well!
Thanks for sharing this video ❤
great video as always.
previously i thought, when i have a rebase conflict i should do `git add` , `git commit` .
i didn't know about `git rebase --continue`. 🤦♂
thank you very much!
If there are no new changes or file added (check by git status) after rebasing, you don't even need to git add --all. You can directly git push --force or --force-with-lease
Dude, Respect. Love this video and even my manager 6+ year exp don't know how does rebase work. but I know now. please use more examples like the one you did here, that helps alot to understand better. giving you a subscribe buddy.
Very helpful video.
great job, you have got a new subscriber
This.. mate is good stuff!
my philosophy is like this: feature branches belong to a single developer only. even if a reviewer pulled a PR (so he pulled the feature branch), I would not recommend or allow it that he would go on and work with that (reviewing only is fine though). It it is agreed on, that a branch only belongs to one dev, you only have to do force pushes to origin and you are fine.
and, if there would be many commits I'd have to go through during the rebase phase, either do a squash beforehand (on your feature branch) or, do a reset with keep local changes just one commit before you started, stash them away, rebase, then re-apply the stash.
but, in the end, there can only be one (dev) to rule the feature branch so you can be confident to force push to origin after the rebase.
great video !
Sweet video
Nice video! Would love on one squash-and-merge and how it compares to rebasing. I’ve used both a decent amount but don’t feel like I totally understand the pros/cons/differences. :)
:D rebasius lord of branches!
your voice and choices of memes reminds me of @ModestPelican gaming channel 😂 7:07
Good explanation, better memes 🤣
The potential mistake with pushed commits is why we don't use git rebase by default instead of git merge at work, unfortunate, this is so much cleaner...
Yeah I think there's a lot of fear surrounding rebase, but sometimes it's warranted ;) I think many of us have horror stories of messing up our repos with a rebase ^^
@@philomatics Yeah, it's scary... Great video though, and very good channel in general, keep it up!
Well, for feature branches i dont see much problem.
You can do before a backup branch either local or remote.
If you understand rebase and other git commands, theres really no problem. Specially if you know how the reflog works. Everything is reversible.
But it is true that most people don’t spend a lot of time learning git.
So it is understandable.
In my case, I usually work with feature branches where I am the only one commuting, so I do crazy stuff lol.
When merging to main I do a squash merge because that’s the policy
The conclusion we came up to is we almost never have 2 people working on the same branch, and if they need the same WIP code that will both cherry pick it, and then one of them will merge to master and the other will rebase on top of master and discard the cherry picked wip stuff
You can create fresh branch locally. Rebase it and then push to merge
Based video
I'm genuinely this dude 2:55
All hail team rebase. Branch history as straight as bamboo 😂
yes, please make a video on Squash merge😊
Thanks, will consider it if there's enough interest :) Got a lot of other stuff already planned, stay tuned!
Rebase is cleaner, at the cost of lost information, having two parent commits isn't a bad thing, atleast that way we can pinpoint the exact point of merge without needing to read 10k commits
If you wait to long with a rebase you get (maybe) a lot of conflicts too.
I use a git rebase --onto the most time. Do you want to explain it or i could :-)
btw. your teaching is awesome!
7:00 it probably opens your default editor
you can configure that by setting VISUAL or EDITOR or by running update-alternatives or whatever your distro calls that program
I'd like a video about merging strategies for bigger teams and scenarios where you might need work from a different feature branch
Thanks for the suggestion! Do you have a concrete scenario that you've run into in the past that was difficult to handle?
@@philomatics Yes, indeed several different. For a long time I was working with only one colleague on a project where we either only had one branch and rebased when getting the changes from remote or we worked independently on two branches. That worked absolutely fine.
On the following project I worked with about 4 other frontend developers, where we worked pair wise on feature branches. For remote changes we rebased and the same for changes from main. So our feature branches would always be based on the latest changes from remote. We used force push with lease to update the remote feature branches, which of course required some communication. We had a lot of merge conflicts to resolve, which partially was due to project wide changes that affected our feature as well.
In the current project we used one feature branch per "user story" that describes a part of a feature. We are 4 frontend developers once again, but in addition the backend developers are working in the same repository too. Usually one FE and one BE developer is working on one branch. However some features branches partially depend on the work from the other ones. So for example if we are developing feature A, then we have 3 branches: feature featA, featB and featC. To work on featB, you need at least some changes from featA and to work on featC you need the setup from featB.
At the moment we handle this with rebasing, like so:
- Branch featA is created
- featA is implemented to a certain degree
- Branch featB is created based on featA
- Changes from featA are integrated into featB via rebase
- featB is implemented to a certain degree
- featC is created based on featB
- Changes from featB are integrated into featC via rebase
- featA is finished and gets merged into main
- featB is rebased onto main
- featC is rebased onto featB
- featB is finished and gets merged into main
- featC is rebased onto main
- featC is finished and gets merged into main
- Done
So far this reduces the amount of merge conflicts we have. Though one complication is, that in the mean time there still can be other merges to main from bug fixes or other smaller improvements.
Overall this works good, however we still have to force push with lease. Just yesterday, so right before your video, I was explaining what to look out for when rebasing and how the hashes change and that git wouldn't be able to tell that your local commits after the rebase are the same as the ones on remote. I asked them to always communicate a rebase beforehand, especially since those colleagues haven't worked with rebase before. My other colleague, who brought up this way of working, is more experienced and said he doesn't even have issues if he still has local commits. I assume this is still fine because we are still rebasing when fetching remote.
Previously we worked in such a way that you would only start featB when featA was merged into main. But that slowed down development.
@@philomatics Yes, indeed several different. For a long time I was working with only one colleague on a project where we either only had one branch and rebased when getting the changes from remote or we worked independently on two branches. That worked absolutely fine.
On the following project I worked with about 4 other frontend developers, where we worked pair wise on feature branches. For remote changes we rebased and the same for changes from main. So our feature branches would always be based on the latest changes from remote. We used force push with lease to update the remote feature branches, which of course required some communication. We had a lot of merge conflicts to resolve, which partially was due to project wide changes that affected our feature as well.
In the current project we used one feature branch per "user story" that describes a part of a feature. We are 4 frontend developers once again, but in addition the backend developers are working in the same repository too. Usually one FE and one BE developer is working on one branch. However some features branches partially depend on the work from the other ones. So for example if we are developing feature A, then we have 3 branches: feature featA, featB and featC. To work on featB, you need at least some changes from featA and to work on featC you need the setup from featB.
At the moment we handle this with rebasing, like so:
- Branch featA is created
- featA is implemented to a certain degree
- Branch featB is created based on featA
- Changes from featA are integrated into featB via rebase
- featB is implemented to a certain degree
- featC is created based on featB
- Changes from featB are integrated into featC via rebase
- featA is finished and gets merged into main
- featB is rebased onto main
- featC is rebased onto featB
- featB is finished and gets merged into main
- featC is rebased onto main
- featC is finished and gets merged into main
- Done
So far this reduces the amount of merge conflicts we have. Though one complication is, that in the mean time there still can be other merges to main from bug fixes or other smaller improvements.
Overall this works good, however we still have to force push with lease. Just yesterday, so right before your video, I was explaining what to look out for when rebasing and how the hashes change and that git wouldn't be able to tell that your local commits after the rebase are the same as the ones on remote. I asked them to always communicate a rebase beforehand, especially since those colleagues haven't worked with rebase before. My other colleague, who brought up this way of working, is more experienced and said he doesn't even have issues if he still has local commits. I assume this is still fine because we are still rebasing when pulling remote.
Previously we worked in such a way that you would only start featB when featA was merged into main. But that slowed down development.
@@philomatics I wrote rather detailed reply, but my comment seems to go missing. I can still give you the whole description if you want, but for now the short story:
In the current project we used one feature branch per "user story" that describes a part of a feature. We are 4 frontend developers once again, but in addition the backend developers are working in the same repository too. Usually one FE and one BE developer is working on one branch. However some features branches partially depend on the work from the other ones. So for example if we are developing feature A, then we have 3 branches: feature featA, featB and featC. To work on featB, you need at least some changes from featA and to work on featC you need the setup from featB. So far this reduces the amount of merge conflicts we have. Though one complication is, that in the mean time there still can be other merges to main from bug fixes or other smaller improvements.
Overall this works good, however we still have to force push with lease.
@@hollow_ego Thank you very much for describing the situation! I'll see if I can work this into a future video. Feel free to email me if you have further questions (email in YT about page).
It would be very interesting if you could make a video about the configuration and the integration between Git and the remote repos.
There are some obscure things like "verified" commits and other things I never truly understood but I did it...
Thank you for the suggestion!
Hi, great video, Me and my colleague were discussing on the rebase disadvantages and this video popped up, great explanation.
Meanwhile, may i know what animation software or library you're using to creare your videos ?
Thanks for the nice comment! I'm using Motion Canvas :)
@@philomatics thank you ! Btw only some videos and your subscription base much more explains that you're doing so good at explaining crisply.
Power and success to you 😊
I love Vim....and I also love your channel. Great work. For other topics, do you want to get into other devops tools such as K8s, Nomad, Terraform, etc..?
Thank you!
Also, thanks for the suggestions, will consider it!
Instead of going through commits one by one at a time for conflicts, it would be easier if we squash the commit into 1 commit and then try the rebase. This way you will only have to deal with 1 conflict.
That's a good suggestion! Didn't want to do squashing as well in this video as I thought it would be a bit overwhelming. But definitely a good option.
@philomatics no problem. I'm just sharing the users to know that this is also an option instead of being overwhelmed by lots of commit's conflicts
It was a really good point, I wish I would've included that in the video. Maybe in a follow up :)
Tutorial on Rebase + Squash
I want the video on interactive rebase 🖐
So, it means that git merge is better than git rebase?
Since I can push my changes whenever I want without afraid of conflict like git rebase,
and have to resolved it one by one.
Since I usually changes between branch while developing but have to create another branch from main for fixing.
I wouldn't say one is better than the other. It depends on the situation and the workflow in your team. Also the number of merge conflicts you get doesn't change much either way.
As a junior i have a question...
If I plan to work on an important feature while other colleagues carry on other features should I simply avoid rebase?
Or is keeping the branch local not so bad?
In my opinion, it's fine to keep branches local and rebase as much as you like before you push.
@@philomatics got it, thank you so much 😀
8:20 - I do want to see a full video on this. This was my scenario today: I created like 12 commits today. In the 3rd commit I forgot to add into the commit a line from package.json. I rebased using interactive mode, edited that commit, staged the changes and then git commit --amend. It said there are no changes or something. If I wrote git rebase --continue I was getting an error that I have conflicts and need to resolve them. I had zero conflicts.
Fast forwards, did this multiple times and advanced a bit and somehow at the end another file (it was un Changes state) was committed idk how. Eventually I gave up, I have created a separate branch, cherry picked and edited the commits and that was all...
git rebase is hard. Need your help.
Hmmm kinda hard to diagnose remotely but it sounds like your general approach was correct. You'd basically set the 3rd commit to edit when starting the interactive rebase, make your edits, and when finished run git rebase --continue (no need to amend but I think it also shouldn't hurt). Then when running into conflicts, the process is the same as in this video.
I'd have to see precise error messages to give more help probably. You can email me (CZcams About page) if you want :)
Iam convinced that it probaly took weeks to beat Rebasius, Lord of branches.
What is your opinion on doing git rebase onto another branch?
Sorry, not sure I understood the question. Do you mean rebasing onto another branch than main? Nothing wrong with that if the situation calls for it. The main thing you gotta watch out for is if the branch/commits you're rebasing have already been pushed.
@@philomatics thx
Is there any way to avoid this repetition of rebasing after --continue or --skip if i have resolved my code in the first time. Because every time after --continue command i have new conflicts to resolve? Please answer!
Depending on your situation, it can help if you squash first before doing the rebase. Check out my video on interactive rebasing to see how to do that.
git interactive rebase - Undo, Edit & Squash git commits with a single command
czcams.com/video/42392W7SgnE/video.html
Thanks I'll try that
Hey dude i always have problem with git rebase command, it ever rebase in main/master branch and nt in feature branch
Hey, what exact command(s) are you using? What's your branching structure (what's the output of git branch -a)?
@@philomatics
1. It is a complex structure righ now 😅
2. git rebase master (from feature branch)
godlike content, and at low subs. thats ripe
Thank you! Channel is still pretty new :) Please share with colleagues, every little bit helps :)
@@philomatics nah man, this knowledge is just for me. jk
what other sorts of videos do you have planned?
I got more stuff on git in the works - any specific requests about other topics? :)
Squash! Squash!
Do you mean "you should squash", or does that mean you'd like a video on squashing? :)
So if I already pushed my branch to „origin“ I should not use rebase? That makes rebase useless (for me)
You _can_ also rebase a branch that you pushed, but you gotta be sure that nobody else has pulled it or pushed to it. So if you're working on your own feature branch where that's the case, you're still safe.
Just a reminder: there are no links to videos in the description.
Hey, thank you so much for letting me know! I completely forgot about that. Thanks!
@@philomatics NP. Keep making videos like this.
In previous video you say "use pull rebase". Now you say it is not a good idea to rebase if pushed. Can I have more comments on this?
Sure! So in the previous video, the commits that were rejected by the remote, the new ones on your computer, were not yet pushed. Since they are rejected when you try to push, the server doesn't have them yet - thus it's totally safe to rebase them with git pull --rebase. Let me know if anything is unclear :-)
When are you actually working on a branch that isn’t pushed?
You _can_ also rebase a branch that you pushed, but you gotta be sure that nobody else has pulled it or pushed to it. So if you're working on your own feature branch where that's the case, you're still safe.
@@philomatics I guess it feels pretty useless as most projects are collaborative
@@someonesalt5084 Well, it really depends on your branching workflow. If you commonly work on the same branch as a team member, this video might help you more: czcams.com/video/xN1-2p06Urc/video.html
When in doubt, force
Squash
Do you mean "you should squash", or does that mean you'd like a video on squashing? :)
@@philomaticsvideo on squash
I still dont understand
Hey, any specific questions or parts that were confusing? Let me know how I can explain better :)
Guys, guys... GUYS!!!
LISTEN FOR ONCE!
I know you like the pretty rainbow...
but you're doing it WRONG!
I don't think there's much benefit of using a versioning system if you're just gonna discard the history like that. There should a different tool for you guys.
wdym discard the history? Squash discards the history, rebasing forces a linear history
Yeah but the history on main matters not the history on your random branch whilst it is still a work in progress
Git is the system for tracking **and** managing history. Sometimes I wanna get rid of a bunch of junk from history. I love git and I squash and re-base all the time.
$5000 for the workshop? Welp
The workshops are more for established companies that prefer personal interaction and support :) Stay tuned for more free content here and on my site!