Committing Changes

Editing Files

I'm using the nano text editor because it's the default for the Treehouse console. If you're following along in Windows, remember to use 'notepad' every time I use 'nano,' because nano isn't available on your system. If you're following along on your own Mac/Linux machine, nano may not be your default editor. If you want to set nano as your default editor so that Git will use it, run export EDITOR=nano before you try to run any of these commands. If you're curious about what this does, there's an article explaining it here.

Git Commands

git add - adds files to the repository so that Git knows to track their changes.

git commit - commits all added files to the repository as a change. With the -a flag, commits all changes to all tracked files. With the -m flag, allows you to specify a commit message directly on the command line instead of in your default editor.

git config - allows you to make configuration changes to Git. With the --global flag, makes these changes available across your entire system.

0:01

[Tommy Morgan] Now, that we've got our repository, it's time to get to work on our project,

0:04

and that means making commits to the repository that we just created.

0:08

So, we'll start by creating a new repository.

0:13

I'll just use the "my_really_cool_project" example from the previous video.

0:22

Let's create a README file.

0:24

That's always a good place to start on the project.

0:26

I'm going to use the "nano" text status for this,

0:29

but feel free to use whatever text status you prefer if you're following along.

0:35

[This project is seriously awesome, you guys.]

0:40

Then we'll save the file.

0:41

In nano, the command is "Ctrl X,"

0:43

we'll say, yes, we want to save changes and accept the filename.

0:49

Now, we've created a new file in our repository.

0:52

How do we commit that change?

0:54

Well, before we can commit it, we'll have to add the file to the repository.

0:59

This lets Git know that the file is important to the project and should have it changes tracked in the repository.

1:06

As you might guess, we accomplished this with the "git add" command.

1:14

But why do we have to do that manually?

1:16

Should the version control system just automatically track everything in the directory?

1:21

It's actually pretty useful for us that it doesn't work this way.

1:25

This functionality, although it may seem like an unnecessary step at first

1:29

allows us to keep some files outside of version control.

1:33

Not everything that you do in a project will be fit to share with others.

1:37

Maybe you'll keep your personal passwords for the project in a file, for example,

1:41

and you certainly don't want to be sharing that with others.

1:45

So, now we've added our readme to the project.

1:48

All we need to do is commit our changes.

1:51

We'll make use of the "git commit" command in order to do that.

1:56

You can see that it has opened a commit message template in my default text editor, which again, is nano.

2:03

It lets us know that lines beginning with a hash sign are comments,

2:07

and contains some information about the commit.

2:10

It lets us know who is making the commit, what branch we're on—we'll talk more about that later—

2:16

and provides a brief description of what we changed.

2:19

You can see here that it has our one change listed.

2:22

We added a new file named "README."

2:26

Don't worry if some of the information on the screen looks confusing,

2:30

we'll cover a lot of these details later.

2:32

For now, the important thing to know is that we need to provide a message for our commit.

2:37

It's generally considered best practice to keep these messages short and meaningful.

2:43

Short, so that they are easier to read

2:45

and meaningful so that we know exactly what kind of changes were made.

2:50

For this commit, the commit message is easy.

2:52

We'll just use added or "README" file.

3:00

We see a success message here

3:02

letting us know that the commit has been made to the repository.

3:06

We also see a message about our name and email address.

3:10

An important part of working with version control is making sure that the system knows who you are.

3:16

That way, if people have questions about a commit, they know who to get in touch with.

3:20

By default, it tries to guess this information on its own.

3:25

But Treehouse user isn't a very helpful name.

3:28

So, I'll just go ahead and change that real quick.

3:31

Like the message suggest, we'll use the "git config" command to set these options

3:36

using the global flag to let "git" know that we like these changes applied for all of our repositories.

3:44

I'll set "user.name" to be my name

3:51

and "user.email" to be my work email address.

3:59

So now, we've gotten a file added to the repository,

4:03

but it's not much of a README, is it?

4:05

Let's go in and have some more information.

4:26

and we'll save our change.

4:29

Okay, now, we've made a change to our file and we have to ask ourselves,

4:34

should we commit it?

4:36

This is always kind of a tricky question.

4:38

My rule of thumb is this,

4:41

is there a good commit message that we can use?

4:44

If so, then we probably need to commit the changes.

4:48

Of course, I can always put something vague down for the commit message for this.

4:53

I could say, added stuff to README.

4:56

But that isn't a meaningful message because it doesn't tell us what kind of stuff was added

5:00

or why we added it.

5:02

In this case, I think we can use the message "added project mission statement" to README file.

5:08

That seems reasonable to me.

5:10

It's short and meaningful.

5:11

So, let's go ahead and commit these changes.

5:14

The more often that you commit, the more detailed your project history would be.

5:19

So, it's important to commit every time a good opportunity presents itself.

5:23

We"ll use the "git commit" command again, but this time, we'll use a couple of shortcuts.

5:29

First, we'll add the "-a" flag which is short for all.

5:33

This flag tells "git" to commit all of the changes it can find.

5:37

Second, we'll add the "-m" flag.

5:40

Remember the last time we committed, we had to edit our commit messages in nano first?

5:44

The "-m" flag stands for message.

5:47

It allows us to provide the commit message to the "git commit" command directly.

5:52

We'll just make sure it's in quotes and type it in right after the "-m" flag.

6:04

We see another success message, and that's it.

6:08

We've made a few commits to our repository and are well on our way to getting our project going.

6:14

Most of the time you're interacting with "git,"

6:16

you'll be doing it by committing changes to the repository.

6:19

But how do you know when to commit? That's the harder part.

6:22

You might have to fill it out a little bit.

6:24

When a change is done, isn't always obvious,

6:27

but it's probably a good idea to err on the side of committing stuff more often than not.

6:32

In time, you'll get a feel for it

6:34

and the most important thing you can do is get in the habit of committing regularly.