Never* use git pull

- In this video, the remote branch is ahead of the local branch. John was also working on the same branch, so they have the same ancestor. The solution is to put the commit after the other person's commit.

Speaker A: So you just finished writing some code, you commit it, you push it and then rejected. Of course, what happened here is that someone else, let's call him John, was working on the same branch as you. You both started out at the same commit as you wrote your code making your local commit. John was also working on the code making his own commit. However, John pushed his code first to the remote, for example to GitHub. So then when you try to push your commit, it gets rejected because the remote branch is ahead of your local branch. This means that the remote branch has newer commits that your local branch doesn't have yet. But there's an easy fix. You just do a git pull to get the new changes and then actually, here is why you shouldn't do this. When you do a git pull in this situation, you're actually creating a fresh merge commitment. You see, what happens is that your commit and John's commit both had the same ancestor.

Speaker B: So by default, git pull will merge the two new commits together by creating an entirely new commit like this.

Speaker A: If everybody on the team does this over time, you'll just end up with a confusing commit history with a bunch of extra useless merge commits in it. This makes it really hard to navigate the commit history. For example, when you're looking for a specific commit in which a certain feature was worked on or a bug was fixed, because then you have to sift through all those useless merge commits first. What you usually want to do instead is to just put your commit after the other person's commit. That way the commit history will stay linear and clean. So instead of using the regular git pull, which creates the extra merge commitment, use git pull rebase.

Speaker B: What does that do? Let's rewind first to the initial situation before we did the regular git pull. Alright, so git pull rebase will take.

Speaker A: Your command temporarily, put it to the side, do the git pull, and then it'll try to put your commit back on top. This even works if you or the other person did multiple commits. But wait, I hear you say, what about merge conflicts? What if the changes the other person made and my changes are in conflict? Normally when you do a regular git pull, you just get a merge conflict that you can then fix. When you do a git pull rebase, you of course still can get merge conflicts. In that case, git will tell you though, then you can just undo the entire poll with a git rebase abort. This will undo everything and restore your.

Speaker B: Local repo to the state it was in before you pulled.

Speaker A: Then you can just pull normally with the regular git pull and fix the merge conflict as you usually would.

Speaker B: So to summarize, when I work on a project, I almost never use git pull, but instead I always try git pull rebase first. If it works, you're already done.

Speaker A: If you do get a merge conflict.

Speaker B: You can always undo the entire pull with the git rebase abort. Then you can just pull normally using git pull.

Speaker A: Alternatively, you could also do an interactive rebase to fix the merge conflict, but that's a bit more involved, so let me know in the comments if you'd like to see a future video on that. In any case, you don't have to worry about breaking anything with git pull rebase since you can always undo it with git rebase abort if something goes wrong. By the way, because git pull rebase is kinda a lot to type, I have this handy git PR alias which you can set up with this command or by editing your global git config. I'll show you how to do that, and also a few other useful git shortcuts in my next video. This has been Filmmatix. This is my first YouTube video ever, so I'd be really happy if you leave a comment and subscribe to my channel to learn other useful developer tricks. Thank you.