By now, you should have GitHub setup, git installed in your system, and even a few commits under your belt. You also have some good knowledge of markdown and other tools related to version control.

In this deep dive section, we're going to take a much deeper look at version control and how you can use it in a professional environment. The actions we’ve discussed such as adding to Git and how to commit with messages are good basic tools, and enough if you're working alone. However, if you're working in a team, there are more tools you should know about such as creating branches, managing merge conflicts (an issue that arrises when two developers push code to the same file), as well as several other tools.

Let’s start in the terminal. I've created a directory called gitguide in Desktop, and we'll be doing all our work in this directory.

(Developer’s note: to create a new directory use the command mkdir followed by the directory name. Don’t forget to cd into that directory to begin creating files in it).

One thing I want you to be aware of is that Git is not connected to Rails at all. Git is a completely separate entity. This guide will be focussing on pure Git and the various commands available to us, as well as some more advanced ways to use version control.

Adding Git to our Directory

To begin, we will create a git repository in our directory. The command is git init

Essentially a git repository is a container for all of the versions of our set of files. When you use the git init command you will get a response that declares Initialized empty Git repository in, followed by the file location.

Now we can start adding files. Remember the command line imperative for creating a file is touch. For this guide we will use the command touch file1.rb file2.txt file3.html

Now, if you type ls, you'll see that we have three files.

Next use the command git status. You will see indications that we are on branch master, are in the initial commit mode, and you have three untracked files.

Tracking files

There a couple of ways to track files in Git. Tracking means putting them in a holding mode until we decide if we want to commit them.

Remember to add a single file we use the command git add filename. So here we would use git add file1.rb

Now if you type git status , you’ll see that the file you added is marked green, and has the indication of changes to be commited

This simply means that the file is added and is ready to commit. Take note, there are a couple of untracked files that still show in red. There are times that you will want to just add a single file to be committed. Other times you will want to add all your changed files at the same time. The command for that is git add .

If you type git status again, you'll see that all the files are now in green.

Next, commit all the files with the command git commit -m "Initial commit". -m is an option we use to add a message to our commit. This commit message can be whatever you choose. It is just for you and the other developers working on the application so that you can know what work was done on the app during that version. Don't forget put your message in quotation marks.

If you do another git status you will see that there is nothing to commit.

Comparing Changes to the Files

Now we will add content to one of our files. If you remember back to the command line tutorial the imperative to add content to a file is echo along with the > symbol which pipes the content into the file.

Here we will use: echo "some content" > file2.txt

cat is the command to display the contents of a file. If you enter cat file2.txt, you will see that the file contains some content

If you type git status, you should be able to see that file2.txt has been modified.

So, do another git add . Then a git commit -m ‘Updated content for file 2’

Another useful Git command is git log . This shows a full list of all the versions for your application.

If you ever want to see what your code looked like in a particular version you can use the commitID from the git log.

Just copy the commit ID, then type the command git checkout, paste in your commit ID and hit enter.
It will look like this: git checkout 1d10f129ef320e9224fbdbd778da9a8fd254a05

This returns a message with all sorts of information that might seem intimidating. For example there is a line that says You are in ‘detached HEAD’ state. There is nothing to be concerned with here, as it doesn't have anything to do with your work. The response also includes a help message to show you the command for creating a branch, which is something will get to a little later in this guide.

For now, Just take note of which commit we are looking at. Here you will see we are looking at our initial commit.

If we run a git status it will show that there is nothing to commit.

If we use the command cat file2.txt we will have no content displayed because our files were empty at the time of our initial commit.

Remember, we are looking at the files for the initial commit. If you want to return to the version you were previously at you would copy the commit id from the git log and use the command git checkout followed by the commit id.

Typing the command clear will take your cursor to the top of the terminal screen. Now type git status again. You will get a response saying HEAD detached at (hash code), nothing to commit, working tree clean . This head detached commit message comes up because GIT doesn’t track files they way you might intuitively think. Even though you have gone back to your current version GIT just makes note that you are at a particular version.

If you simply want to go to your current version, the proper command is git checkout master

Once again type git status and you will see you get a normal response of On branch master nothing to commit, working tree clean.

Branches

The next item we're going to talk about is branches. I want to explain a real-world example of why Git branches are so important.

