When learning Git for the first time, all the terminology can get confusing pretty quickly. Thankfully, not all of it is necessary in order to have a solid understanding of Git. There is this 80/20 relationship when it comes to git, you only need to know 20% of Git, to utilize 80% of it’s potential. In this blog I will cover the crucial 20% of Gits terminology and at the end, provide a handy .pdf to summarize the information.
Version Control
Starting at the beginning, what is version control? Version control is used to control resources, traditionally software, that is being worked on by multiple people. It allows you to control access, versioning, editing, and deployment. It is very useful for tracking changes over time, because let’s face it, we make mistakes.
Git
So where does Git fit into all this? Git is a version control system. “Git is an open source program for tracking changes in text files. It was written by the author of the Linux operating system, and is the core technology that GitHub, the social and user interface, is built on top of.”. Git is a very common VCS, and as such has a large array of documentation and resources. Something to note is that git is very flexible. This means you have freedom to screw up.
Pull
So what is pulling in Git? “Pull refers to when you are fetching in changes and merging them. For instance, if someone has edited the remote file you’re both working on, you’ll want to pull in those changes to your local copy so that it’s up to date.”. In layman’s terms, you’re pulling the changes someone has made to a file to your local machine, so you can view and maybe edit those changes.
Push
Pushing is the opposite of pulling. Before you can pull someones changes, they first need to push them. This is because your computers don’t communicate with one another, but rather something called a remote sits in the middle. “Pushing refers to sending your committed changes to a remote repository, such as a repository hosted on GitHub. For instance, if you change something locally, you’d want to then push those changes so that others may access them.”
Commit
Commit what? Commit a crime? Committing in Git is the term used to commit to making a change. Don’t worry you can un-commit if you want to. Before you can push a change to the remote, you need to tell Git what files you actually want to push, ad why you’re pushing them. You do the latter with a commit message. “A commit, or “revision”, is an individual change to a file (or set of files). It’s like when you save a file, except with Git, every time you save it creates a unique ID (a.k.a. the “SHA” or “hash”) that allows you to keep record of what changes were made when and by who. Commits usually contain a commit message which is a brief description of what changes were made.”
Head
When talking to people who have experience with Git, you’ll likely hear the word Head. Each branch in Git has a Head. This is the most recent commit, which means the Head is constantly changing. There is a lot more to head, but that is a simplification.
“A named reference to the commit at the tip of a branch. Heads are stored in a file in $GIT_DIR/refs/heads/ directory, except when using packed refs.”
“The current branch. In more detail: Your working tree is normally derived from the state of the tree referred to by HEAD. HEAD is a reference to one of the heads in your repository, except when using a detached HEAD, in which case it directly references an arbitrary commit.”
Branch
Branches are used to get a copy of a project for you to work on, generally alone and undisturbed. You can makes branches of branches too. This is the key functionality that GitFlow governs. “A branch is a parallel version of a repository. It is contained within the repository, but does not affect the primary or master branch allowing you to work freely without disrupting the “live” version. When you’ve made the changes you want to make, you can merge your branch back into the master branch to publish your changes.”
Origin
Like Head, this is a term that you will come across quite quickly. It is even sometimes used in Git commands like pushing.
“The default upstream repository. Most projects have at least one upstream project which they track. By default origin is used for that purpose. New upstream updates will be fetched into remote-tracking branches named origin/name-of-upstream-branch, which you can see using git branch -r.”
Repo
Git Flow
“GitFlow is a branching model for Git, created by Vincent Driessen. It has attracted a lot of attention because it is very well suited to collaboration and scaling the development team.”. Git flow is a set of guidlines and ideas that, if followed, result is a scalable and robust project structure and process.
Remote
“This is the version of something that is hosted on a server, most likely GitHub. It can be connected to local clones so that changes can be synced.”. This is the part of the project structure that connects everyone together. It sits on a server like GitHub, BitBucket, etc. and is where changes are pulled from and pushed to. There will also likely be a GUI component on the website belonging to the server host.
Fork
“A fork is a personal copy of another user’s repository that lives on your account. Forks allow you to freely make changes to a project without affecting the original. Forks remain attached to the original, allowing you to submit a pull request to the original’s author to update with your changes. You can also keep your fork up to date by pulling in updates from the original.”. Essentially, forks are branches of entire projects.
Upstream
Fetch
Rebase
Master
“The default development branch. Whenever you create a Git repository, a branch named “master” is created, and becomes the active branch. In most cases, this contains the local development, though that is purely by convention and is not required.”
Keywords Cheat Sheet Git – Download
From hard data to fluid design – Scott