A channel with this level of production value has only 38 subscribers!? This video has the best explanation I’ve seen so far of rebase conflict resolution. Make me #39.
This is an excellent explanation. I had this issue at work some days ago and had to go through the painful road of figuring an alternative way to do it because I could not understand the videos I came across. But watching your video now, I see what I should have done clearly and clearly sees how it would have solved the conflicts I had.
I've been banging my head asking why do I keep getting the multiple conflicts during git rebase, I've looked everywhere, thinking I'm not doing it right. Now I know why, I should have done a squash first. Many thanks for that very last minute explanation, not even part if the video topic. It is why I came here. Many thanks
Thank you @Larry\sOke! This means a lot to me. I didn't visit this channel in a while, been busy with my 4th child, and seeing comments like this motivates me to do more explainer type videos!
Thank you for this video! It's helpful to just see you go through the steps and pause to explain what we're looking at frequently, and why we're seeing the step we're at. This is a great approach and makes it much easier to learn than reading documentation in some cases.
Thank you so much, sir! For explaining this topic of rebasing with merge conflicts so well. I have watch many other videos. This is the clearest. I just used it to rebase and solve conflicts by myself for the 1st time! I thought I could never learn to do this by myself. It feels good to not have to plead my male colleagues for help with this all the time.
Great video, keep it up. This is really helpful to better understand git. It would also be nice to have something about branch strategy (trunk based vs gitflow or something). Or when to use a dev branch with separate feature branches. Or when to merge dev into master for a release
Thank you so much for feedback! I'd like to finish up rebase with the squashing and editing the commits, then I'll definitely talk about branching strategy: multiple long-lived branches vs a feature branches, release channels, etc. Best, Alex.
I had a situation where I could not force push the changes after I fixed 5 commit conflicts which ended by one of the commit going missing as there was no difference. Maybe that's why force push didn't work. So I rebased pulled from my remote feature branch to my local branch and I had to fix things all over again and it was pretty different. After fixing conflicts now it has become crazy and full of other people's commits. I'm now thinking of creating a new branch from my current updated main branch then add my changes manually from my old feature branch since I don't want to deal with what's going on there it's messed up!
U menya vse ravno stoit "first resolve merge conflicts", which I of course did, I am not a beginner. Did it serveral times without luck, still the same error. Never used rebase and had to
Hi @thekillercrab, thank you for kind words. Sorry, I’ve been inactive lately. Going to double down on a few new vids shortly - to give back to community!
This is when you made one change to the file. Sometimes we make multiple changes/commits on branch. When rebasing I get promoted to accept current or head changes. I accept and continue, then it ask me to do same in the next commit. Is this normal?
Good question: fetch doesn’t apply changes to your local copy of main branch, but it does apply them to the origin/main “ref”, which is kinda a local mirror of the remote main. So when I rebase on top of origin/main after fetch, I am rebasing on top of latest commit from the remote main. I hope this makes sense :)
Thanks for the excellent video. At 4:05, you say "I can resolve this conflict in here, but this would create a merge commit, and a better way to do it is use a git rebase." ... Would appreciate some clarification on exactly _why_ is it better to use git rebase here versus using the UI and creating a "merge commit." Also, at 4:20, you used git fetch. Would git pull have done the job here, or does it have to be fetch? Why? Thanks for any additional insight!
git pull is basically execution of git fetch and git merge in succession. So in a situation where you want to update your local branch with all the latest changes from remote but don't want git to initiate auto-merging, git fetch is your way.
It depends: if no one else checked out your feature branch - force pushing is not bad at all, you’re just overriding the state of the remote branch with your local state
This is not very helpful because it is a contrived example. I know the basics of how to resolve a merge conflict. I want to see practical examples of resolving merge conflicts. If for example you rebase one branch on top of your other branch, and you have merge conflicts, with duplicated work, how to solve it?
The example is simplified indeed, but the concept in the same: if you have duplicated work in 2 branches and you're trying to rebase one on top of the other: you'll get the same "social markup" in your files with conflicts and you're still responsible for resolving them manually. Sometimes it is not obvious which code changes to keep, so typically both developers hop on a Zoom call and hash it out together. Thanks for the feedback! I might record a video of a "REAL" conflict resolution from my work - if I have a particularly tough one :)
I watched this video after having some difficulty with a git rebase and the video photo perfectly captured my feelings after working with the rebase.
A channel with this level of production value has only 38 subscribers!? This video has the best explanation I’ve seen so far of rebase conflict resolution. Make me #39.
This is an excellent explanation. I had this issue at work some days ago and had to go through the
painful road of figuring an alternative way to do it because I could not understand the videos I came across.
But watching your video now, I see what I should have done clearly and clearly sees how it would have solved
the conflicts I had.
Thank you so much for your comment! It means a lot to me!
It's criminal more people haven't seen this, especially the cut-away head smash. Hope you continue with more vids some day!
Thank you so much! I'd like to do more with my team :) We're just a bit busy this Q4 at work :)
I've been banging my head asking why do I keep getting the multiple conflicts during git rebase, I've looked everywhere, thinking I'm not doing it right. Now I know why, I should have done a squash first. Many thanks for that very last minute explanation, not even part if the video topic. It is why I came here. Many thanks
Thank you @Larry\sOke! This means a lot to me. I didn't visit this channel in a while, been busy with my 4th child, and seeing comments like this motivates me to do more explainer type videos!
I have been having this issue for years, so nice to finally figure it out
Thank you for this video! It's helpful to just see you go through the steps and pause to explain what we're looking at frequently, and why we're seeing the step we're at. This is a great approach and makes it much easier to learn than reading documentation in some cases.
Nice, great explanation. And I liked that "I always pull before push to avoid conflicts", had a nice laugh
The sketch really cracked me up. More, please!
Hi @Daria, let's face it - I only do the programmer videos so I could include silly sketches with them :) Working on another one as we speak!
Thank you so much, sir! For explaining this topic of rebasing with merge conflicts so well. I have watch many other videos. This is the clearest. I just used it to rebase and solve conflicts by myself for the 1st time! I thought I could never learn to do this by myself. It feels good to not have to plead my male colleagues for help with this all the time.
Thank you for saying this! It means a lot to me! I'm working on the Kubernetes one now :) Takes time to do it right
Nice! Your explanations are very didatical! Thank you! I'm curious about the next video.
Looool. Everytime I have some conflicts to resolve I come for this video. Thanks a bunch.
probably only video that exactly addresses my problem. thank you.
Great video, keep it up. This is really helpful to better understand git. It would also be nice to have something about branch strategy (trunk based vs gitflow or something). Or when to use a dev branch with separate feature branches. Or when to merge dev into master for a release
Thank you so much for feedback! I'd like to finish up rebase with the squashing and editing the commits, then I'll definitely talk about branching strategy: multiple long-lived branches vs a feature branches, release channels, etc.
Best,
Alex.
Thanks for clean explanation.
thanks for the explaination sir
Always so scary when you don't know exactly what you're doing. Thank you for clearing that up for me in the future!
I was drinking some water while listenning at the video. At 0:47, I spat all of the water at my monitor because I laugh so hard.
So sorry (not) LOL :)
Thank you for this video!
thank you so much! finally i undestand this
Thanks for watching! :)
I had a situation where I could not force push the changes after I fixed 5 commit conflicts which ended by one of the commit going missing as there was no difference. Maybe that's why force push didn't work. So I rebased pulled from my remote feature branch to my local branch and I had to fix things all over again and it was pretty different. After fixing conflicts now it has become crazy and full of other people's commits. I'm now thinking of creating a new branch from my current updated main branch then add my changes manually from my old feature branch since I don't want to deal with what's going on there it's messed up!
The best one ever!
Thank you, this helped me a lot.
Very well explained!
This is the best video!
Спасибо из Воронежа )
Привет из Юты! О чем разговор, на здоровье ;)
U menya vse ravno stoit "first resolve merge conflicts", which I of course did, I am not a beginner. Did it serveral times without luck, still the same error. Never used rebase and had to
Thanks, this video was really helpful
Thanks!
very helpful thank u :)
this was so useful! when is the interactive rebase vid coming?
Hi @thekillercrab, thank you for kind words. Sorry, I’ve been inactive lately. Going to double down on a few new vids shortly - to give back to community!
This is when you made one change to the file.
Sometimes we make multiple changes/commits on branch. When rebasing I get promoted to accept current or head changes. I accept and continue, then it ask me to do same in the next commit. Is this normal?
0:47 must have hurt
ribs hurt from laughing so hard
great stuff ..thanks
Thanks
At 4:20, how come you didn't have to pull the remote changes? I thought fetch only downloaded them without applying them?
Good question: fetch doesn’t apply changes to your local copy of main branch, but it does apply them to the origin/main “ref”, which is kinda a local mirror of the remote main. So when I rebase on top of origin/main after fetch, I am rebasing on top of latest commit from the remote main. I hope this makes sense :)
Did team programmer become a HR associate or something? There is not a next video, maybe he fell in the lake in Salt Lake City? RIP team programmer
I'm so sorry! I had a new child born and things got out of whack. Planning to get back to it, with more jokes :)
I did that but there is a loop
Thanks for the excellent video. At 4:05, you say "I can resolve this conflict in here, but this would create a merge commit, and a better way to do it is use a git rebase." ... Would appreciate some clarification on exactly _why_ is it better to use git rebase here versus using the UI and creating a "merge commit."
Also, at 4:20, you used git fetch. Would git pull have done the job here, or does it have to be fetch? Why?
Thanks for any additional insight!
git pull is basically execution of git fetch and git merge in succession. So in a situation where you want to update your local branch with all the latest changes from remote but don't want git to initiate auto-merging, git fetch is your way.
@@eddiethehead7466 thanks Eddie!
Isn't force push a bad strategy?
It depends: if no one else checked out your feature branch - force pushing is not bad at all, you’re just overriding the state of the remote branch with your local state
@@teamprogrammer9650 got it, thanks.
Thanks a lost.
Yep, sorry, I'm lost for a while.... Planning to get back to it.
I feel like he is struggling to not blink horizontally
You got me :D
This is not very helpful because it is a contrived example. I know the basics of how to resolve a merge conflict. I want to see practical examples of resolving merge conflicts. If for example you rebase one branch on top of your other branch, and you have merge conflicts, with duplicated work, how to solve it?
The example is simplified indeed, but the concept in the same: if you have duplicated work in 2 branches and you're trying to rebase one on top of the other: you'll get the same "social markup" in your files with conflicts and you're still responsible for resolving them manually. Sometimes it is not obvious which code changes to keep, so typically both developers hop on a Zoom call and hash it out together.
Thanks for the feedback! I might record a video of a "REAL" conflict resolution from my work - if I have a particularly tough one :)