Tag: push

How to: Work with remotes in Git (Part VI)

How to: Work with remotes in Git (Part VI)

As described much earlier, Git is a distributed version control system and each machine that taps into it holds the entire history of all repositories. All that information is stored inside .git folders in the root directory of projects. This is already helpful as you can run git locally and maintain your own repositories.

Well, it gets even better once you get to share those repositories with any number of your split personalities and better yet, store them safely on your backup remote location. In short, a remote is much like a regular repository and is usually initialized as a bare repository.

Only difference is that it really doesn’t contain and actual project files and it can be accessed by any number of people who have access to it and act as a central hub that other repositories sync data to and from.

git remote

This command will be used to create, rename, delete and basically manage a set of tracked repositories. There’s not all that much to it. Here’s how you add a remote repository to your already existing local one:

git remote add origin ssh://<user>@<server>/srv/git/repo.git

Supposedly, you can add any number of remotes to a repository, but I’ve never tried it and therefore I’m not a fan of it and all my independent remotes are conventionally called origin.

Again, for all the information on the matter, check the man pages – I’m only giving you the bare minimum important can’t-live-without stuff.

git pull

Not too much interesting information on pulls, except that it is generally considered wise to do them often in order to prevent merge conflicts, earthquakes, tsunamis, alien invasions and other catastrophes. Pull your sh*t together:

git pull

or

git pull <repository> <refspec>

Pull your shit together

A command that incorporates changes from a remote repository into your current branch. It is widely recommended to do one before any push.

There would actually be some background stuff to know about pulls: for instance, git pull is actually a shorthand for git fetch, followed by a git merge FETCH_HEAD. Yeah… bet you didn’t know about that, now did you?

But, when ran with the --rebase option, it actually uses git rebase instead of git merge. I’m not gonna get into more detail because at this point, I’m not sure how viable rebases really are, at least not in the context of the workflow I have in mind, which is inspired by a source that shall only be revealed once I write my post on it (and remember where it came from).

git push

Pushing is one of the most important part during your second stage of labor, but also the operation you’ll find yourself repeating over and over again once you go remote.

Typically, when working with remotes you would still make changes to your local working copy, commit them, make some more changes and then at some point you will want to push them to the remote repository, so that they’re both in sync so to say.

Push

git push

Well, this is all fun and painless until new branches come along or the contractions grow stronger.

On a side note, I’m sorry if this section is harder to read – it’s just that push sounds ridiculously like something you’d read about in a guide on how to manage labor pains or something – and now you know why I’ll never have an Android category on my blog.

Anyway, of course you could probably just branch out of your main tree locally and work there, but what if this is more of a persistent branch for a major feature or a general development branch that other people need access to as well? As the proud founder of the branch, you get to set an upstream remote branch:

git push --set-upstream origin <new-branch-name>

or, for short:

git push -u origin <new-branch-name>

That creates a new branch on the origin remote repository and sets your local branch to track it. Tracking is that thing that tells you how many commits behind or ahead is your local branch as compared to the remote one, whenever you switch to it, fetch from the remote or check the status.

I almost forgot, as of Git 2.0 the push command’s default mode changes from matching to simple, so you might get some annoying message every time you push. To discard it for now, wait until your cervix is fully dilated, then pick a mode you’d like to set as default and do it:

git config --global push.default simple

This only affects the behavior of using the command without any extra arguments. I’m going with simple because I’m a somewhat of a control freak, but here’s the long story short about the differences between those two:

  • matching mode will push all your local branches to their matching ones on the remote
  • simple mode will only push your currently active branch to the repository

For occasional matching pushes you can try the --all option, I dare you, I double dare you:

git push --all

It might also be useful to know how to delete a remote branch, for any number of reasons. We have a few different situations depending on whether you’re the one deleting a remote branch or the one who was working locally on his own copy and someone else deleted the upstream remote branch.

So, if you’re deleting the branch, do it properly. First delete your local branch (make sure you merge it into another one if it’s necessary).

git branch -D <branch-to-delete>

Then, remove the remote branch:

git push origin --delete <branch-to-delete>

I do this every once in a while to at least piss off some people who sometimes seem to just deliberately cause merge conflicts. Anyway, here’s what you can do if you ever find yourself in their shoes (willingly or not):

If you were just about to push some commits, but just as you were doing a overcautious fetch / pull right before of it, you realized your refs were gone, you can still make the push and the remote branch will be reborn, OR you can discard your own branch.

However, if your own local branch was clean (i.e. no pending commits) and its remote counterpart gone, it’s probably a sign you should also get rid of your own. But this is SPARTA, so if you would like, you could keep working on your local branch independently from the once prosperous remote one, but for that you first need to prune some refs:

Double check your assumptions first, before considering anything and do a dry run:

git remote show origin
git remote prune -n origin

Whenever you’re ready, you can run the prune command without the --dry-run or -n option and that will unset the upstream.

git remote prune origin

Congratulations, you are now a rogue developer! You are also on your own, with no one to help you out, or hear you scream for that matter. However, many things can happen to a stealth branch in time: it can change its name, can silently track the changes on the main branches and eventually come back mysteriously with some seriously valuable code that would make you employee of the year, or someone’s bitch in jail, even if only for one night… Either way, here’s a quote you might find useful, it’s from an older post on How to make a Git server:

This will get you a reputation and / or a night in jail so be ready for both. For more tips on moronic behavior, follow my guide on How To: Make A Rep In Jail In The First 12 Hours.

Advertisements