The Basics
In a few minutes we’ll step through a simple workflow using Git. But first let’s review a few of the basics of Git that we need to understand before moving forward.
We’ll cover:
- Repository
- Branches
- Commits
- Remote Repository
- Branching & Merging
Repository #
The repository is a collection of files and directories and their history of changes. These changes are recorded with commit objects. These commit objects are referenced by other items in Git (branches and tags, to name just two).
A new repository can be created by anyone at any time using the git-init command. By default repositories are local only and don’t require a remote.
Branches #
Every Git repository has at least once branch. When you first initialize your Git repository, you have a branch called master. You can have additional branches in your Git repository and name them as you see fit. They are independent from each other unless you choose to merge one branch into another.
Commits #
A commit is a record of what the repository looked like at a given point in time.
Each commit has a commit message, which should briefly explain what the changes were. You can also access a diff to show where the changes were made in a specific commit.
Commits should be create as atomically as possible, so you have as many points in the history of repository as possible. More commits will give you more precision in undoing breaking changes.
Remote Repositories #
By default Git is completely local to your computer. You can optionally have remote copies of the repository (either on a central server or service — like Github — or on a co-workers computer).
To get your copy of the repository up to a remote server you use the command git-push. If you want to retrieve others’ changes to the repository you use git-pull.
We’ll cover all of this is more detail later on in the class.
Branching & Merging #
Earlier I mentioned branches. Prior to using Git, my experience with version control systems was using Subversion, and before that CVS. My experience with Subversion was that branching — and especially merging — was not a fun thing to do. It often didn’t work properly and left the project in a state of conflict.
In Git, branching and merging are simple and safe. Later on we’ll talk about common Git workflow patterns. Most of them rely heavily on branching and merging.
A few notes about branching in Git:
- A branch is typically created locally first and then pushed to a remote (if desired).
- As we’ll see later in the Workflows section, Git is set up to be branch-heavy. Create a lot of branches and create them liberally. It’s the benefit of having a merge process that works so nicely.
- Branches can be only local, if you want. There’s no requirement to push all of your branches to a remote server. I use branches a lot for local experiments that I later delete.