Inspecting Remote Data
When adding a remote repository, Tower also performs a "Fetch" command automatically for us. This command updates the information about a remote.
Concept
Remote Data is a Snapshot
Git stores information about remote data (like branches, commits, etc.) in your local repository for you. However, there is no "live" connection to your remote. This means that, with Git on the command line, you would not automatically see new commits or branches that your teammates published on a remote - because you have to explicitly tell Git to update! The information about remote branches, remote commits, etc. is only as fresh as the last snapshot that you requested.
Tower, however, performs a "Fetch" automatically for you in the background in fixed intervals. Therefore, you'll rarely have to execute a "Fetch" manually.
Fetch will not touch any of your local branches or the files in your working copy. It just downloads data from the specified remote and makes it visible for you. You can decide later if you want to integrate new changes into your local project.
Creating a Local Branch from a Remote Branch
Let's start working on that remote "faq-content" branch. Currently, however, this is only a remote branch pointer. To be able to work with this branch - to have our working copy populated with its files - we need to create a new local branch that's based on this remote branch.
To do this in Tower, you can simply drag the respective remote branch and drop it onto the "BRANCHES" section header in the sidebar.
When we do this, a couple of things happen in the background:
- (a) A new local branch is created with the same name as the remote one ("faq-content").
- (b) The new branch is checked out, i.e. it's made our local HEAD branch. At the same time, our working copy is populated with the associated files from that branch's latest revision.
- (c) By the way, we're establishing a so-called "tracking relationship" between the new local branch and the remote branch it's based on.
Concept
Tracking Branches
In general, branches have nothing to do with each other. However, a local branch can be set up to "track" a remote branch. Git will then inform you if one branch contains new commits that the other one doesn't have:
- If your local branch contains commits that haven't been published / pushed to the remote repository, your local branch is "ahead" of its remote counterpart branch by some commits.
- If your teammates, on their part, have uploaded commits to the remote, the remote branch will have commits that you haven't downloaded / pulled to your local branch, yet. Your local branch is then "behind" its remote counterpart branch.
In case such a tracking relationship exists, Tower will inform you about any commit that haven't been pushed or pulled, yet:
When creating a new local branch that is based on an existing remote branch, establishing a tracking connection is easy: either create the branch via drag and drop (dragging the remote base branch and dropping it onto the "BRANCHES" section header in the sidebar) or by right-clicking the remote branch and choosing the "Track <branch name>..." option.
Now, simply double-click our new local "faq-content" branch to check it out - and we're ready to contribute to this feature. Let's make some modifications to the "faq.html" file that you now have on your disk (I leave the details of these changes to your imagination...). Then, please stage the changes (by ticking the checkbox next to the file in the "Working Copy" view) and commit it with a short message.
Pushing Your Work to a Remote Repository
Now it's time to share these brilliant changes we've just made with our colleagues. In Tower, simply click the "Push" button in the toolbar:
Note
On your machine, this "push" command will not work because you don't have write access to our course remote repository. If you want to follow along and execute this command yourself, I recommend you create your own remote repository, for example on GitHub or Beanstalk.
When you confirm the dialog with the "Push" button, Git uploads all the new commits from our current HEAD branch to its remote counterpart branch.
Concept
Tracking Connections Revisited
By default, the "push" command expects us to provide it with two things:
- (a) To which remote repository we want to push.
- (b) To which branch on that remote repository we want to push.
With the tracking connection that we've set up already, we've defined a "remote counterpart" branch for our local branch. Tower can then use this tracking information to preselect the correct target in the dialog's "Destination" selector.
