There are times when this is useful, but what if you want to track the remote one directly instead of having to pull through a local copy? What we have here is experimental tracking master, and not origin/master in other words, it's a local branch tracking another local branch. doing in here? Well, that's a special short hand meaning this repository, much like it means this directory in filesystem access. We can flag it as tracked using the -track option of git checkout (or its shorter -t alias):ĭeleted branch experimental (was 4a3fa88). What if we wanted to set up our experimental branch? If we just do git checkout -b experimental, it won't be tracked: Any pulls that happen on master will result in a merge (or rebase) from refs/heads/master. The way to read this is that master is a local branch, which tracks refs/heads/master on the remote origin. git/config file, since it lists what its remote is and where to merge from: In fact, all a tracked branch is is one that's explicitly mentioned in the. So, how do you set up a branch for tracking? Well, when you check out a branch from a remote master, it gets set up automatically. This is useful if you have a long-running UAT branch which needs to be refreshed periodically from a moving target setting it up as a tracked branch means that the only thing you need to do is git pull, and you're up to date. This means you can fetch and pull, as if you were pulling from a remote repository, and consume changes from the ongoing branch moves. Instead, you can set up your experimental branch to track another one. You either need to pull changes through master and then rebase, or remember where your merge point was. However, what if you wanted to spin off another branch for experimental purposes, and keep that updated? If you do git checkout -b experimental, it diverges from your local master at that point in time. Any changes you pull into your master come (by default) from EGit's master. If you check out EGit, you'll get a master branch that tracks refs/remotes/egit/master (or origin if you didn't specify a default repository identifier). Normally, branches checked out of a remote repository are automatically set up as tracking branches. As well as the branche(es) that will be affected by a fetch/pull/push, tracking says which branch is upstream of which. However, each branch also has the concept of what it is tracking. You can also use the reference HEAD to refer to the commit that the current branch is on as a source for the refspec, which can be useful for pushes. And whilst you can't have partial wildcards (like refs/for/qa*) you can have sub paths (like refs/for/qa/*). This is normally of the form refs/heads/master:refs/remotes/origin/master, where refs/heads are the pointers to your local branches, and refs/remotes are the remote branches.Īn optional + prefix on fetch refspecs indicates whether or not to fetch non fast-forward commits automatically.
This is the set of branches that will be updated if you interact with that repository. You can specify what the refspec is when interacting with a remote repository. For remote repositories, this will default to origin if not specified (In fact, remotes can have a second URL one is used for fetching, whilst the other is used for pushing – this is used to permit anonymous fetches but authenticated pushes.) You need to specify, when fetching and pulling, what repository you're talking about. Each remote is a name of a repository on a remote end, which corresponds to a URL and a refspec. Both of these reach out to the remote repository and get content that you're interested in, with the git pull variant doing either a merge or a rebase as appropriate.īut how does Git know what to pull when you invoke git pull? Where should it pull it from? What makes a branch you have checked out locally differ from one you have pulled from a remote repository?įirstly, a (local) git repository can have many remotes.
#Git create branch tracking remote update#
When you initially use Git, you learn that to update items from master involves a git pull (or git fetch). Last week I wrote about the behaviour of pulling tracked branches this week, it's worth taking a dive in to find out what a tracked branch is.
You can subscribe to the feed if you want to receive new instalments automatically. This week's Git Tip of the Week is about configuring what happens when you pull.
0 kommentar(er)
