Hacker News Reader

Comment by rleigh | Hacker News Reader

I rarely use "git pull". Why would you?

More typically, I will "git fetch origin" to fetch the current integration branches, then "git checkout -b <feature branch> origin/master" to start a new feature branch from a given integration branch, then push that once the change is completed.

If I need to update a local copy of an integration branch, then I might well use "git pull". But I would never have any local changes made there which would require stashing, since all changes are done on feature branches.

View on HN

I use git pull pretty frequently. I like to keep my main branch up to date with the main branch of the remote repo. I find it's helpful to have that consistency across contexts.

I think diffs are faster if it's to the local repo vs the remote repo.

I always make branches off local-main, as opposed to remote main as in your example.

I think it's also helpful to have the main branch replicated across as many machines as possible. There have been one or two times where a dev has deleted remote main at my company where some (very VERY CALM) git push solved the problem. I probably could have checked out a tracking branch and fixed it that way, but having a local copy of main made it a one-step process (I think the resolution was just to git push the main branch?).

There are few differences between "local" and "remote" main in GP's example. "origin/master" is a _local_ copy of the origin's master branch, and updated with every "git fetch". So "git push origin origin/master:master" resolves the "remote master was deleted" without having to stash/checkout/etc.

It's just a preference thing. If I'm sitting down to write a new feature I can do the git fetch origin and go directly to a branch, but if I'm investigating an issue, I'll often open that develop/master branch directly, find the problem, do a pull to make sure there are no changes that got checked in, then "git checkout -b".

Alternately if I'm helping other developers, I'm on their branch a lot, and it basically becomes a "push your changes and I'll take a look" and I just open that folder and git pull.

I think I use more git pull now than I did originally, because I'm working on less of my own code.

I basically never use git pull. I use git fetch and then I check (using git diff, git log or in confusing cases gitk) what I want to do. That could be merge (fast forward), rebase, ignore or either branch because the other one is just better. Of course often pull might do what you want, but when it doesn't people start to complain. So better avoiding surprises from the beginning.

It sounds like you finish your work much faster than I do. I usually go for the same workflow as you do, but it can take days between a branch being created and the moment I'm done with it. During this time, I often want to keep up with the latest changes on master. Other times, more than one person works on a feature branch, so they still need to git pull from origin/feature-branch into feature-branch to get the changes from the other committer.

I would be very happy if I could just merge to master every day, but that is extremely rare for me and my team.

No, I don't necessarily work any faster. But I will switch between multiple feature branches as necessary. And to keep up with master, I'll rebase my feature branch onto origin/master or depending upon the circumstance I'll directly merge origin/master. Both keep me up-to-date without a direct pull.

Well, if you're switching branches, you already have problems with a dirty worktree. Also, pulling can actually mean rebasing (I always use pull --rebase).

I've worked at a few places where CI will automatically merge main back into open feature branches (or at least open PRs). It's quite nice.

Reply on news.ycombinator.com