GIT: Pushing and Pulling

Now that we have set up our repositories to talk to each other, let's look at pushing and pulling changes between them. Consider that we will be working on a database feature.

Push Command

Create a branch called data_feature and a file of your choosing and commit it. We want to show off our new feature to our partner, but they don't have our changes on their local machine yet.

The easiest way to do this is to push our changes to the remote repository: $ git push

Wow. That's a big error message. To summarize:

• matching means git push will push all your local branches to the ones with the same name on the remote. This makes it easy to accidentally push a branch you didn't intend to.
• simple means git push will push only the current branch to the one that git pull would pull from, and also checks that their names match. This is a more intuitive behavior, which is why the default is getting changed to this.

This setting only affects the behavior of your local client, and can be overridden by explicitly specifying which branches you want to push on the command line. Other clients can have different settings, it only affects what happens when you don't specify which branches you want to push.

So let's set out push.default to the new way by typing:

$ git config --global push.default simple

Before we go ahead, remember that our new branch doesn't exist in our remote repository yet. We need to explicitly ask Git to track changes to this new branch by providing the branch name to the push command.

By default, the first argument to $ git push must be the name of a remote. If you don't provide one, Git automatically assumes that you are talking about the origin. Go on and type $ git push origin data_feature

Ah! A success message. Finally. Go to your awesome_project and check if the branch has been created. Good, it's all there. While you are on the origin, checkout the new branch, edit the file and commit it. Now head back and make a few more changes to the same file (yes, we know this is confusing, but we promise it's all worth it). Now try pushing the changes.

Uh-oh. An error. Looks like we aren't up-to-date with the changes in the remote so we can't push. So how do we update ourselves with the changes in the remote?

Pull Command

As you might have guessed, as there is a $ git push command, there is a $ git pull command. The syntax is pretty similar to the push command. We say we want to pull, we specify what remote we want to pull from, and also what branch we want to get the history for.

Git tries to pull that information over and oh, right. In both repositories we made edits to the same file, and git has no idea how to fix it. It works very similar to a merge, except that it merges changes from two repositories. Recall merge conflicts? Well we have one here.

Go ahead and resolve the conflict (you know that pretty well now). Add the file to the staging area and commit it. Our git pull should be complete by now, so trying pushing again. Everything works fine now.

This was all about pushing from our clone to the origin and pulling from the origin to our clone. What about the other way around? Let's head back to our awesome_project, make an edit and commit it. Run $ git push and uh-oh.

An ugly error message. Something about a no configured push location. In most of your interactions with remote repositories, you will be pushing and pulling changes from your origin. In this case, we created this repository on our own and that's why we need to specify the destination where we want to push to. Ah all is well.

Once you get some practice you'll be doing this pretty easily. Next we'll learn about the most popular hosting service for repositories, GitHub.