git rebase - Why, When & How to fix conflicts

probably the most common scenario for using a git rebase is this one let's say you're working on your own feature branch which has not been pushed or shared with anyone yet as you're working on the feature Branch making your commits to it your teammates are also making commits and merging them into the main branch sometimes you need those changes to continue working on your feature for example if those changes are some important bug fixes or other changes that your feature depends on to get those changes what you could do is just merge the main branch into your feature Branch occasionally when you you do this it will automatically create a merge commit as you keep working on your branch you might have to do this multiple times each time creating a new merge commit doing this more often is also generally a good idea because if there are merge conflicts the longer you wait with the merge the bigger they become and the more difficult they are to fix once your feature is done you'll want to merge your feature Branch back into the main branch this is most often done with a pull request on GitHub once you're ready to merge the pull request you can hit this button it will merge your feature Branch into the main branch the same thing can also be done via command line with these commands but in many teams you don't have the permissions to do this because the main branch is protected in any case once you do the merge a final merge commit will be created this time on the main branch all the other commits will be left in history even after the feature branch has been deleted if everyone on the team does this after time the commit history will be quite full with these extra merge commits that don't really add any meaningful information this makes it quite difficult to navigate the history for example when you're looking for a specific commit where a feature was worked on or a bug was introduced here's an example that shows a typical history with lots of merch commits and you can also see that the branching history is getting quite confusing to decipher for some people this isn't really a problem and for smaller teams and projects you might not even care in that case you don't ever need to rebase at all and you can just keep using git merge but if you do care and want a more linear commit history here are two ways to fix this you can either squash upon merge or do a rebase or you can do both I'll focus on rebasing for this video but let me know in the comments if you'd like to see another video that explains what squashing on GitHub does okay to see what rebasing does let's go back to the beginning when we initially created our feature Branch remember our goal was to get these commits from the main branch into our feature Branch but without creating an extra merge commit this is exactly what rebasing does if we switch to our feature branch and run git rebase Main it will modify the commit history it'll temporarily put these commits to the side and then reapply them one by one but this time with the latest commit on the main branch as the ancestor it's called rebasing because before this commit was the old base commit that our feature Branch was originating from but now this commit is the new base commit so we've rebased our Branch the branches are still separate it's just that our feature Branch now contains all the latest changes from Main and all all the other commits are applied on top of that you can rebase your branch multiple times as needed the big advantage of doing this is that no merch commits were created even once we finally merge our feature Branch back into main this kind of merge that leaves the commit history in a linear state is called fast forwarding this linear history is the main advantage of rebasing since it makes it much easier for you and your teammates to navigate it's not all sunshine and rainbows though in rebase land there are also some major downsides to rebasing First of of all the one Golden Rule of rebasing you should always follow is unless you really know what you're doing never rebase any commits you've already pushed why is it so bad to rebase pushed commits let's take a look as you probably know every git commit is identified by a unique hash when you push to a remote for example to GitHub those commit hashes remain the same however when you rebase a branch the commit hashes for it will change since you've already pushed that Branch the hashes on your machine and the remote no longer match up kid will get confused and won't be able to identify that those commits are actually the same this is particularly bad when other people have already pulled from the remote in the worst case this could lose your team some work because some commits get overwritten this can't ever happen if you only use git merge since git merge doesn't rewrite the history and keeps all commit hashes the same if you're not quite sure if you've already pushed your feature Branch just run G Branch d a to see all your remote branches and if the feature branch is listed there you really shouldn't be rebasing it if it's not listed there you can safely rebase another thing we unfortunately have to worry about are conflicts when you rebase of course it could still happen that the latest changes from the main branch and your changes are in conflict in that case you have two options either you abort the rebase entirely or what I would recommend instead you fix the conflict while you're rebasing if you've never fixed the merge conflict before not even when using git merge you should probably learn about that first I already have a full video on that on my channel Link in the description with rebasing fixing conflicts is unfortunately a bit more complicated still but I guess that's a common theme around Git You See git rebase will take the commits on your feature Branch temporarily put them to the side and then reapply them one by one this means that each commit could potentially cause new conflicts and you might have to go through multiple stages of conflict resolution let's go through a quick real life examp example here I'm on the feature SL login branch which contains three fresh commits they all originate from this commit on the main branch here there are two additional commits on the main branch that I'd like to rebase on top of so basically making this commit the new base commit of my feature Branch I've deliberately set up the repo in this example in such a way that these two commits will cause merge conflicts when reapplied during rebase while this commit will not cause any conflicts okay now let's actually do the rebase and as you can see I'm running into the first conflict if we run get status here we can see that the rebase is still in progress when running into a conflict it will pause the rebase we can see here that the conflict occurred when trying to apply our first commit and there's still two more commits to go after that fixing a conflict during rebase works almost the same as during a merge G will place conflict markers in all conflicted files you then have to open them in your favorite text editor and manually f fix any conflicts you can do this by removing the conflict markers and picking the code that should actually stay in the file after the rebase once you fixed all the conflicts you need to run git ad for all conflicted files if this was all a bit too fast please do check out that other video in the description I explain it in much more detail there now compared to a merge the main difference during a rebase is that instead of committing your changes you need to run git rebase continue when you run that command G will open a text editor to let you change the commit message by default this will open Bim which is a terminal based text editor and it's notorious for being confusing to newcomers if you've never used it before just hit the Escape key then type colon WQ which stands for right quit and will just save and close the file by doing this you're basically telling git that you're fine with leaving the commit message as it is and you don't want to change it by the way if you want to change the text editor that git uses for commit messages and other actions I have a video on my Channel showing you how to do that link in the description after you close the file in Bim kid will automatically continue with the rebase it will apply the next commit of the feature Branch the way I've set up this example repo this commit won't cause any new conflicts so git can just apply it automatically and move on to the next commit the third and last commit is conflicting again so get paused once more to let us fix the conflict let's do that just like we did before and run G re B continue again since there are no more commits left this concludes the rebase and we're done if you want to be sure that you're finished with the rebase Run G status to check that you're no longer in a rebasing state that's it now you've successfully rebased your branch there's also another way to do rebasing the interactive rebase which allows you to undo squash or even reorder commits let me know in the comments if you'd like to see a full video on that by the way I've been teaching inperson courses for git and other programs topics for a few years now and I noticed that while a lot of people gain some insight from videos like this actually implementing the advice and changing your workflows can be a different Beast entirely sometimes it really helps if you have someone guiding you personally along the way and that's why I'm going to offer some live online workshops later this year the workshops will have explanations like in this video but they'll also have some bite-sized exercises for you to try on your own and get immediate feedback from me personally personally so if you like my style of teaching and you are ready to actually get good just go to fil matic.com Workshop to learn more I really enjoy working with people on a personal level so I'd love to see you there I'm still really new to YouTube so I'd love to hear your feedback this video alone took more than 30 hours to create so if you enjoyed it it'd be really great if you subscribe to the channel I have more videos on git in the works and I might also try out other programming related topics if you have any ideas or wishes please let me know down below I'll also post exclusive nony youube content on my website phila.com in the future so if you'd like to get notified when that's released please leave your email address there have a great day and thanks for watching

Channel: Philomatics

Views: 31,409

Keywords: github

Id: DkWDHzmMvyg

Length: 9min 44sec (584 seconds)

Published: Mon Jun 10 2024