Pushing Changes to a Remote

In the last few videos, we’ve already talked a bit about the theory behind exchanging data. Today, we’ll push new local changes in your local repository to the remote.

Let’s start with some important things to know.

First, always keep in mind that your local branches are private to you when you create them. Therefore, you have to decide yourself if and when you want to publish any of them.

Second, when we’re talking about pushing and pulling data, we always refer to branches - not individual commits. You don’t push or pull individual commits in Git. You push or pull all new commits in a certain branch.

And third, the source and target when pushing or pulling. For example, when we push changes, we never have to think long about what is pushed: you always push the new commits of your current HEAD branch. The only thing you might have to think about is where you push it to. But more about this later.

Let’s get our hands dirty.

Let’s say we want to start sharing our local “feature/news” branch. We haven’t pushed it before, so we have to explicitly publish it on our remote. This is exactly the same process as in our last video. So let’s quickly do this again.

We drag our local “feature/news” branch and drop it onto the “origin” remote item.

Tower already prefills the input fields for us, but let’s check this quickly. We want to publish our local “feature/news” branch - on the remote called “origin” - and want that new branch on the remote to have the same name.

Make sure the “track” option is active - because such a “tracking connection” establishes a nice 1-to-1 relationship between the local and the remote branch.

As soon as this is finished, the new remote branch appears here in the sidebar.

Now, I’ve prepared some more changes - I add them to the staging area, and produce a new commit.

Before I push this new commit, I’d like to draw your attention to this badge here in the sidebar. With our new commit, a little “1” appeared in here. Let’s wait for the tooltip…

It tells me that my local branch is “1 commit ahead”. With that “tracking connection” set up, Tower will tell me both if there are new commits that I haven’t downloaded yet; and if I have local commits that I haven’t uploaded to the remote yet.

I can even see this in the history view.

Unpushed or unpulled commits are marked with a little arrow in the top right corner.

Now, to actually push these changes, I only have to click the Push button in the toolbar. Thanks to that tracking connection, Tower already knows where to push this branch. The correct target branch is already selected.

Note that the little “1” has disappeared. We’ve uploaded our local-only commits and kind of synced the branches.

There’s one special situation: If one of your teammates also pushes to this branch, it might be that your own push fails. This is because Git warns you when there are changes on the remote that you haven’t integrated, yet. Also, Tower informs you about unpulled commits in the sidebar.

In that case, you’ll have to integrate those changes into your local repository first and then push again.

This is it for today. See you soon in our next video!