Git is a Version Control System (VCS) that helps us track the changes in a file - or a group of files - over time. Much like Google Docs, this allows multiple people to contribute to a document, and to have a timeline of the changes that are made. This is especially important in coding, seeing as finding the genesis of bugs, or seeing how features have developed over time in critical to good, functional code.
Git can be used locally on your home/work computer to track changes in your personal directories, or, with something called GitHub (a web application that hosts Git repositories (a repository is simply a Git-enabled web-hosted directory)), you can track, change, and collaberate on the web, from anywhere.
There is a method to the GitHub maddness, and - to be honest - the learning curve for understaning Git/GitHub's protocols is steep; but once you learn how and why the workflow is the way it is, and once you give it a little practice, you will pretty quickly and smoothy begin working within the Git/GitHub world.
As mentioned above, there is a specific order and protocol that is required for things to move effortlessly in GitHub. This is called the GitHub Workflow. The GitHub Workflow is designed to smoothly intergrate and track changes that are made to repositories over time. This workflow is important because it is often not simply you that is working on a singular project, but instead, possibly dozens or hundreds of people working on dozens or hundreds of shared documents. Below is an image to function as a reference for the next section:
There are a number of specific ordered steps required to successfully manage your GitHub updates which I will describe below. These are taken directly from the GitHub website, so these are certainly worth taking the time to analyze and understand.
- When you're working on a project, you're going to have a bunch of different features or ideas in progress at any given time – some of which are ready to go, and others which are not. Branching exists to help you manage this workflow.
- When you create a branch in your project, you're creating an environment where you can try out new ideas. Changes you make on a branch don't affect the master branch, so you're free to experiment and commit changes, safe in the knowledge that your branch won't be merged until it's ready to be reviewed by someone you're collaborating with.
- Once your branch has been created, it's time to start making changes. Whenever you add, edit, or delete a file, you're making a commit, and adding them to your branch. This process of adding commits keeps track of your progress as you work on a feature branch.
- Commits also create a transparent history of your work that others can follow to understand what you've done and why. Each commit has an associated commit message, which is a description explaining why a particular change was made. Furthermore, each commit is considered a separate unit of change. This lets you roll back changes if a bug is found, or if you decide to head in a different direction.
- Pull Requests initiate discussion about your commits. Because they're tightly integrated with the underlying Git repository, anyone can see exactly what changes would be merged if they accept your request.
- You can open a Pull Request at any point during the development process: when you have little or no code but want to share some screenshots or general ideas, when you're stuck and need help or advice, or when you're ready for someone to review your work. By using GitHub's @mention system in your Pull Request message, you can ask for feedback from specific people or teams, whether they're down the hall or ten time zones away.
- Once a Pull Request has been opened, the person or team reviewing your changes may have questions or comments. Perhaps the coding style doesn't match project guidelines, the change is missing unit tests, or maybe everything looks great and props are in order. Pull Requests are designed to encourage and capture this type of conversation.
- You can also continue to push to your branch in light of discussion and feedback about your commits. If someone comments that you forgot to do something or if there is a bug in the code, you can fix it in your branch and push up the change. GitHub will show your new commits and any additional feedback you may receive in the unified Pull Request view.
- With GitHub, you can deploy from a branch for final testing in production before merging to master.
- Once your pull request has been reviewed and the branch passes your tests, you can deploy your changes to verify them in production. If your branch causes issues, you can roll it back by deploying the existing master into production.
- Now that your changes have been verified in production, it is time to merge your code into the master branch.
- Once merged, Pull Requests preserve a record of the historical changes to your code. Because they're searchable, they let anyone go back in time to understand why and how a decision was made.
- Author#1 and Author#2 are both local, in disperate geographic locations.
- Author#1 creates Project#1 on home PC.
- Author#1 initiates a local git repository.
- Author#1 writes a handful of code in abcdefg.html. For example:
<!DOCTYPE html> <html> <head> <title>This is some code...</title> </head> <body> </body> </html> - Author#1 adds abcdefg.html to the local staging area.
- Author#1 commits edits locally.
- Author#1 pushes commits to the GitHub (or a similar online client) repo.
- Author#1 invites Author#2 to collaborate on Project#1 - authentication and access control would be managed by GitHub (or a similar online client).
- Author#2 would pull Project#1 from GitHub (or a similar online client) repo.
- Author#2 would make changes locally. For example: Author#2 adds this change to the
<body>:<p>This is some new code</p> - Author#2 would add changes locally (version controled by git locally).
- Author#2 would commit changes locally.
- Author#2 would make a pull request to Author#1.
- Author#1/Author#2 conduct code review.
- Author#1 would pull changes, merging the code.
- Rinse.
- Repeat.
Git (and GitHub) makes sharing code between a number of different computers and developers almost seemless, and is used by thousands of companies, developer teams, and coding schools.