Master: git push

---

In this video we'll learn some short hands and additional scenarios for git push.

In init: git push we covered the most common usage of git push by passing the remote name followed by the branch name.

Let's take a closer look at these arguments to understand how we might be able to use some shorthands.

If we have to pass git push the name of the branch, this means we'll need to type a different git push command for each branch.

It be nice if we could just type the same command for each branch.

If we think about our common use case, we're usually pushing the latest work on our branch.

As we learned in Part 3, HEAD also references the top most commit on a branch.

We can demonstrate this by running git log --online --decorate to see that HEAD and our branch reference the same commit.

So, we can run:

git push origin HEAD

So, we can use HEAD as a way to keep the git push command consistent across different branches.

While it's nice to be consistent, we really haven't shortened the command.

Even if we don't pass the branch name to git push, Git will attempt to use the current branch.

By default, so long as this branch name matches a branch name on the remote, this will work.

Let's try this by just running:

git push origin

This command fails because Git can't match the local branch name with origin.

It provides a command we can run to set what's called the tracking branch.

So, we'll use the suggested command, or we could also use the -u option for git push.

This will automatically set the tracking branch to the one I'm pushing too.

Now if we run: git push origin it works.

Furthermore, if you don't specify a remote name, git push will use origin by default.

So, if we run:

git push

We see from the output Git pushed our current branch to the origin remote.

So while prefer being explicit by running git push origin HEAD, you can often simply run git push.

Sometimes you may want to push your local branch to a remote branch with a different name.

You can do so by passing the remote branch name immediately after the local branch name, separated by a colon.

Let's demonstrate this by pushing our current local branch to a different remote branch named new-branch.

I'll do so by running:

git push origin register:new–branch

Or

git push origin HEAD:new–branch

From the output we see that new-branch was created and we also see it on GitHub.

You can also delete a remote branch with git push.

The syntax is similar to the previous command except we don't pass a local branch name.

So, to delete new-branch, we would run:

git push origin :new–branch

From the output we see that the branch was deleted and we also see it was removed on GitHub.

This is a bit of syntactic sugar, but if we think about it we didn't specify a local branch name. Or, said another way, we pushed nothing to a remote branch which removes it.

There's one last scenario to cover, which is force push.

There will be times when your local branch gets behind the remote branch. For example, if someone else has pushed work to the same remote branch while you were working.

To simulate this, let's push the register branch to a new remote branch called force-push.

Then I'll create a local force-push branch from master, by running:

git checkout -b force-push master

If I run git log --oneline --decorate --all we'll see my local force-push branch is behind the register branch.

This creates the scenario where our local branch is behind the remote branch.

So if we were to run:

git push origin head

We'll see the push fails. The output states our local branch is behind the remote branch and if we want to push our changes we can use the -f or force option.

So let's run:

git push –f origin head

We see from the output now we have force pushed our changes and if we look on GitHub its commit history now matches master.

By force pushing, we overwrote the commit history. This means we lost the commit from the register branch.

If you force push your work you are effectively overwriting the remote history with your local history.

Doing so may not only lose work, but make it difficult for others to push their work as their branches will no longer match the remote branch. In turn, they will receive the same error and may also force push creating a vicious cycle.

I once heard someone say that -f option stands for "fuck your team". While explicit, it does relay the seriousness of using this option.

So while there are times it's necessary to force push, its a good idea to reconfirm your intentions and notify others after doing so.