Never* use git pull

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 them 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 Jon was also working on the code making his own commit however Jon 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 good 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 merch commit you see what happens is that your commit and John's commit both had the same ancestor so by default get pull with will merge the two new commits together by creating an entirely new commit like this 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 merch 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 merch 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 pool which creates the extra merge commit use git pole rebase what does that do let's rewind first to the initial situation before we did the regular git poool all right so git poool rebase will take your commit to 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 rebate is you of course still can get merge conflicts in that case kid will tell you though then you can just undo the entire poll with a git rebase abort this will undo everything and restore your local repo to the state was in before you pulled then you can just pull normally with the regular git pull and fix the merge conflict as you usually would so to summarize when I work on a project I almost never use git pull but instead I always try get pull rebase first if it works you're already done if you do get a merge conflict you can always undo the entire poll with a G rebase abort then you can just pull normally using git pull alternatively you could also do an interactive rebase to fix the merch 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 poool rebase since you can always undo it with Git rebase if something goes wrong by the way because gitp rebase is kind of 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 fil matics 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

Channel: Philomatics

Views: 349,867

Keywords: github

Id: xN1-2p06Urc

Length: 4min 1sec (241 seconds)

Published: Mon May 06 2024