I don't, and I don't recommend it. However git pull seems to match other version control systems more closely.
This causes a familiarity where your objective is to bring remote changes into your working tree. But git has local branches, so you first need to update your local branch and then merge that into your other branch.
As you point out, this line of thinking is actually less efficient than updating your local database followed by a merge.
But that brings me to the other confusion, when do you use a space vs a slash. Clearly you use a space when naming a remote, but that isn't clear.
$ git merge origin develop
I want to merge the develop branch on origin. This seems logical, but the command does not operate on a remote, if I switch the command to pull it works as desired.
Introducing the idea that the entire remote repository is locally available is yet another topic to cover.
There are really only two operations that you can do with the remote repository, push your local database and pull their remote database. All other operations occur against the local database.
But the pull command creates confusion as I should have said fetch instead oy pull even though without all the git lingo you'd expect the same thing.
Don't even get me started on why github has you create "pull requests" when you are wanting them to merge in your changes.
I don't, and I don't recommend it. However git pull seems to match other version control systems more closely.
This causes a familiarity where your objective is to bring remote changes into your working tree. But git has local branches, so you first need to update your local branch and then merge that into your other branch.
As you point out, this line of thinking is actually less efficient than updating your local database followed by a merge.
But that brings me to the other confusion, when do you use a space vs a slash. Clearly you use a space when naming a remote, but that isn't clear.
$ git merge origin develop
I want to merge the develop branch on origin. This seems logical, but the command does not operate on a remote, if I switch the command to
pullit works as desired.Introducing the idea that the entire remote repository is locally available is yet another topic to cover.
There are really only two operations that you can do with the remote repository, push your local database and pull their remote database. All other operations occur against the local database.
But the pull command creates confusion as I should have said
fetchinstead oy pull even though without all the git lingo you'd expect the same thing.Don't even get me started on why github has you create "pull requests" when you are wanting them to merge in your changes.
Cheatsheet for Git Rebase
Jesse Phillips ・ Apr 17 ・ 1 min read
Nice overview. Yes, the 'git pull' workflow is something I see very often, without a good reason to invest the extra time for the pull.
Your workflow example also isn't the most optimal one could
git pull origin <branch>I understand one wouldn't do this as it does not update you local copy of the branch. My view on that is of course different.
Delete Your Master
Jesse Phillips ・ Apr 8 '19 ・ 1 min read
That's why I alias
git pull origin mastertogpom.Yeah that is useless for me as I
git fetch origingit rebase origin/masterWhatever works for you.
git pull --rebase origin masterWould actually do what I do. So many options.