The 8 most essential Git commands

This time last year I could taste blood in my mouth, my front teeth felt loose, and I was so angry I had just been kicked in the face by a donkey whose feet I was trimming. It happened so fast it took me a couple seconds to really understand what had happened.

Well it's been over 5 months since the last time I have touched a horse. I no longer make my living shoeing horses. Over the past 5 1/2 months as a junior developer I have learned 8 Git commands that have saved my butt countless times and that I deem absolutely essential especially starting out as a new developer in the field. The first rule of development is just like in medicine: "First do no harm".

There are basic git commands, like 'git push' 'git commit' and stuff like that, but these 8 rules while simple are the keys to becoming trustworthy and responsible to not screw anything up on your development team.

1- 'git status'

I used to "sometimes" check what I was committing, when working on my own projects. Now after working on a development team I ALWAYS 200% of the time do a 'git status' or 'git st' as I have it for short on my machine. I then do a...

2- 'git diff' or use the GUI 'gitx'

I know some "purist" developers would never consider using ANY sort of GUI but I have to say using 'gitx' from the command line has helped me SO much to make darn sure of exactly what I am committing. Without 'gitx' installed, the next best thing is to type 'git diff '. I think it's personally a little harder to read, 'git diff ' will show you what was changed in the files about to be committed.

3- 'git log'

Now don't jump the gun, we still are not ready to commit anything yet, one last step I like to do is to check the log, just to make sure that I am paying attention and know exactly what branch I am on and what has been committed before, I do a quick 'git log', if every think looks fine and I am sure that I am on the right branch, then I go to...

4- 'git add  filename'  WITHOUT the ' . '

Yes it's fun to just do 'git add . ' which then adds EVERYTHING all the files at once. A much safer way is to manually do a 'git add filename' it's the same thing, just you have to type in each file name as you add them to git. I think for me that it helps me to establish good healthy work flow patterns so that I am less likely to make a mistake when under pressure or stressed. I will have a good mentally strong git work flow.

5- 'git commit --amend'

You then of course do a 'git commit -m "my first commit" ' but what is really cool and helpful as long as you are working on your own branch and haven't released your work to any other developers is to use: 'git commit --amend' after making your first commit to a project. It basically just keeps stuffing each commit into the next one so that you don't have a lot of different commits for small tweaks to files or in tweaking a CSS rule or something. The more important less routine the work, the less I will use 'git commit --amend' but otherwise a really handy command to know.

6- 'git reset HEAD-1' or 'git reset HEAD^'
If even after being as careful as possible you do add a file or something you didn't mean to, you can simply undo the last commit you did by either doing: 'git reset HEAD~1' or if you prefer 'git reset HEAD^'. This command is worth a million dollars when you are brand new and make a mistake as all new young developers will, not an excuse for not be careful, but definitely a git command life raft.

7- 'git branch -d  branch name'

When deleting lots of branches in my case usually 10 - 15 branches every week, I ALWAYS use the lower case '-d' versus the '-D' to check if the branch can be safely deleted. It's basically a built in git safety, use it.

8- 'git rebase -i HEAD~4'

I never thought I'd care about how many commits it took to complete a task or project. I thought as long as it was done and worked correctly, that was good enough. Well actually no, when working on a code base with thousands and thousands of commits, development teams like to keep commits as clean and meaningful as possible. Which means if you took eight commits to do something that should have taken one then you will need to interactively 'squash' your commits and then re push your work back up to git as one nicely formatted commit. Pretty complicated the first time you do it but it's really too hard once you get used to it. Something you should probably practice on your own project the first few times. Take a look at interactive rebasing and don't be scared.

Keep coding!