Start learning with our library of video tutorials taught by experts. Get started
Viewed by members. in countries. members currently watching.
The course shows how to use Git, the popular open-source version control software, to manage changes to source code and text files. Using a step-by-step approach, author Kevin Skoglund presents the commands that enable efficient code management and reveals the fundamental concepts behind version control systems and the Git architecture. Discover how to track changes to files in a repository, review previous edits, and compare versions of a file; create branches to test new ideas without altering the main project; and merge those changes into the project if they work out. The course begins by demonstrating version control in a single-user, standalone context, before exploring how remote repositories allow users to collaborate on projects effectively.
In this movie we are going to learn how to do some basic configuration of Git in order to get us started. The first thing we need to know is that there's three places that get stores configuration information and depends on how widely we want those configurations to apply. The first and largest is System level configuration, that is configurations that ought to apply to every user of this computer. Now each user, of course, can overwrite it with their own, but these are going to be default configurations. Now in truth you won't use this very often. It's much easier and much better to set it up on a per user basis, but I just want you to know that it exists.
On Unix that's going to be inside the etc directory, in a file called gitconfig. It's also going to be in the same file, inside the same folder on Windows, but it will be stored in a different place. Most likely it will be inside your program files, inside the application for Git. Now the most useful place to store configurations is going to be User level configurations. These are going to apply to a single user, which most of us, most of the time are working on a single-user machine and so we can have our single-user configuration. On Unix, that's going to be in your home directory, inside a file called .gitconfig.
On Windows, it's also going to be in your User directory that's the HOME directory .gitconfig. If you're not familiar with where your HOME directory is chances are it's going to be inside your Documents and Settings folder, and you should find your username there, and inside that username folder, that's where you will see gitconfig. And then the third place that we can store configurations is on a project-by-project basis. So in a single project we can have configurations that apply only to that project. Now most configurations, you are probably don't want to use from project-to-project, and you want to put them in the User configuration.
But if there is something specific to a single project you can put it inside of the project, look for a folder inside there called .git, and then inside there we have file called config. Now the names of these configuration files vary depending on the location, and some of that is just because of some of the different conventions that Unix uses, and that's what this follows. But if you know generally where to look for these files, the fact that their all named slightly different, shouldn't throw you off, they should stick out, you should be able to find them. Now we can go in and directly edit these files and put in our configuration information, but that requires us to know something about the format of those files, we don't have to do that.
Git gives us some commands that we can use to make editing these configurations easy. For all three of them, it's going to be git config, followed by a modifier that tells at what level we want to do the configuration, and then followed by the configuration itself that we want to do. So if we want to do a system-wide configuration, then it's --system at the end, if it's User level then that's --global, don't let that throw you, global doesn't mean system, it means global to the user, and then if we don't have any modifier then it's just on a single project basis.
So that's what the command looks like, and that tells it how to direct it, what are the kinds of configurations that we can set? Well, let's set a few. So here I am in my command line. You'll want to make sure that you're there as well, it doesn't matter where we're located because we are going to be doing configuration that's global. So as long as we are logged in as a user, we will be making edits to our global user file. So we can call git config and then --global, and then whatever we want to configure. Well, the first thing we need to configure is our user.name, so user.name, space, and then in double quotes put in your name.
So obviously you've used your name and not my name and then when you are done hit Return and Git added it to the config file. Let's add another one, git config --global user.email, space, and then you can put in your email address there. I am going to put in just a fake one here rather than give out my real email address, firstname.lastname@example.org but you will put in your real one. Now if you want to see these configurations, you can say git config --list, and it will then pair it back to the list of configurations that it has set for you, or if you want to look at a specific one, you can say user.name, and it returns just that one, same thing, user.email, and it returns the email address.
So we can take a look, we have the ability to set them, and we have the ability to retrieve them and look at what they are. Now let's look at where those are located. I am inside my user directory already right here. On Unix, you can do cd space followed by the tilde, and that'll make sure that you are in your user directory, and let's do ls -la, for Windows users that's going to be dir, that will show you the directory listing, and you will right here is a file called .gitconfig. Now there are number of ways that you can open up this file, the fact that it is a dot file means that it's going to try to hide it from you, you are not going to see it when you look at it in the finder, you are only going to see it from the command line here, that's part of what that dot does.
One good way to take a look at it real quick with Unix is just to use the cat command, cat .gitconfig, I'll just clear my screen so you can see, and there is the file. That's what it actually looks like inside there. So this is the minimum that you need to configure and to start working with git. You will come back to this file and add other configurations over time. I want to show you two more useful ones now. The first is to tell Git what Text Editor you will be using. This allows Git to open up text that needs editing in that editor by default.
There are times when Git is going to want to have you edit a message and so it'll pop up that message in a Text Editor, let you change it, and then close it. And Git will go ahead with what it was going to do. The way we do that is with git config --global and then core.editor and then after that in quotes let's put the name of the editor that we want to use. So if you like using Unix's nano, you can put that there, you can use vim, or emacs, if you are on Windows, you can use notepad.exe, that comes by default with Windows.
I'd like to use TextMates, so I am going to be using M A T E, which is a little program that TextMate provides that sits inside Unix, and it can then launch TextMate. In addition to just launching it though, we need to provide a couple of options with it, which is the -w option, which says, hey after you launch it, wait until TextMate is done before you keep going with what you were going to do Unix, so we need that W option otherwise Unix will open it and then just keep going further as I was doing without waiting for you to finish the message, and then l1 also tells it to start at line 1.
So wait and put the cursor at line 1 of the message. If you have a different text editor you'd like to use, you can try plugging it in here or you can Google around and find out what configuration other people are using, so they can use that program. Okay, so now that I've got that in there, that will add it to my config file, the second configuration we will add now is to tell Git to use colors when outputting things to the command line. If we don't use this, it will just give us monochromatic text, just one single color. Instead, by setting this option, it will allow Git to try and use colors like red and green and blue to help illustrate what point it's trying to get across, what information it's trying to convey.
So we can use git config --global, and then we are going to say color.ui set to true. So that's it, tell it to color the user interface. Once we do that, cat .gitconfig, you can see now our config file has a few more options listed. We will come back and add more later, but this is enough to get us started.
Find answers to the most frequently asked questions about Git Essential Training.
Here are the FAQs that matched your search "":
Sorry, there are no matches for your search ""—to search again, type in another word or phrase and click search.
Access exercise files from a button right under the course name.
Search within course videos and transcripts, and jump right to the results.
Remove icons showing you already watched videos if you want to start over.
Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.
Click on text in the transcript to jump to that spot in the video. As the video plays, the relevant spot in the transcript will be highlighted.