Lots of companies go to great effort to make website development straightforward for the average user. This makes sense, because there are site owners who don’t have (or want) the time to learn every aspect of running a local site. However, with a bit of research, you can use Git to handle the process of pushing your site live. This gives you a little more security, and once you set everything up, an easier path for making site changes.
Even so, getting to that point is admittedly tough. There are lots of prerequisites to consider, skills you need to have, and tools to hand. Also, you’ll need to think through the process the first few times, because there is a lot to remember. However, using Git to push a site live is possible for almost every user, and it doesn’t have to be as complicated as you think.
For this tutorial, we’re going to show you step by step how to use Git to push a local site to a live server. First, let’s run over some of the tools and technologies we’ll feature in the post.
An Introduction to Git
For the unaware, Git is a Version Control System (VCS). It’s a way to save and record the changes you make on a project – often a app or a website. It’s something we touch on elsewhere, but you’ll need to know more about it for this tutorial.
The typical way to use Git is through a Command Line Interface (CLI) – if you have experience with the WP-CLI, it’s a similar approach. You’ll use commands to mark and organize the files you work on in a number of ways:
- Before you issue commands, files will stay ‘unstaged’. This means they are not part of your Git ‘repository’ (the directory that stores your history).
- You’ll issue a command to stage all or some of your files, at which point you can still work on them.
- When you finish, you commit the files to the ‘repo’ from the staging area. This is akin to saving those changes.
It can be more complicated than this, but for the most part you’ll use only a handful of commands to carry out day-to-day work with Git.
Using Git for Team-Based Development
Git is a key tool for development teams, because each developer will open a different ‘branch’ within the same repo. This means everyone can work on the project without affecting the files for others. At regular intervals – often as the last task of the day – the team will commit changes to the repo.
A senior member of the team will then look to ‘merge’ all of the branches and changes together to the main or trunk of the repo. At this point, you’ll have the definitive set of project files within the repo.
For a single developer – likely you – Git still has value as a kind of incremental saving tool. You’ll open a new branch, work on your site, then stage and commit those changes. It means you can do whatever you like on the branch without affecting any other file on your site. When you want
[…]
This article was written by Tom Rankin and originally published on WPKube.