If you aren't using source control yet, then I hope this article convinces you to start today. Maybe git's learning curve has put you off, and now you just archive and email files amongst team members, or maybe you're even still using FTP. When you learn to use git effectively you can super charge your development workflow.
Whatever your reasoning, you should use version control today!
In this article I will cover some basic and powerful git commands. Armed with these commands, you should be able to comfortably navigate a repository, and understand exactly what is happening.
If you are reading this article, then I assume you already have some form of git installed.
Use Git Effectively for a Better Workflow
Git is just one form of source control, and is one of the most widely used. Source control tracks all changes made to all files included in a repository. Each change can be committed (or added to the repositories history) or simply discarded. Each commit can also be reverted to its previous state. That means if you made a code update, and your new widget suddenly stops working, you can checkout a previous commit and see what changed.
You'll get the hang of it pretty quickly so let's jump right in!
Basic git commands
Alright, so you've got your command line fired up, your git installed, now what?
One of the most common uses of git is to grab some code that someone else has written. Let's say you found a great little plugin that you'd like to use for your website on Github.com. You can use the git clone command to download the entire repository directly to your machine.
git clone https://github.com/some/awesome/widget.git
This will create a directory on your machine named after the repository. You can also specify a location after the URL to clone to a specific directory.
git clone https://github.com/some/awesome/widget.git .
The above command will clone the repository into your current directory.
Now you can access this directory and see the plugin source code. You also have access to the entire version history since this is a complete git repository. This can come in handy if a recent update broke something and you'd like to view previous versions of the code to see what happened.
Whether you've cloned an existing repository or started a fresh one, there will come a time when you have made some changes you would like to keep. A git commit will 'commit' your changes to the source history. This is the biggest part of using git effectively. Commit often, and use a descriptive message to indicate what you changed. This will make it much easier when you sift through the history later.
git add . --all git commit -m "commit message"
The first command tells git which files to track for changes. By default, files are 'untracked' meaning git will not keep track of changes made to these files. The '.' indicates the current directory, and the --all parameter tells git to begin tracking all files. After tracking the files, the changes can be committed along with a brief message indicating what exactly was changed.
There may come a time when a developer updates their code on Github. You'll want access to these changes to keep your local source up to date. In this case the git pull command is used.
This command contacts the repository URL (the one you used when cloning) and checks if there are any updates. If there are, these updates are downloaded.
Let's say you've been working hard all day, and just put the finishing touches on your plugin. Now it is time to push your code up to the repository server, whether that is Github.com, your own company Git, or just a repository hosted by your friend.
This command will contact the Git URL and add your local commits to the repositories commit history. Now if someone else pulls or clones the repository they will see your changes.
At some point you will have a few commits, and you'll want to take a look around your repository. Or maybe you've made some changes that you aren't happy with and you just want to get rid of them. The git checkout command is a versatile command that gives you powerful control of your repository.
Checking out a branch
Lets say you've been working on a feature in a separate branch and you are ready to go back to the master branch.
git checkout [branch name]
The above command will 'checkout' that branch, and all code in your directory will match the state of the branch you selected. If you have uncommitted changes in your current branch, git will notify you, and not continue with the checkout.
The checkout command includes a handy parameter when you just want to discard your changes. This parameter forces git to discard the changes and proceed with the checkout.
git checkout -f
Running the checkout -f command without a branch will discard changes made in the current branch, without switching to a different branch.
Checking out a commit
Remember when I said the checkout command is versatile? You can also supply a commit hash to checkout. The same -f parameter applies here too.
git checkout [commit hash]
Sometimes it might be nice to see exactly what has changed in the code since you've started working. Git does a very nice job of keeping track of all this, and even includes a handy diff tool, git diff. Git diff will compare two commits, two files, or pretty much anything else, and show you the exact differences. This is perfect for those instances where you had something working perfectly, and now it doesn't. Git diff can show you exactly which lines differ allowing you to find the problem much more effectively.
git diff [commit hash] [commit hash]
If you are already using some form of source control, it is my hope that this article will help you understand how to use git effectively. If you have not made the switch, then hopefully this article makes a strong case for why you should use git.
Source control provides an effective means for tracking and managing changes to source code for projects large and small. Understanding how to use git effectively the first step to adopting its use. With these basic commands in hand you can begin to practice and integrate source control into your workflow.
Still feeling unsure about source control? Leave a comment below!