Although most tutorials will have you use Git for version control, they can’t possibly go into as much detail as you’d like. Before last week, my Git knowledge was this: git add, git commit, git push. Github has taken the lead in being the repository (repo) of choice for most people/companies. It’s what we use at my current gig. If you’re just starting out and learning how to program, chances are, you aren’t working with a whole lot of people…if any at all. So you haven’t had the opportunity to use Git to its fullest potential.
I’ll be honest, I felt like a complete idiot when I first started pushing code to production. My worst nightmare: pushing code to the main code base and breaking everything. That or accidentally deleting the entire repo. I’ve heard of many SQL commands that omit just a few words or added some accidentally and taking down entire applications worldwide. I definitely didn’t want to do that. But when my manager asked me if I knew how to create a branch or make sure how to get the latest changes that people have committed, I had no clue. So hopefully this will help anyone who’s reading. Here are a few commands I use often and my general workflow with Git:
- git checkout -b <name>
Example: git checkout -b fix-scrolling-bug
Before working on any issue/feature/bug, you’ll want to create a branch. Some teams use branching differently, but generally, you’d have a branch for the one specific piece of work you’re doing. This helps keeps things concise and will help collaborators understand what your branch is trying to do. So try to name it so people will know what the code is doing. Or, simply put the issue number on it (more on that in a later post). If you’re just working on minor bugs and enhancements, sometimes it might make more sense to have a generic branch that you can push to that you’ll use all the time. More than likely, you’ll never want to be directly on the master branch.
- git status
This let’s you see what your current status is. If you’ve made any modifications to your code and it differs from the repo, you can see what files have changed. You can also see what you’ve added to be committed. So depending on when you run this command, you’ll either see red (modified files that haven’t been added) or green (modified files that have been). I like running this command before I add and after just to make sure I’m committing what I want.
- git diff or git diff <path>
Example: git diff app/controllers/users_controller.rb
I like using this when I’m not quite exactly sure what I’ve changed, especially if I’ve touched many different files. Almost all the time, I’ll forget what I’ve done, so I’ll want to compare my files to what’s in the repo. If I only want to see the changes for a specific file, I can add the file path to the end of the command. I use this frequently throughout my development. I’ll usually use this right after I do a git pull too (mentioned below).
- git pull origin master
This will pull whatever changes have been committed by others in the master branch. It’ll sync up your code so that when you’re ready to push to the repo, you’ll have the most up to date code. This is an important step because anytime you push your code, you want to make sure you have all the changes up to that point. It’ll make merging your code to the master branch a lot easier. Plus, you can take a look at whether or not someone has edited code where you’re doing your work. So if you changed something and then someone else changed that exact same line, you’ll have conflicts that you’ll need to resolve, which basically means you’ll need to either fix more of your code or talk to that other person to see who’s code remains. Important command here.
- git add
Basic command. Prepare the files you’ve changed to be committed. Make sure you do this before you do a commit or a push.
- git commit -m “<your message here>”
You’ll almost always want to add a message to your commit. It’s normally just what you’ve fixed. Don’t be too descriptive, just make it a one-sentence line. Chances are, it’s tied to an issue/ticket tracking number (ex: JIRA). Doesn’t hurt to append that number at the end.
- git push
Everyone should know this command. This actually pushes your code changes to the repo. If you’re on a specific branch, you’ll be pushing this to that one branch. This is another reason why it’s a good thing to be on a branch versus the master. Even if you push code here that breaks, you won’t be affecting the main code base. Someone will be able to review your code before they merge it in with master.
- git stash or git stash save “<name>”
Example: git stash save “work for scrolling bug”
This is another command that I highly recommend you use. As a developer, it’s common you’ll be asked to switch gears at the drop of a pin. Chances are, you’ll be right in the middle of something. You’re not quite done with it and it’s too incomplete to commit. That’s when stashing becomes the best option. Running this command will take all of your changes and put it in a stash. It’ll revert all your code back to what it was before. Whenever I stash, I normally like to run a pull too so I have the latest changes before stashing. Or, I want to test original functionality. So I’ll stash my code, test how the app originally worked, and the reapply my changes to test how my code makes it work now. This is a great command.
- git log
This is one that I don’t use too often. This is probably more for the person who has to manager the repo, but nonetheless, it can become handy. It’ll give you an audit of all the changes to the repo. You can see who committed code in what branches, when. It’s good when you need to do some detective work to see when changes were made.
There are a ton more commands and even more options you can append to them. Personally, these the most common ones that I use. I haven’t done a whole lot of merging since that’s normally done by the person managing the repo, but I think these will give you a pretty good head start. I know I wish I knew these before going in to a development shop. There are also plenty of free tools to make this process a little easier, like giving you a gui so you can visually see what’s going on (ex: SourceTree by Atlassian). Most hardcore developers will just work straight through the terminal, but if you’re coming from an Eclipse or RubyMine world, having a gui like SourceTree might ease the transition.
Just a final note: if you want to keep your code private, use BitBucket. It’s just another git-based repo. You can have unlimited repos for free and not display your code to the entire world.