In the last installment of the Learning git series we took a look at how to start using git to version code. Now that we know how to commit our code, we need to know how to share it, or at least back it up. This is where the remote command comes into play with git.
In general, a remote is literally a remote from your current machine. You can set it up a few different ways, but I’ll cover the central repository pattern here. With that pattern you can think of a remote as just a big cloud data store -it’s more than that, but let’s move on for now.
Wait a minute… I thought that we were only discussing the remote command, what’s this push nonsense?
Well, push is how you will get your code up to the remote. Most user interfaces have a push button. If you’re feeling the command line today cd into the directory and type the following:
Either way with the command or the button as long as the remote is set up your code and its commits will zip off.
Oh good, back on topic… a remote is simple a remote computer somewhere that can accept your code pushs. For this series we are using the central pattern, which simply means a server that manages repos. You can either host your own or use a service. Here are a few to get you started:
- Bitbucket : I use them for private projects
- github : I use them for open source projects
- gitlab : I haven’t tried them, but many people seem to like them
Regardless to the service that you use you’ll need to set it up. Luckily this is a one time thing and it’s painless. Different user interfaces do it different ways, but from command line you can type the following:
git remote add [shortname typically 'origin'] [your url]
You might get prompted for a username or password depending with the remote service, but you can work through that.
Yes - another non-remote command that has a lot to with it. This command simply asks git to connect to the remote and return the changes that it might have that you don’t know about.
Again in git user interfaces there are quite a few different ways / buttons to do this we’ll resort to the command line for an example.
This will true up your code with the remote, and sometimes will result in a conflict if git cannot automatically merge the code. We will cover that in a later post - for now while you are learning git on your own repository, you should not need to worry about it.
Putting it all together
Thus far in our git series covered many of go to commands and you should now be able to start using git with your code backed up a remote repository. Just to give you a big picture on how everything relates to each other here’s a high level picture.
If you stopped here you’d be able to use git by yourself, but would still be missing a lot of its power. In the next post in the series we will cover branches - what they are good for and how to use them. If you missed any of the prior articles in the series check them out below, the list will also update as posts are added to the series.
Links to the other posts in the Learning git series
- Intro to git - Part 1
- The git cycle
- Setting up git
- Initializing git
- What's a remote in git
- git branches simply explained
- git Merges Demystified
- How to use git flow
- git stash and pop
Always follow the manufacturers instructions, this write up is simply the way that I do it, and it may or may not be the right way. Use your common sense when applying products to or altering your stuff and always wear the appropriate safety gear.