At my first internship, nobody told me about their version control system (which was significantly more painful than using Git is anyways). Inevitably, something went wrong one day and I lost a lot of work. I used my own rudimentary version control after that, making copies of my code in 10 different places and naming the copies things like "finally working version 03-24-13". When I finally started using a different version control system and later Git, I wished I could go back in time and save myself all the time and head banging that not a proper VCS caused.
However if you're mostly just using
git commit -m and
git add and basic branching, you are missing out on some of the commands that make git especially useful. One thing I won't mention here is interactive rebasing * which I will write a later blog post on.
Here are a few git commands that I wish I had used sooner than later.
git commit -p(
git add -pis similar but only adds the files instead of commiting them): proof read your commits first!
- if you have ever worked on a codebase with a lot of files (or even if you haven't) there have probably been times you accidentally edited a file you didn't mean to
- whether it was acidentally adding a space or a typo to a file or a leftover
debuggeror an embarassing comment/note to yourself, there are sometimes things you would rather not add to the public repository
git commit -amor
git add .or other similar commands are dangerous because you have no idea what the changed files contain. Sure, you can do a
git difffirst but that's an additional step to remember and amending your commit once it is pushed is not a great idea since it rewrites history
git commit -pshows you each change you have made and asks you whether it should actually add them to the commit change list. If you indicate no, the changes are preserved but just not committed
I personally use
git commit -pfor the following reasons: a) to make sure I am only committing things I actually intend to commit b) to help me split a huge amount of changes into smaller commits and c) when I change multiple parts of a file but only want to commit a few of those changes (instead of the whole file)
git commit -p you get a nice summary of each change and are asked whether you want to include it in the commit. Here is an example:
While it takes a bit longer to initially commit (since you are looking at each change),
git commit -p will definitely save you from lots of revisions, mistakes, and ultimately save you time. It is the only way I commit most of the time and has been super helpful.
git reset HEAD^ : Undo your last commit
- While I still use
git stash quite a bit to store changes to files that I want to temporarily store away and not be part of my code (often when switching branches), I find that it can be hard to manage all your stashes and remember what is going on (even if you use use
git stash save to specify a description for the stash)
git reset HEAD^ removes the most recent commit but still keeps all of the changes it has made. This is great when you want to edit or add to the previous commit or when the commit is a "temporary" work in progress commit that you are just storing temporarily
My use case for this is either when I have made a bunch of changes that I intend to break up later into smaller commits or when I want to have a temporary stopping point to come back to. I have an alias,
g undo for this which makes it super easy for me to remember. If you want to "undo" multiple commits, you can do
git reset HEAD^2 or
git reset HEAD~2 ( here is a great resource on the difference between those two)
git stash: copying and pasting your file changes
- I have this bad habit of sometimes starting to make changes on the wrong branch. - I also often make changes to a branch and then need to switch branches but don't want to commit my changes just yet (lately I have been using the
git reset^HEAD for this particular thing however).
- Sometimes, I also go down a particular path and realize it may be the wrong one and need to start over but don't want to lose all my changes in case I need them in the future.
git stash is perfect for all of these situations. It basically takes all of your changes and "cuts" them and stores them away. Later on, you can use
git stash apply or
git stash pop to "paste" the changes back into your code (the latter deletes the stored changes from storage after "pasting" them while the former keeps them around. I almost always use
git stash pop since once you paste the changes, you either will stash them again or commit them and there is no reason to keep them stored).
The problem with just
git stash is that it can be hard to figure out which stash contains what changes. I personally always use
git stash save (description) to give my stashes a description I can later read and understand. When you do
git stash list, you are shown a list of all the stashes you currently have stored including any descriptions you included Normally,
git stash pop (and apply) default to the last stash (the most recent one) but you can also specify which one you would like to pop/apply/show (show tells you which files were changed). I have the aliases
git stash) and
git stash save) since I use these super often.
Here are some slides from a talk on Git that I gave to students at Hackbright Academy
The above are just a few of a bunch of Git commands that I use constantly. Becoming more familiar with git (and having a ton of aliases) has made my life a whole lot easier and also helped avoid a lot of mistakes.
Feel free to email me if you have any questions. Thank you for reading!