Let's go look at the DevCamp site that I manage. Here is the main profile page. While it is fine and functional, at the time of the recording this video, we're in the process of redesigning this site. The redesign process is actually going to be quite extensive, and it will take me more than say an hour or even a day or two to implement the new code. Imagine that I am only partially done working on the updates for this page and another team member contacts me to let me know there is a small spelling mistake on another page in the site. Ideally, I can take a minute or two to make the spelling change fix, upload it, and that small item is now taken care of.

However, there would be a problem with this upload. If I am working on the main code base, although I’ve fixed the small issue, when I push up my code, it will include the half-finished product and the DevCamp website will now look terrible and I would look like a sloppy developer.

Git has a way for us to overcome such an issue and that is to create a branch. A feature branch allows us to isolate work we are doing that would take more that a few hours or days. Returning to our example, if you needed to change a mis-spelled word, or some other quick fix, you could simply switch to a different branch, make the small change and push that up to the live site. Then you can go back to your feature branch and continue with your work. This way, you won't push up product that is only partially completed. From this example you can see that branches can be a great resource.

Creating a Branch

To find out which branch you're working on, the command is git branch.

If you are following along you should have received the response master.

To create a new branch, the code is git checkout -b branch-name. Let’s try that with the command
git checkout -b my-great-feature

You should have received the response Switched to a new branch ‘my-great-feature'

Now if you type git branch, you'll see that you have two branches. You should note that the current branch is highlighted and has an asterisk in front of it.

Working on our Branch

Let's do some more work here. We'll append content to our file2.txt. Remember to append you use >>, so our command will be:
echo "some more content" >> file2.txt

Now if you type cat file2.txt, and it'll display everything in file 2, which will be the lines, some content and some more content. The git status command now shows that one file is changed.

Let's suppose you still need to make more changes on this branch, but someone calls and wants you to make a quick fix to the website. Your first step will be to commit the work you have already done. Start with the command git add file2. Then git commit -m ‘Initial implementation of file2 . With a git status you can verify that everything is in order.

Your next step will be to switch branches with the command git checkout master. If you use the cat file 2 command now, you will see that the changes you made on your ‘my-great-feature’ branch did not carry over. Now you can make the small change you need to, and push it up live, without having to worry about the incomplete work in your code.

So whenever you have a feature that isn’t quite ready for production, you can use a separate branch to build that code. You can have multiple feature branches that you are working on in a project.

Don't worry if this concept is still a little unclear as we'll be using branches extensively throughout this course. We will follow a workflow such that whenever we start a new feature, whether it is covered in a single guide or requires a full section to complete, we will create a feature branch and then merge it into our main file base (master branch).

Git Merge

The next concept we will cover in this guide is how to merge changes.

Returning to our real world scenario, let’s say we are going to finish the feature we started. We can go back to the branch we had previously created with the command: git checkout ‘my-great-feature’.

Let’s add more content to file2.txt. We will use the command echo “last items” >> file2.txt” , to append to file2.

Go ahead and run a git status to verify which file was modified. Then, git add . , followed by git commit -m ‘finished file 2 feature’. You can run a git status again to see that everything is committed. Now use the command clear to return to the top of your screen.

Now we are ready to merge this feature branch into our master branch. To merge it with our master branch, the first thing we need to do is switch to the main branch. Use the command git checkout master.

Next, we can use the merge command followed by the name of the branch we want to merge in:
git merge my-great-feature.

The terminal will respond with information about how many files where changed and the number of insertions.

Remotes

The next item we will cover is working with a remote repository. Earlier in this section of the course we learned about how to create a GitHub account and a repository.

Let’s create a new repository for this guide. To do this click on the + button in the nav-bar and choose New Repository. I'm going to name it “git-demo-repo". It will be public and we do not need a readme file, so just click the Create Repository button.

If you remember when we did this before we are given some options:

Nine out of ten times, we'll use the third option to push an existing repository. We already have a repo, we just need to push it up to a remote location online.

If you have a completely empty directory or application, use the second option to create it. If you look at the directions, you'll see that the first couple are just commands that you would do to create an repository and the final two are exactly what we will do to push an existing repository. Essentially, we’ve already done the work that would be required for that second option.

For this demo, let's click the clipboard for the third option and paste those commands in our terminal. This will push all the code from our local repository to our remote repository. Go back to your browser and refresh your GitHub page. You should see all the files we created along with the content we added.

README

Managing conflicts is a really important concept to learn in order to use version control effectively.

