Advanced Git Tutorial - Interactive Rebase, Cherry-Picking, Reflog, Submodules and more
**The Power of Git Repository**
A git repository is a perfect log of all your activities in a project, every change is documented. And sometimes you want to browse through this log, because you're looking for something you're wanting to find a piece of information. So let's talk a bit about how searching and finding good works. Or in other words, how you can filter your commit history.
**Filtering Commit History**
You can filter by almost anything: date, message, author, file, branch, even. So let's start with date and search for all commits that happened after a specific date, for example, we're doing this in the Ruby on Rails, open source repository. There are a couple of commits present, you can use git log and then the after flag. For instance, `git log --after="2022-07-01"` will show all the commits that are after July 1st, specifically specified in that repository. You can also combine this with before flags to get all the commits between July 1st and July 5th.
**Advanced Search Techniques**
If you want to search for a certain commit message, you can do that using the destination grep flag, and let's search for anything that contains "refactored" in its message. And you will see here is one, here's one, and there's lots of others. You can get really fancy with GREP, because it accepts regular expressions. So actually no limits to your creativity.
**Author Search**
Looking for a certain author's work exactly the same using the author flag. For instance, `git log --author="Heinemeier"` will show all the commits from Heinemeier colleague. And of course, before I forget that, you can combine these criteria, of course, so for example, you could use `-a` author and `-b` before in combination to find all commits from a certain person before a certain date.
**File Search**
And then you can also search for files, this can be really handy to understand how a certain file evolved over time, for example, when you know that a certain file used to work fine in the past, but it doesn't anymore. And you could filter for commits with only that file. So let's do that `git log -` (readme dot markdown) will show all the commits where readme dot markdown was manipulated.
**Branch Search**
Finally, pretty helpful way to see commits that are not in one branch, but in another one. For instance, if you want to find out what happened in the main branch after you branch off with your private feature branch, let's type `git log -o` (feature/login) .main. And this will show you all commits that are in Maine, but not in feature login. And you might then decide to do a merge so that you're up to date again, or you can at least see what happened in Maine while you were gone in your future work.
**Advanced Git Techniques**
Alright, so much for today. Be sure to check out my little advanced git kit. It's completely free of charge. It's a little collection of short videos about a lot of advanced get topics from things like interactive rebase, all the way to branching strategies, merge conflicts, sub modules, what have you. It's really helpful if you want to become more productive with Git and version control. And again, it's free. Alright, have fun and see you soon. Here on the Free Code Camp YouTube channel.
"WEBVTTKind: captionsLanguage: enThis is an advanced git course taught by Tobias Gunther. He'll teach you some more advanced concepts and tools to make you more productive and confident with Git. Hello Free Code Camp friends. My name is Tobias. And I'm going to make you a better get user today. If you're using Git is your version control system, you have a lot of powerful stuff available. And we're going to talk about some of the more advanced topics today, cherry picking, interactive rebase sub modules, and much more. At the end of the session, you'll be a lot closer to becoming an advanced git user. Before we start a huge shout out to the Free Code Camp team, thank you so much for being on this mission of teaching people how to code and thanks for letting me contribute a little bit. A couple of words about my own background, I am part of the team behind tower tower is a get desktop GUI for Mac and Windows, we've been around for more than 10 years and helped over 100,000 developers and designer, designers work more easily with get become more productive with Git and make fewer mistakes. For today's sessions session, you do not need to have tower installed, you can follow along on the command line, don't worry. Okay, let's get started. Interactive rebase is like the Swiss Army knife of good commands, lots of use cases and lots of possibilities. It's really a great addition to any developers tool chain. I'll start to explain what you can do with it. And then we'll look at a couple of practical examples. So in short, interactive rebase allows you to manipulate your commit history, you can make changes to your commits after the fact. So you could change an old commits message, you can delete commits, reorder them, combine multiple commits, and even reopen a commit, edit it and make new changes from its change that crazy stuff. Keep in mind, though, that interactive rebase rewrites your commit history. So the commits you manipulate will have new hash IDs. Technically, they are new commits. And there's a simple rule, you shouldn't use interactive rebase on stuff that you've already pushed to a shared repository. Use it for cleaning up your local commit history. A good example is when you're done developing on a feature branch, before you merge it back into a team branch, you can optimize that clean up the commit structure, so it's easier to understand. And that's exactly what interactive rebase is meant to do. Before we take interactive rebase for a test drive, let's look at the general workflow. This is the same no matter what exactly we're doing deleting a commit changing a commit message combining commits, the general steps are always the same. So the first step is to determine which range of commits you want to manipulate. How far back in time do you want to go? Once you have that, you can start the actual interactive rebase session. And finally, you'll have the change chance to make your edits. You can manipulate the selected commits by reordering deleting, combining and so on. Okay, let's try this in practice. We'll do two things as examples. First, we'll change an old commits message. And secondly, we'll combine two old commits into one. Alright, let's hop into the command line and take a look at our repository. git log. Okay, so let's say we want to change this commits message here, right. Just to note, as a reminder, if it were the most recent commit, we want to change this one here, we could just use git commit amend to change the commit message. But for anything older than that, for this one, this one, this one, we really need to use interactive rebase. So the first step for interactive rebase, determine our base commit termen, how far back in history we need to go. And this is at least the parent commit of the one we want to manipulate. So we said we want to change this here. So at least this one here. I could simply copy the commit hash of that commit, or I can do a little bit of counting. So this is head currently head minus one head minus two head minus three, I'll use that. So Git rebase. Stash interactive had till the three. So there is an editor window popping up just as I promised. Let's make this bigger And you can see all of the commits that we just selected. And by selected, I mean that we referred to a range of commits, had to leave three, three behind the head, from head all the way to the one we mentioned. So we can now manipulate these commits. But big but, but we don't change the commit message right here. In this window, we only tell git, what kind of manipulation we want to perform. So we just mark up this line here. With the reward action keyword, that's the action keyword that allows us to change the commit message. And don't worry, all of the action keywords or protocols are documented here in the comments. Alright, reword, then we just save and close the window, we do not make our changes to the commit message right here, right? We do not do that we only mark it up. So save and close. And that's actually it. So now we get an editor window. Again, why is that because we can now finally actually change the commit message. So let's make a change optimize the markup structure, very important. Save and Close. And let's check git log again. And we can see it's now optimized the markup structure. So we've successfully changed an old commits message. So let's do one more example of an interactive rebase. Let's combine. Let's take a closer look. Let's combine well, let's say these two, these two commits here into one. Again, first step of any interactive rebase. Correct, we have to determine the base commit. And again, we have to go at least to the parent commit, so at least this one here, so it's head on is 1234. Okay, so the git rebase, interactive head, and tail D for again, here are the commits, we just requested for manipulation. And this time we're using the squash keyword. Squash works by combining the line we mark up this here with the one above. So by marking up line number two, with squash good, we'll combine it with line number one, which is what we want, right, we want to combine these two commits, so markup, this one with with squash and combine it with the one before. Again, we just save and close the window. And a new window will pop up, right. Why is that because by combining two old commits, we are creating a new one, right. And we can give this new commit a commit message, of course, so I'll just write combine two into one. And again, save and close. And let's see what happened here on the command line. All right, now we have combined these two old commits, you can see they were present here, and they are now combined as one under this commit here. So these were just two examples of what interactive rebase can do. If you want to see the other possibilities, you should check out our video about undoing mistakes in Git, and I'll add a link in the description. Normally, when you integrate commits, you do this on a branch level, you use a command like Git merge or git rebase and integrate all the new commits from one branch into your current head branch. And normally, that's exactly what you want. But in some situations, you might only want a specific commit not all the commits from another branch. And this is where it gets cherry picking tool comes in handy. I'll show you a practical example in a minute. But before that a word of warning. Don't get too excited about cherry pick. Your main way of integration should still be on the branch level, merge and rebase were built exactly for this job. Cherry Picking should only be used for very special situations, you need to have a good reason to use it. It's not a replacement for merge and rebase a sure I'll show you a great example for when cherry pick is actually the right tool to use. Let's say you made a commit on the wrong branch. As an example many teams don't want you to commit directly The domain or master or other long running branches, and still we forget and commit there by accident, of course. And this is a perfect example for cherry pick. Let's take a look at an example situation in practice. Okay, so currently we are on master and have that checked out. And the last commits is newsletter signup page. Okay, but we already have a feature newsletter branch. So my guess is, and I'm correct. This should have been here, this should have happened on the feature newsletter branch. So we want this commit here to be on the feature branch and not on master. So let's use cherry pick to move it over. Oh, okay. So first, we switch to the feature branch, feature newsletter in that case. And then we cherry pick that commit over and we can just copy the commit hash. So this is the one we want to the clipboard. And then git cherry, pick and hash of the commit. And Wallah, let's take a look at what happened. And we can see, boom, here it is. Now, it should have been here in the first place. And finally, here it is. If you also want to clean up the master branch, so this doesn't linger here, it shouldn't be here. Then you can also do this week and get checkout back to master and then get reset to Ashutosh hard head till the one head till the one means one behind the head. So we're effectively deleting this from the master branch. And Wallah. Master is clean and newsletter, feature newsletter now has that brand that commit sorry, well as if nothing had happened. Let's talk a bit about a very special git tool, the ref lock. You can think of the ref log as gits diary. It's a journal where git logs every movement of the head pointer. So what is the movement of the head pointer Exactly. That's when you commit checkout, merge rebase, cherry pick reset, all of the more interesting actions are documented there. And this makes it perfect for those situations where things go wrong. Let me show you a perfect use case for the ref log. Let's say we don't want these two newest commits here. At least we think we don't want them anymore. And to get rid of those, we'll perform a reset, right? They've disappeared from the commit history. And a while later, we noticed that this was a horrible mistake. We've just lost valuable commits. So let's have some fun and make this horrible mistake in practice. Alright, so here we go. Let's say we want to throw away these two commits, and get rid of them. So we are making this here our latest revision on the branch. I just copied the commit hash here to the clipboard. And on the command line, I can get reset dash dash hard and use this commit hash. Alright, let's have a look what happened. And we can see those newer commits disappeared. And we're back at this rubbish in here. I'll give you a couple of seconds to realize that this was a horrible mistake, panic emoji con. And there was invaluable data in those commits, and we just deleted them by accident. So let's see if the ref log can help us in this situation. Opening the ref log is as easy as typing get ref log on the command line. And this here is the ref lock that journal where git logs all of the important actions. And first of all the entries are ordered chronologically, which means the most recent, the newest items are at the top. And if you look closely, you'll find this catastrophic reset action right at the top. We just did that 20 seconds ago. So the journal seems to work. Good news. Now if we want to undo our last action, we can simply restore the state before, which is also documented here. We can just copy the commit hash, this is the state before. I'll copy that to the command line to the clipboard. And I could use git reset once more totally valid, but I'm going to create a new branch. Should I find a little bit more Elegant, happy ending. And I will have it start at that previous revision with the correct state. So let's use that. Let's see what happened. Okay, there's a new branch. Wow, that can that contains the seemingly lost commits. We just saved our necks. Awesome. So we just restored some deleted commits with the ref lock. And here's another great use case for the ref log, restoring branches. So again, we think we can clean up and delete something. This time, it's a branch not commits. But again, as life sometimes goes, we realize that it was a bad idea. And we still need it. So let's take a look at this scenario in practice. That is, ref log, re cover, Branch. Okay, so here's a beautiful, beautiful feature login branch. meds, let's say our customer or boss or team lead, say they don't want it anymore, it's not necessary. So of course, we go ahead and delete it. Just to make things worth worse, this commit here, this one is present nowhere else. So we are definitely going to lose data when we deleted. All right, but before we can delete it, we need to step away from that branch. It's currently the head branch at the moment, and we can't delete the head branch and get so we're checking our master. And then we can delete, we have to force deleted because it contains a commit that is not merged into any other branch. And Wallah. Okay. So now let's say our customer changed their mind. Again, the feature is necessary after also, what do we do? What do we do? What do we do? Let's take another look at the ref log. Alright, and it turns out, we're lucky the last entry was when we made that checkout to master. So let's try returning to the state before again. And I will copy the so here is the checkout and I'll copy this here to the clipboard and get put that on top. git branch I think it was called featured login if I'm right, and we want to have it start at that revision here that we just copied from the ref log. And let's see what happened. So okay, a branches back Wallah. And it includes that seemingly last commit that valuable commit another happy ending. If you're using Git in a desktop GUI like tower like you're seeing here, undoing a mistake is really easy, you can simply press command Z to undo your last action, just like in a text editor, when you made a typo, and this works for almost anything, accidentally deleting branches, commits files, undoing a commit or a bad merge, you might have pushed something too early, doesn't matter what it is. So I can just go ahead and delete this one more time, delete, forced delete, I can just press Command Z. And again, there it is very helpful. Pretty often in a project, you want to include libraries or other third party code. And you can go the manual way, download the code, copy the files into your project, and commit the new files into your projects. Git repository. And this is a valid report approach. But it's not the cleanest one. If you simply throw those library files into your project, you're inviting a couple of problems. First, you're mixing external code with your own unique project files. But the library is actually a project of itself. And it should be kept separate from your own work. There's no need to keep these files in the same version control context as your project. And secondly, should the library change because bugs were fixed or new features added? You'll have a hard time updating the library code. Again, we need to download the raw files and replace the old items. These are quite common problems in everyday project. So Git has a solution and that's sub modules. A sub module is just a standard git repository. The only specialty is that it's nested inside another parent repository. sub module is a fully functional and Git repository. You can modify files commit, pull, push from inside, like with any other repository. Let's see how sub modules work in practice. Alright, so we have a little sample project here. And let's say we want to add some third party code. Creating a lib or or vendor folder is a good idea so that it's cleanly separated from our own files. Let's do that. So let's create lib, and change into that folder. And I will add a little JavaScript library from GitHub, I can do that with a Git submodule, add command, and then provide the remote URL of that repository. And you can see that the command starts to clone the Git repository responsive misspecified. And let's see what happened in our Working Copy folder. And here we go. We have a lib folder, I just created that. And here it is. Our project now contains that third party library inside the lib folder, you can see there's a dot Git sub folder here. So this is indeed a fully featured git repository. And let me emphasize this, again, the actual contents of that sub module, they're not stored in our parent repository. Right? This is important to understand apparent repo only stores the sub modules remote URL, the local path inside the main project and the checkout revision. Of course, the sub modules, working files are here in our project. Now, after all, we want to use the libraries code, but the files aren't are not part of our parent projects. Git repository, they're not part of that version control context. Okay, so let's take a closer look at what else happened. So there's a new git modules file here. So let's take a look at that. Get modules. And so you can see here is the path in our project and the remote URL documented, and as also a record of that in the Git slash config file at the bottom sub module lib to progress again. And finally, the Git also keeps a copy of each sub sub modules git repository in its internal git modules folder. So here is the Git repository. There is modules, and now we have lip to progress. So this is the the Git repository of our library, stored inside of our main git repository. These are all internal files. So please don't mess with this configuration. Because as you can see, get internal gets internal management of sub modules is quite complex. There's good modules, there is dot git config, there is dot get modules. My strong recommendation is don't mess with sub module configuration values and files manually. Do yourself a favor and always use proper git commands or get desktop GUI to manage sub modules. All right, so let's have a look at our projects status. And you can see that Git regards adding a sub module as a modification like any other, so this means we have to commit it to our main repository. Let me just do that quickly. So Git commit dash m, Add to Project to progress library. Okay, we've successfully added a sub module to our main project. Congrats. Now, let's start from the other end. Let's clone a project that already has sub modules added. And let's step out of that and get clone I will clone the Apache Airflow project for that. And let's see what happens here. So I know this project has several sub modules added and we'll take a look at those in a second. Okay. All right. Here we go the airflow project. So let's see. So I know that the product checked has some sub modules in the dot GitHub actions folder. So these are our sub modules for this project. But if we take a closer look after cloning, visual empty. Okay, so what's happening here? Why, why are those sub module folders empty? Well, you already know that a project report does not contain its sub modules files, right? The parent repository only saves the sub module configurations. So when we clone a project with a default git clone command, like I just did, and we only download the project itself with the configuration, the sub module folders, however, they stay empty. And we can repair that by now calling get sub module update. And we have to initialize these for the first time. And we want to do this recursively. Sorry, I have to step into the airflow project folder. And now you can see this action happening here. It's several cloning processes start. And And now, the sub module folders have been populated, or in other words, the sub module Git repositories have been cloned can take another look at that and see, well, yeah, these are all populated now. Right as files in here. Let me see. So using git clone, like we just did, and then an extra command is a bit unnecessary, I would say. So you can achieve the same if you use a particular option with Git clone, the recurse submodules option. This tells Git to initialize all sub modules, when the cloning is finished automatically. So I would have used the command like this instead, right, we left that option here out the recurse submodules. And we would include that now, and everything works from the beginning. Alright. I don't want to go into too much detail about some modules. But one more thing is important to understand the way revisions are checked out in a sub module. A git repository can have countless committed reversion revisions, but the files from one specific revision can be in your working directory at one time, right. So in a normal git repository, you check out a branch. And automatically the last commit in that branch is your checkout revision. If you add new commits to that branch, the checkout revision is all always automatically the newest commit, right, we just move the pointer forwards to the latest commit, like like you can see here. sub module repositories, on the other hand, are always checked out on a specific commit, not a branch. And it makes sense, think about it, the contents of a branch can change over time when new commits arrive. In a sub module, however, you don't necessarily want that sub modules are mostly library code. And in that situation, I want to guarantee that I always have a specific revision of the code. Even if the maintainer of the library ships, some genius updates. I don't know if those would break my code. So I always want a specific chosen version checked out. Alright, let's quickly hop into the sub modules in this project. I can show you that. So this is a target client. And when I select the sub module here, so here you can see that this sub module is not checked out on a branch, but on a specific revision. And this is what I meant. I've already mentioned it managing sub modules is a bit complicated, I can really recommend taking a look at a good desktop, Gui, like tower, for example. So adding updating moving sub modules, all of that is really simple here, take a look and see if it's helpful. Okay, we could talk for hours about sub modules, but I think this should be a good introduction. Just try them out in your project and take it from there. And git repository is a perfect log of all your activities in a project, every change is documented. And sometimes you want to browse through this log, because you're looking for something you're wanting to find a piece of information. So let's talk a bit about how searching and finding good works. Or in other words, how you can filter your commit history. You can filter by almost anything by date by message by author by file by branch even. So let's start with date and search for all commits that happened after a specific date, for example, we're doing this in the Ruby on Rails, open source repository. So there are a couple of commits present, you can use git log and then the after flag. So now I get all of the commits that are after July 1, I specifically specified in that repository, I can also combine that with before, and thereby get all of the commits that are between July 1 And July 5. Pretty easy. And if you want to search for a certain commit message, you can also do that, you can do that with the destination grep. Flag, and let's search for anything that contains refactored in its message. And you will see here is one, here's one, and there's lots of others. You can get really fancy with GREP, because it accepts regular expressions. So actually no limits to your creativity. Looking for a certain author works exactly the same using the author flag. So git log, let's search for anything from a certain Heinemeier colleague. And of course, before I forget that, you can combine these criteria, of course, so for example, you could use dash dash author and dash dash before in combination to find all commits from a certain person before a certain date. And then you can also search for files, this can be really handy to understand how a certain file evolved over time, for example, when you know that a certain file used to work fine in the past, but it doesn't anymore. And you could filter for commits with only that file. So let's do that git log double dash, I'll explain that readme dot markdown, sorry, markdown. And I get all of the commits. Were readme dot markdown was manipulated. The double dashes in that command, if you've taken a look, there just to make sure that Git doesn't confuse the file name with a branch name, right. And finally, pretty helpful way to see commits that are not in one branch, but in another one. So very handy. If you want to want to find out, for example, what happened in the main branch, let's say, after you branch off with your private feature branch. So let's type git log, feature. Login, dash dash, or sorry, dot double dot notation, main. And this will show you all commits that are in Maine, but not in feature login. And you might then decide to do a merge so that you're up to date again, or you can at least see what happened in Maine while you were gone in your future work. Alright, so much for today. Be sure to check out my little advanced git kit. It's completely free of charge. It's a little collection of short videos about a lot of advanced get topics from things like interactive rebase, all the way to branching strategies, merge conflicts, sub modules, what have you. It's really helpful if you want to become more productive with Git and version control. And again, it's free. Alright, have fun and see you soon. Here on the Free Code Camp YouTube channel.\n"