Let’s walk through an overview of how to use the Git version control system and Github to manage your software’s development lifecycle.
This is meant to be a readable introduction to Git for the new user, as well as a reference to the common commands and procedures, not an exhaustive document of all there is to know about the Git version control system.
For an exhaustive guide, I’d like to recommend you to read Pro Git and Gitref. They provide a wealth of detail about all the Git commands I’ll be going through in this brief overview, and I strongly encourage you to go beyond this post if you are considering to work with Git in the long term.
Let’s start with an overview of most frequently used git commands:
And an overview of a basic git workflow:
- You initialize a new git repository for your project
- You write some code
git addthe modified files (You add snapshots of modified files to your staging area.)
git commityour completed feature/chunk of work
git pullto update your local codebase with other people’s changes
- Resolve conflicts and
git merge, integrating your teammates’ code with yours
git pushto your remote repository to share your changes with everyone in your team
- Go back to step 2
Having signed up for a Github account, setup git, and initialized your git repository with
git init, you can start by making changes to your code and add the files you want to include in your commit with git add:
Then, we can commit all our added files, using the -a and -m flags to automatically stage all tracked, modified files and add an inline commit message respectively:
A git commit affects only your repository and is not visible to anyone else until you push those commits with git push. Once your code changes have been pushed to the remote repository, other developers can do a git pull and retrieve those changes into their local repositories.
When working on your own, it’s useful to commit “early and often,” so that you can explore different ideas and make changes freely without worrying about recovering earlier work. It’s also important to never commit broken/partially finished code. (Something I need to take to heart myself.)
Prior to pushing your changes, it’s best to do a
git pull if you are working with other developers, as their changes might conflict with yours:
Set git pull –rebase as a default! This avoids an extra commit during the merge step, which annoys some developers. To set it as a default, do
git config --global pull.rebase true
Having pull use the
—rebase flag eliminates unnecessary merge commits which provides no helpful information and pollutes the git commit history. This is also the step where you resolve merge conflicts.
Once you are ready to share your code changes into the remote repository, do a
And you have just pushed your code! You can also see the list of everyone’s changes to the repository with
git status and
In this post, I’ve outlined how to use the most often used git commands to help you get started with
git, but I highly recommend that you go beyond this post and learn both the fundamental concepts of Git as a version control system, but also other commands such as
rebase, and so on. For that, I recommend Pro Git and Gitref.
You should read my other post on how to use git aliases to streamline your git workflow: Useful git aliases in ~/.gitconfig
Thanks for reading! Now, go ahead and
Git Along with other developers!
📬 Get updates straight to your inbox!
Subscribe to my newsletter to make sure you don't miss anything.