Pushing Changes to a Remote [Learn Git Video Course]

Learn how you push your changes to the remote server. We will also take a closer look at what exactly tracking connections are. This video is part of our free 24-part video course on Learning Git on the Command Line.

***************************************

Additional Git tutorials and resources

***************************************

Welcome to our video series on learning version control with Git. 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 decided that 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. We need a special form of the 'git push' command - but only for this first time.

First, we make sure we're on the right branch.

With "git checkout feature/news", we make this our HEAD branch.
With the "git push" command, we'll now publish it. We add the "u" flag, because we want to track that new remote branch. Such a "tracking connection" establishes a 1-to-1 relationship between the local and the remote branch.
Then, we tell Git to which remote repository we want to push - and how to name that new branch. We deliberately choose the same name as its local counterpart.

With "git branch" we check what this did. The "a" flag also shows us remote branches - and here it is: our new "origin/feature/news" branch. The 2 v's in that command make sure that we also see the tracking connections.

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

Let's push this new commit, too. Before I do, I'll call "git status" once more.

And I'm glad I set up this tracking connection with "git push -u". Because here, git status tells me that my branch is one commit ahead - which reminds me that I haven't pushed this commit to its remote counterpart branch.

Now, to actually push these changes, I only have to call a simple "git push". Thanks to that tracking connection, Git already knows where to push this branch. I don't have to use any further arguments.

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.

In that case, you'll have to integrate those changes into your local repository _first_...

And then push again.

SUBSCRIBE to learn more about Git, Tower, and how to become a better developer!

For more free ebooks, cheat sheets, and video tutorials make sure to check out our FREE learning platform!

STAY UP-TO-DATE:

#git #learngit #gittutorial