Some of the developers I have worked with on smaller projects have never used Git (shocking, I know), and I always end up having to give them a very basic tutorial just to help them get up to speed.
Since I’ve already done it more than a couple of times, I thought I [...]
Some of the developers I have worked with on smaller projects have never used Git (shocking, I know), and I always end up having to give them a very basic tutorial just to help them get up to speed.
Since I’ve already done it more than a couple of times, I thought I should write a post about the absolute minimum every developer should be aware of when starting to use git to collaborate with other developer(s) on a software development project.
Note: I prefer using git from the command line. Most linux distributions should come with git pre-installed. If you don’t have it or you’re on a mac, you can download it from the official git downloads page. If you’re on windows, you can use mysysGit, which comes with bash. (Secret: if you’ve always missed bash on Windows, this can replace cmd.exe for most command-line work)
First, you should know how to clone a repository. Most of the times, if the repository is hosted on a hosting service like GitHub or Bitbucket, this consists of copying and pasting one git command from the website, like in the screenshot I took from bitbucket below:
Now, you should have the files for your project in the directory you cloned your repository.
Then, once you’ve worked on your project (i.e. added/modified/removed files), you can do:
git add -A
which basically tells git “hey, I’ve modified stuff and I want you to know about them”.
Then you can commit your changes as:
git commit -m "message"
where ”message” is a little note describing what you’ve changed.
After this step, you want to pull for any new changes that may have been made. This is important, and is often forgotten by beginners. Between the last time you cloned/pulled from a remote repository, there may have been changed committed to the files by another member of your team, and you want to get those changes and deal with any conflicts at this step. I thought this tutorial had a great discussion on handling merge conflicts in Git.
After you’ve taken care of any merge conflicts you may have had, it’s push time. This is as easy as
git push origin master
which tells git now that you know what I changed (using git add -A) and how I described what I did (using git commit -m “message”), I want you to take my changes and send it to the remote server where everything is hosted.
This, in my opinion, is the bare minimum that every developer should know about git. While what I’ve described is in no way comprehensive, it should be enough to get started on a project that’s using Git for source control.
Once you feel comfortable with all this, I recommend you check out some tutorials available online. If you like videos, O’Reilly has a great one hour video tutorial on Git. If you like traditional books, the Git Community Book is probably the most authoritative, comprehensive and up-to-date guide, and it’s available for free (I had their chapter on branching and merging bookmarked for many months when I was first learning this stuff).
I also have a printed copy of this Git Cheat Sheet on my desk, and I find myself frequently looking up stuff at Everyday GIT with 20 Commands Or So. I also found the Git Workflow essay by Benjamin Sandofsky a good introduction to basic workflow.
Update: The Git Basics Tutorial by CodeForAmerica/Skillshares is really good for beginners as well.


