More Productive Git

Re:More Productive Git by olvy0 on Friday May 24, 2019 @03:51PM (#20004747)

Yes, that has been my experience as well. Starting a new repo that has a remote tracking branch has been a source of constant frustration for me. I routinely mess up some incantation and then have no idea how to fix it. The mental overload is high enough with local branches, but I still don't quite follow what it means to have a tracking branch, it seems to complicate the nice and simple mental picture I have of the local repo as a DAG.

[ Parent | on HN ]

Re:More Productive Git by js2 on Friday May 24, 2019 @06:42PM (#20005936)

When you fetch from a remote repo, the state of the branches in that repo has to be recorded somewhere locally in your repo. That’s what remote tracking branches are. So if the remote called origin has a branch called master, and you fetch, git downloads the commits you don’t have and then updates .git/refs/remotes/origin/master to the commit ID of whatever master is on origin.

That’s all it is.

Basically you have a DAG just like you think. But git needs some way to label some of the nodes in that DAG. It calls those labels “references” or refs, it records them under .git/refs/, and there’s basically just three kinds: local branches (refs/heads/<branch_name>), tags (refs/tags/<tag_name>) and remote tracking branches (refs/remotes/<remote_name>/<branch_name>). There’s also the reflog which is a change log of the local branch refs, and a special log for HEAD which keeps track as you switch which branch is currently checked out.

Note: if you start poking around under .git (and you should in a toy repo!), you might not find exactly these files. For performance reasons, git sometimes combines the refs into a single file called packed-refs.

[ Parent | on HN ]

Re:More Productive Git by atq2119 on Friday May 24, 2019 @06:44PM (#20005951)

A concrete example would be interesting.

The only thing you really need to internalize is that all git operations are entirely local on your machine, except clone/fetch/pull/push.

(Another useful thing to internalize is that git pull is really just git fetch followed by git merge. git fetch is the part that involves network activity, while git merge is entirely local on your machine. I can't remember the last time I've used git pull, actually...)

So when you're doing git log origin/master, you're not looking at the current state of the master branch on a remote machine. Instead, you're looking at what the state was the last time you did a fetch/pull/push.

This is extremely useful for being able to work remotely.

[ Parent | on HN ]