To understand the process we are going to begin by creating a README.md file. You might remember from previous guides that the README.md file is akin to your application’s instructions.

GitHub looks for the README.md file at the root of your application and displays it on the home page of your remote repository.

To create the file we use the command: touch README.md.

Open the file in sublime, and add ## Git Demo on line one (1).

Next, add the file to your local repository and commit with the message “Added Readme”. Now we want to do a git push. You might be wondering, where are we going to push this?

You can use the command git remote -v to find the location, which almost identical to your GitHub repository’s URL.

To push your code to this repository, the command is git push.

Hit the refresh button on your browser again and you can see your updated README file.

Managing Conflicts

Now, what happens if multiple developers are working on the same application?

For example, I have several developers who contribute to work on DevCamp. We might be working on different features, but sometimes we each end up altering the same code file. This can lead to something called code conflict.

I'm going to create a conflict by editing the README file on GitHub itself. It’s not a good practice to edit files here, but I’m doing this just so you can see what a conflict looks like.

Click on the readme file itself and then click on the edit button (pencil icon) and add > Some content on line three (3), then go down to the form and add Updated readme as the commit message and hit the commit changes button. You can also create a new branch from here. I suggest you peruse GitHub and look at some of these options, but you will rarely make file changes on GitHub. For now we will just commit this change.

Let’s pretend that some other developer made this change and pushed it up to GitHub, but I was unaware of the change.

In my version, I would make my own changes. Open your README.md in sublime and add the line ## Some other changes to line three. Now add and commit it locally with the message ‘More readme updates’

Git pull

Next, we are going to pull the content from our remote repository to our local machine. The command is git pull

If you're the only person working on an application, then the only time you'll use git pull is if you have pushed a remote branch and want to pull it down.

If you're working with other team members, then you'll do this often to have the latest version of others' changes in your local machine. For example, if another developer did some updates to the DevCamp website, they would push the changes to the remote repository, and GitHub would store those files. However, they would not be on my local machine. I would need to use git pull to have the latest version of the application.

Resolving the Conflict

If there are no conflicts, i.e.: no files that contain mismatched code, then git just pulls those files in and we can continue to work with no issue.

In the case we created, there is a conflict and git doesn't know to manage it. So, you'll get a message like this:

The message let’s know that there is a conflict in the README.md file. If you’ve never seen a merge conflict before, it can be a little intimidating. When you open the file in sublime, you’ll see a lot of weird characters like this:

This is not a bad thing, but there are some developers who get really tense over these conflicts.

Actually, I think git has a great way of managing conflicts. Instead of overriding one developer's work with the code another one wrote, it displays the conflict and gives you a chance to resolve it. This way, we can decide if the conflict code is relevant and whether we want to keep it.

If you decide to keep all the code changes, just delete the characters git inserted to show us where the conflict resides.

Now the code will look like this:

Next we can save and commit. Git will have all the code, and the conflict is merged. Not too overwhelming really after what looked like some peculiar code.

What the Merge Conflict Code Indicates

Now, let's explore what those strange characters are. The first line - "<<<<<<<<< HEAD" refers to your specific commit, or the code you wrote.

The "========" signifies what is causing the conflict. Below this row of equal signs you will see the code that varies from yours.

The end of conflicting code is denoted by a group of angle brackets followed by the commit hash and looks similar to this: ">>>>>>>>>>>> commitID"

This separation allows you to choose between your changes, the other developers changes, or to keep all the changes. After you delete the conflict characters, save your file and run a git status. The response will indicate that you have unmarked paths. To fix that just run the command git add . Followed by git commit -m ‘fixed merge conflicts’, and finally git push.

After committing the files, go to github, refresh the page and you should be able to see your README file with all changes. No code was lost in resolving this conflict!

Git cheatsheet

Git is so expansive even a deep dive guide can not cover every single facet of it. So, I'm going to make a cheat sheet available to you.

The Git cheat sheet will contain all the basic commands and what they do, commands for creating branches, as well as more advanced topics. I highly recommend you take the time to look through these commands and play around with them so you can become more comfortable with Git and concepts such as stashing, reverting, cloning, and more.

There is even an entire section on resolving merge conflicts. Merge conflicts happen on a regular basis. New developers can sometimes feel intimidated by these and can get scared away. This guide can help you resolve your concerns about merge conflicts!

Resources

• Git Cheat Sheet