The life of a developer is full of choices. The industry moves so quickly that there’s always some new tool to try or an updated best practice to incorporate. It’s impossible to pick the best overall framework or the most efficient workflow because different tools lend themselves better to different projects. That being said, there are certainly a few things that absolutely every developer should be comfortable with. Version control is one of those things. Don’t believe me? Check out our guide to preparing for a bootcamp!
When I think back to the very first websites I built as a kid, a chill runs down my spine. Hours upon hours of work could be completely lost if the power went out or I hit the wrong keys. Even if my site worked exactly the way I wanted it to, I’d have to save more than one copy if I ever wanted to go back to a previous version. (My file names got very creative!) This strategy for managing the different versions of my sites felt clumsy and wrong, but it wasn’t until much later that I was introduced to the concept of version control.
Now, I use a pair of tools every day to preserve snapshots of my code. Git is an open source version control system. It’s what keeps track of every single change to my code. GitHub, on the other hand, is a social platform that hosts projects that use Git as their version control system. Using Git and GitHub together makes it incredibly easy for people all over the world to collaborate!
There are a few different “states” a file can be in when the project uses Git. Don’t worry if the following list is difficult to understand at first. It will become more and more clear as you use Git in your projects.
- untracked: Git knows the file exists, but is not tracking changes.
- tracked: Git is now intimately familiar with the file. It will know if you change anything.
- changed: You changed something! In order to save those changes, you’ll need to add the file to the staging area.
- staged: The file is ready to be saved as part of a commit, or snapshot of the code.
- committed: You’ve committed changes and now the file is really just back to the “tracked” state!
There are a ton of things that Git can do to help manage a project. There’s also more than one way to interact with Git itself. GUIs (graphical user interfaces) exist that allow the user to point and click their way through version control. Honestly, though, it’s worth the time and effort to learn to use the command line. Mac users can open up their Terminal and Windows users their Command Prompt. (Keep an eye out for a friendly intro to the command line!) The following commands are the most important for beginners to know and understand:
- git init: Create a Git repository (container for code) in the current folder.
- git clone: Copy a project into the current folder. (This will be followed by a URL leading to said project.)
- git status: Check the status of the project. (This is my favorite!! Check your status often.)
- git add: Add files to the staging area.
- git commit -m: Take a snapshot of the code including the changes made to staged files. (The “-m” is for “message”. Follow this command with a brief message in quotes that explains what you changed.)
- git push: Tell your remote repository (in our case, one that’s hosted on GitHub) about all the changes.
- git pull: Incorporate any changes that have been made to the remote repository into the one on your computer.