Git is one of the most confusing things a newbie developer will encounter. Its overwhelming and the information you find out there in the world wide web either dumbs it down too much that you don’t get any valuable information or it uses complicated terminology that your newbie mind doesn’t know yet. On the surface, Git seems wildly complicated, but once you dig deeper you realize it’s just not that bad! One thing to know right off of the bat, git does not store multiple versions of the same file. Instead, each “version” of the file is stored as a hash (like a book mark) for that file. This makes Git very flexible in the directions you can move in your code (jump forward, backwards, even sideways to another branch).
Lesson 1: Vocabulary (for beginners)
The terminology that is used when talking about Git sounds super overwhelming, so let’s go through that first and get you used to the terms being used across the board.
- Repository: This is the #1 most important aspect of Git and it sounds just like what it is. It is basically a “bucket” where all of your files and code goes in to. The repository (or “repo”) is where all of the changes you make will go into. The repo will store all of your files and each change you’ve made to that files.
- Upstream: This is usually just used as another word for the “repository”. It’s sole purpose is to confuse you. But seriously, it’s the location which all of the changes will come from.
- Branch: You can think of this as a copy of the repo that supposed to house specific groups of changes that contributors can work on. Different developers will use branches differently, but I liked to use these few branches for all projects: Master, Release, Dev* (more on this to come). This allows me to make changes to a “Dev” branch without effecting the “master” branch until I am ready to.
- Commit: This is the bread and butter of Git. Commits are made by developers to the branch that they are working on. A commit is just like a bookmark in your coding process and it allows you to go back to it if you mess up or want to see what you were doing.
- Merge: When your branch is ready, you will merge it in to another branch. This, again, will all depend on how your branches are set up. If you take my branch setup for example, I would merge the “release” branch into the “master” branch when the release branch has all of the code in it ready to be launched. A merge will check for any conflicts and show them to you or, if no conflicts exist, it will merge both branches into one branch seamlessly.
- Pull Request: This is really a “social” aspect of Git and not a technical one. It does not do anything with the code or commits itself but instead it is a way to ask for permission to merge their branch with yours. This works to simply help the repository manager track all of the branches their team is working on and to make sure to merge only when it is necessary.
- Pull: Strangely, this has little to do with a pull request. If two people are working on the same branch, you will want to “pull” the files from the branch down to your own computer. Doing this will then merge your work with the current work on the branch.
- Push: After you commit your changes to the repo you want to push them into the branch you were working on. If you think of a commit as a bookmark in your code changes, a push is like publishing those changes into your book. You can commit many times before you push your changes into the branch. Until you push, your changes will exist only on your version of the files you are working on. Once you push your changes then other collaborators can pull them to see what you worked on, commit their own changes, and then push them into the same branch!
Knowing the terminology is half of the battle. When you are a newbie looking for git tutorials you can get overwhelmed with “push this and pull that and then commit and pull request all of the things”. It starts to look like alphabet soup and your brain just wants to shut down. Now that you know what they are talking about with this handy little beginner glossary for git you should have a much easier time learning from existing tutorials.
Stay tuned for more contributions to this “Git for Beginners” segment. I will be talking more in depth about these terms and showing you the type of flow I use to manage my small team of developers and even how I set it up for an individual developer.
If you have some questions you are too embarrassed to ask, post them here. The most embarrassing ones that make you feel like a super noob are the ones to ask right here!
Lesson 2: Setting up a repo (coming soon)