One situation I might do a `git fetch` rather than a `git pull` would be if I knew there were changes in both the local repo and the remote. The default for `git pull` is ff-only and that will fail if there are changes in both repos so I would do the `git fetch` that would let me review the changes before merging so I can see if there will be any problems. After reviewing I can do a manual rebase or just `git pull --rebase` which means my local repo will then have the remote changes followed by my changes. It has to be either ff or rebase: if you ever got your local repo with local changes followed by a merge from the remote branch you wouldn't be able to push it (except by doing force push that overwrites the remote branch) because the branches have to end up with identical history not just identical content.
I'm also a big fan of using rebases when pulling. You can use the option like you mentioned here or you can set it globally with `git config --global pull.rebase true`. It makes it so nice to pull all the changes that other people have merged in and not have extra merge commits lying around. Kind of related, but I also love to use interactive rebases to clean up my commit history before merging my branch in. If I'm just coding away I might just do a `git commit -m "current progress"`. I can do this whenever I think it's right (although I'm pretty bad at committing frequently) and then when I want to merge I can use `git rebase -i ` to fixup my commits and squash it all into one meaningful commit with a descriptive message. I should note that if you have pushed any of your changes to the remote and you do a local rebase you need to do a `git push -f`. I'm fine doing this when I'm on my own development branch that doesn't affect anyone else but it can be spooky the first few times you do it. Git is still black magic to me but it's fun being able to bend it to my will some of the time
@@Toxic_Zed If you want to clean up a really messy commit history there's an easy way to reduce any complex branch down to a single commit. I usually prefer to keep the history but it's useful for example if you're doing a PR to an open-source project and just want the cleaned up PR to have a single commit and not any dead-end you followed first. First just make sure all your changes are committed and the branch is up to date against main then do 'git reset main'. Now you just threw away your entire branch history but all your changes are sitting on disk uncommitted. Do git add and git commit (or git commit -a) and your branch has a single commit with your changes.
I always forget rebasing when pulling is a thing. I tend not to need it that much, but at the very least you can rebase after the fact. Some cool solutions to the problem here though!
One situation I might do a `git fetch` rather than a `git pull` would be if I knew there were changes in both the local repo and the remote. The default for `git pull` is ff-only and that will fail if there are changes in both repos so I would do the `git fetch` that would let me review the changes before merging so I can see if there will be any problems. After reviewing I can do a manual rebase or just `git pull --rebase` which means my local repo will then have the remote changes followed by my changes.
It has to be either ff or rebase: if you ever got your local repo with local changes followed by a merge from the remote branch you wouldn't be able to push it (except by doing force push that overwrites the remote branch) because the branches have to end up with identical history not just identical content.
I'm also a big fan of using rebases when pulling. You can use the option like you mentioned here or you can set it globally with `git config --global pull.rebase true`. It makes it so nice to pull all the changes that other people have merged in and not have extra merge commits lying around.
Kind of related, but I also love to use interactive rebases to clean up my commit history before merging my branch in. If I'm just coding away I might just do a `git commit -m "current progress"`. I can do this whenever I think it's right (although I'm pretty bad at committing frequently) and then when I want to merge I can use `git rebase -i ` to fixup my commits and squash it all into one meaningful commit with a descriptive message. I should note that if you have pushed any of your changes to the remote and you do a local rebase you need to do a `git push -f`. I'm fine doing this when I'm on my own development branch that doesn't affect anyone else but it can be spooky the first few times you do it.
Git is still black magic to me but it's fun being able to bend it to my will some of the time
@@Toxic_Zed If you want to clean up a really messy commit history there's an easy way to reduce any complex branch down to a single commit. I usually prefer to keep the history but it's useful for example if you're doing a PR to an open-source project and just want the cleaned up PR to have a single commit and not any dead-end you followed first. First just make sure all your changes are committed and the branch is up to date against main then do 'git reset main'. Now you just threw away your entire branch history but all your changes are sitting on disk uncommitted. Do git add and git commit (or git commit -a) and your branch has a single commit with your changes.
I always forget rebasing when pulling is a thing. I tend not to need it that much, but at the very least you can rebase after the fact. Some cool solutions to the problem here though!