This post is for people who have used git before, but aren’t really sure what they can do besides push/pull. If you have never used version control, I would definitely recommend git! Here is a simple NetTuts tutorial for getting set up.
I frequently hear people say they “don’t use git, but should,” or “haven’t had time to learn it yet.” Like me, they are intimidated by git. Though I have been “using” it for about two years, I have always been uneasy around git. Here’s why:
- I didn’t know how to do anything but push and pull
- I hated merge conflicts
- I panicked when I had broken code in my local repo, but needed to pull down someone else’s changes
- I had no idea how to quit for the night with unfinished code
Here is everything I used to know about git and git workflow:
git pull git add . git commit -m 'some message' git push origin master
meanwhile, squeezing my eyes shut and praying for no conflicts (lest the dreaded VIM editor open). I even used to try to work on files no one else was working on, just to avoid a conflict. Crazy, right?
Why Use Git?
I used to think git was nothing more than a “version history”; useful just in case code needed to be rolled back to a working copy (which is just so wrong).
I’m not going to get too crazy here, because many have written on this topic. However, here are my reasons for using git:
- Collaborate without accidentally overwriting someone’s changes
- Keep track of who wrote what (i.e. git blame)
- Use branches to work on features
- Support multiple versions of a codebase
- Cool deployment options
- Version history, so you can roll back if necessary
Alright let’s get into some things you can do with git, besides pushing and pulling.
Scenario 1: You Are Adding a Feature Which Will Take Several Days to Finish
You don’t want to be committing changes to the master branch as you work, because your partially-finished code will break the main codebase.
This is a great use case for a branch! Making a branch is like making a clone of the current codebase, wherein you can go crazy with changes without affecting your clean master branch. Then when you are happy with your changes, you can merge the temporary branch back into master. Alternatively, if you decide to scrap the idea of the new feature, you can simply delete the branch and forget it ever happened
There are a couple ways to make a branch. This first one is a little more tedious:
git branch myNewBranchName git checkout myNewBranchName
In general, you will use checkout to switch between branches. You can achieve the same thing with the following one-line command:
git checkout -b myNewBranchName
Now that you are working from this new branch, you can commit changes without fear. When you are done with your new feature, you can use the following commands to resync your code:
//switch back to master and make sure it is utd with remote origin git checkout master git pull //merge the new branch into master and push to remote origin git merge myNewBranchName git push origin master //delete the no-longer-necessary branch: git branch -d myNewBranchName
Scenario 2: Something Urgent Interrupts You
You are happily writing code in your local repo when an urgent or quick-fix bug is sprung on you. You need to stop what you’re doing immediately and handle the problem. You don’t want to lose all your work, but you also don’t want to commit broken code.
Another situation for branches! If you aren’t already working in a non-master branch, create one (I like to call it ‘hold’) and switch to it. Your changes will follow you there, and once you commit from this new branch, those changes will only be associated with that branch.
git checkout -b hold git add . git commit -m 'Working on x. Commit needs rebasing'
Next, you can switch back to master and do a clean pull. Then create a new branch where you can work peacefully.
git checkout master git pull //move to a second branch called quickfix git checkout -b quickfix
Once you’ve fixed the bug, commit your changes, merge back into master, and push your changes live, like we did in Scenario 1. Don’t forget to delete the no-longer-necesary branch.
When your master branch is once again clean, switch into your ‘hold’ branch, and continue working. If your commit was especially bad, you can finish what you were doing, commmit, and then rebase the two most recent commits together. (Rebasing is essentially squashing two commits into one).
git checkout hold //do some work git add . git commit -m 'Describe your changes' git rebase -i HEAD~2
At this point you will be taken to VIM and asked to delete one of the commit messages. Once you do that, you can switch back into master, and do a git merge hold.
Scenario 3: You are Looking through the Codebase, and Find Some Code You Don’t Understand
No matter how many times you read through the code, you just can’t understand what it’s doing.
Do a git blame on that sucker! Then you can go straight to the source and ask the author to explain it to you.
git blame index.php // or whatever your filename is
This will open the file in your terminal and display line-by-line, who last edited that line. Below, you can see that a user named m1ck3y is responsible for the second-to-last line of this file:
Other Things to Know About Git
Git has plenty of other commands and uses (such as deployment), and you can find tutorials and Git Cheat Sheets all over the web. I definitely recommend bookmarking a good cheat sheet or making your own.
Here are a few resources I like:
Using Git for Deployment
Pretty Git Log
Git Cheat Sheet with Examples
Exhaustive Git Cheat Sheet
Colored Output, Shortcut Commands, Autocompletion, and Bash Prompt
Feel free to share your favorite resources!