Most computer science students have at least heard of Git and GitHub. However, if you’re anything like I was, that’s as familiar as you are with this tool. Let’s see if I can help by starting with the basics:
Git is one of the largest version control tools for software development. It can be used by an individual for a side project or by a group as a collaboration tool. Either way, this tracking system tool, keeps versions and configurations of a software project organized.
GitHub is a code hosting platform that uses Git. By which, multiple members of an organization can access the remotely hosted code on their local machines. This facilitates collaboration by allowing for local changes to the main code base to be visible remotely after being approved.
Imagine that you and a friend are writing a research paper together. If each of you write your portion on a physical piece of paper, in your own homes, then even the simplest change on either of your parts will take a lot of effort to be reflected in the final work. As new research is done, grammatical errors are found and progress is made, endless in-person meet ups are made necessary. But what if you each wrote to a Word Document on your respective local machines and then uploaded those changes to the same Google Doc? Because the paper is hosted remotely by Google, you’re then still able to do your individual work and merge it with the final draft when needed. This is the exact problem that GitHub solves, but for software projects.
Git, used by GitHub and other hosting platforms like Bitbucket, is the man behind the curtain. Git helps keep up with all versions of your project and all the versions of the code that exist between you and your teammates (called branches). The former function is similar to ‘ctrl-z’ in a Word Document, you can always revert back to a previous version of your code by using the appropriate commands.
Secondly, Git allows teammates to have their own local versions of the code in isolation from other’s updates and edits. After getting a copy of the remote repository from GitHub (or wherever the code is hosted) and storing such on your local machine, a developer has the ability to start working on their part of the project. But in order to prevent any current work from overwriting anyone else’s, individuals should branch off from the main code base, or master branch. A branch contains all the code that the master branch does at the time it’s created. Any changes made to the branch you are working on, is only reflected there, until merged with the master branch. This is great because your coworkers, classmates or whoever has access to the overall project (stored as a repository on GitHub), can update their own local version, then safely and quickly merge it with the original, main code. With Git, work can easily be divided among the team, changes can be tracked and undone, and work can be completed from anywhere in the world.
As mentioned, a repository holds all of the code, but also any other important documents like configuration files and READMEs (a markdown document with information about the project). This directory can be public or private, local and remote, and is only accessible by the allowed parties. All of the branches of the code base are also tracked in a repository.
Because other collaborators are constantly adding and refactoring code, you want to make sure your local environment reflects these changes before working on your own. If you’ve already cloned the remote repository onto your machine, pull any changes from the remote repository to your local repository. Now create a branch, work on your changes, then add them from your working directory to the staging area. When you’re ready to have these changes reflected on your branch, in your local repository, commit them. Finally, push your branch’s recent commit to the remote repository. When you’re ready to have the master branch reflect your branch’s work, you can merge such in the form of a pull request (PR). If your request to pull your commit from your branch to the master is approved, the master branch code base will then reflect this change. And that’s it!
Basic Workflow Git Commands to Know
cd localWorkingDirectory (change to your working directory)
git pull (pull any new code from remote repository into your local repository)
git checkout -b branchName (create a new branch and switch to it)
make changes to code on your new branch
git add fileYouChangedOrAdded (files are added to staging are)
git commit -m “Describe what you did in present tense” (takes changes from staging area to commit)
(repeat above until satisfied with work)
git push branchName (local branch changes are pushed to remote branch)
git merge branchName (from branch to master branch)
Other Helpful Git Commands
git clone remoteRepositoryURL (clones remote repository to your current directory)
git status (tells you the current file changes)
git log -n count (lists a log of branches last n commits)
git diff fileName (shows changes between working directory and staging area)
git reset fileName (resets to previous working state)
git stash (put current working directory changes in stash for later use)
git stash pop (apply stash to current working directory and clear stash)
git stash drop (delete a stash)
git branch (to see all local branches)
git checkout branchName (switches to branch)
git -d branchName (deletes branch)
git remote -v (to see bookmarked remote repositories)