What is Git?
The elevator pitch:
Git is a repository for code and provides versioning with a capability to easily share and collaborate with others
Maybe a little too simple, but at its core, that’s what git is about. It provides developers a place to store their code with version control so that they can always roll back changes. For teams of developers, it becomes even more important as it allows for many developers to contribute, along with version control, and ensure code quality.
A git repo keeps a collection of files in a
branch. A single git repo will contain multiple branches. A branch can have multiple versions in it, each version in git is called a
commit. Branches are created from other branches. Each repo starts with a single branch called
master, all other branches eventually branch from
master is considered the production branch, the code in this branch is released to the production environment.
Most teams have a
develop branch, or similar. This is the branch they will work against, test against, and ensure quality of the product before pushing those changes to
master branch. Furthermore, some teams will have additional environment branches like
We can also create feature specific branches. These branches are branched from
develop and allow developers to make any code changes they want without impacting
develop until they’re done. A feature branch might be
feature/widget, named anything you’d like. Branches can be created from any other branch as needed.
It may look like:
master develop feature1 newCard newCard_2 widget etc...
Again, each branch is its own self contained bucket of the files, each with their own version history. The code that is changed in the branch
widget will not be in any other branch, until it’s merged into another branch, like
develop, then it has to be pushed into
master to get to prod. Each one of these pushes should be under scrutiny with quality controls and code reviews. Given this tight escalation process, development teams have a control on exactly what is released to prod and have assurance it’s going to work.
Check out Git Flow for more details about feature branching.
Code reviews, quality gates, release processes and more are capabilities that live outside of git itself. Each team does it a little differently. We can talk more about these if you’d like. Let me know.
Before we get much further, install Git! Go to https://git-scm.com/downloads and download and install the right version. During the install, accept the defaults, unless something looks good for you to change. Your call.
Once installed, you can use the newly installed app
git bash to use git with a command line interface (CLI) or use the desktop version. It may be tempting to use the desktop version but I encourage you to not to. Learn it the real way and you’ll appreciate it a lot more.
The rest of this post will use the CLI, but all of these capabilities should be available in the desktop app as well.
Git itself is a toolset for code repos, and there are many differing products that support git, like GitHub.com, BitBucket.com, VisualStudio.com and others. Fortunately, they all use and support git in the same ways. The app you just installed will work with any repo that supports git.
Fundamentally, branching is pretty straight forward (although there are some real complex scenarios out in the wild). You will create a branch from another branch and then your new branch has all of the same files and commits as the source branch.
If you want to walk through this using a real repo, go to github.com, create an account and create a sample repo.
Before we get branching, first clone down your repo. This will make a copy of the repo on your local machine. Any git repo will have a basic
git clone command available you can just copy and paste. This command, and all subsequent commands below, will be run in Git Bash. When you clone it down, it creates a subfolder using the repo name.
In Git Bash, navigate to the newly created folder then you can do a
to get the status of the repo, showing you what branch you’re on. If this is a new repo, you should be on
Create your first branch
Let’s create a branch! Type in
git branch branchName
Branch names are case sensitive, kind of. If you name your branch
branchName and then try to go to
BRANCHNAME it’ll work, but it won’t be directly linked or clear. It’s kind of odd. I’ve had issues where
Dev are the same branch but some functionality in git got confused. Avoid it as much as you can. I recommend all lower case or caMel case names and keep it consistent.
git branch without the name to view all branches on your local machine. You should see
branchName listed there now.
Enter your branch
To now use that branch, we want to check it out.
git checkout branchName
Now when you run
git status you’ll see you’re in this branch.
Add files to your branch
Go ahead and add some files to your branch. Use Windows Explorer or Mac Finder and drag and drop some files in, or create a new file. Git supports virtually any filetype. For now, it may be easiest to use a
Once your files are there, run
git status again. You’ll see your new files are in red, labeled
Untracked files: which means they’re not ready to be saved. Let’s add them to your commit
git add .
This will add all files and changes to files that are in the folder structure of the repo. You can alternatively add one file at a time by using
git add filename.html.
git status again and you’ll see your files are green. Now they’re staged and ready to be committed. (remember a commit is a version).
Commit your changes
Now let’s commit your changes. At any point you can run
git status and see changes ready to be committed in green. Now run
Depending on how you installed git, if you accepted defaults, you should see a full screen editor in the command window with a nice message
Please enter the commit message... and so on.
This edit mode is called vim. Vim is too big to explain here, so here’s what we care about:
i to insert text then start typing a commit message. Your commit message should be meaningful and explain the changes in this commit. Check out this post for more on a good commit message.
esc to exit insert mode, then enter
:wq to save (
w write) and
q quit. If you want to cancel your changes, type in
:q! to force quit and not save.
Now when you run
git status you should see
nothing to commit. Good job!
You can continue to make changes and commit them as you go. Each time you commit it makes a different version of the branch with those changes.
Remember, these changes are only in your branch. To send them into the original branch you branched from you have to merge them in. First we push them up then merge them.
Push your changes to the repo
All of the changes you’ve made are local, only on your machine. Now we want to push them up to the code repo so we can merge them. Run
Since we created a new branch, it doesn’t fully know where to push it. The above git command will throw a fatal error, but it also gives us the command to run, which is awfully nice of it, so copy the command, paste and run it. It will look something like
git push --set-stream origin branchName
This will trigger the push, you’ll see a lot of fun info about what it did. Moving forward, on this branch, you can just run
git push, since the stream was set before and doesn’t have to be set for every push. You will however have to run it for any new branch you create.
Merge your code back to source
Now that your code is in the repo, create a pull request and request to merge your branch back into the original branch. This is done through the web interface, and I won’t cover it here since there are many different products that can provide git repos.
Refreshing your branch
Sometimes we may run for a few days on our own branch. This is okay, but it’s important to refresh your branch with any changes made to the source branch over the length of your branch’s life. Remember, your branch has its own version of the code, and any changes made in other branches are not included in your branch.
To refresh your branch, run
git rebase sourceBranchName
This will apply all changes made to the source branch to your branch since you created your branch, while keeping your changes. If there are merge conflicts, usually happens when two people edited the same lines in the same files, you will get merge errors. You can edit those files and you’ll see the conflicts in the code. Pick which one should win and delete the wrong one. Then commit it.
You’re a master!
Really! We covered the basics of git and this covers 90% of what you may have to ever do with git. Most weeks I only do these commands.
In my next post, we’ll dive in a little deeper and streamline some commands, share some tips and tricks and shortcuts! Stay tuned.
‘Til then, happy git’in!