Getting started with Git

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.

Overview

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 main, all other branches eventually branch from main.

Traditionally, main 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 main branch. Furthermore, some teams will have additional environment branches like int, qa, staging, etc.

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 newCard or feature/widget, named anything you’d like. Branches can be created from any other branch as needed.

It may look like:

main
  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 main 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.

Install Git

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.

Managing branches

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

git status

to get the status of the repo, showing you what branch you’re on. If this is a new repo, you should be on main.

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 and 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.

Run 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 .txt or .html file.

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.

Run 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

git commit

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:

Press 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.

Press 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

git push

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.

Getting latest changes

If you’re working with a team and want to get whatever the latest is in main then you can simply pull down changes like:

git pull

Of course, make sure you’re in the main branch when pulling it down.

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!