Python for Entrepreneurs Transcripts
Chapter: Digging Further into Git
Lecture: Git commit

Login or purchase this course to watch this video and the rest of the course contents.
0:01 Once new, modified or deleted files are in the Git staging area,
0:04 then we need to use the "git commit" command
0:06 to permanently track those changes as part of a specific Git commit.
0:12 Unlike the "git add" command
0:13 the "git commit" command does not specify particular files,
0:17 "git commit" will simply take all of the files that are in the staging area
0:20 and add them to the next commit, we use the resources.markdown file,
0:25 which is already in our staging area from the last video,
0:28 as an example, after typing "git commit", you'll see this screen,
0:31 which will ask you to enter a commit message,
0:33 the complexity of the commit message is going to depend
0:35 on how many changes you made; typically it's a good practice
0:39 to just make small changes at a time.
0:42 Your repositories can have as many commits as you want,
0:45 so just adding a single file or a few files at a time,
0:49 many times a day is a completely acceptable
0:52 and quite frankly a really good practice to get in a habit of.
0:56 What should you type when you see the "git commit" message screen?
0:59 In this case, I've only changed a single file, so we can have
1:02 a very simple commit message, once you've entered your message,
1:06 save the file, and then we can quit out of here and now our commit is complete.
1:10 Writing commit message is a bit of an art, let's talk about how to do it well.
1:15 First off, what should be in a commit message, you should give context
1:19 on the changes that you've made to other developers,
1:22 now, these other developers may actually be you six or twelve months in the future,
1:26 the commit message should be the one line that allows you
1:29 to jog your memory or understand if you can't remember
1:33 what this commit was all about.
1:36 Why is this group of files together, as part of a single commit.
1:41 It will take some practice to get used to giving context to messages
1:45 in just a short phrase, but, go about it in an intentional way,
1:49 and be consistent in the way that you write your messages,
1:52 the first line of your commit message should be the title
1:55 and that should be less than 50 characters.
1:58 If you can't express everything that you want the reader
2:02 to know about this commit message, in less than 50 characters,
2:05 come up with that short title, give a blank line
2:08 and then write the rest of your commit message.
2:11 In many cases, you're only going to be adding one or two files,
2:15 maybe just making a simple change and in that case you can use the -m flag,
2:20 "git commit -m" and then pass a string in with your commit message,
2:25 it won't take you to the text editor where you are going to enter your commit message,
2:28 you will immediately enter your commit message on the command line,
2:31 when you use the -m flag.
2:33 Those are some principles behind "git commit" messages,
2:36 let's take a look at few examples of good and bad commits.
2:40 A really great example, the "git commit" title would be "remove deprecated API calls",
2:44 at high level, you're removing some functionality,
2:48 a contrived bad example would be "January 12th work",
2:52 first off, the commit message already has time stamps,
2:55 you don't need to include that in your commit title, and second of all,
2:58 it just doesn't give you any context for what happened.
3:01 How is January 12th work any different than January 13th work?
3:04 Another solid example of the commit title would be "fix typos in README",
3:09 it's simple to the point and just tells you "hey, this is a commit
3:12 in which I made one single change to the README file",
3:15 the counter to this great example would be the bad example,
3:17 "Kelsys grammar checking", there is no context for who Kelsey is
3:20 and grammar checking, what actually changed?
3:23 Finally, another great example would be "simplify image filter processing",
3:27 this looks like some sort of feature change that is going to be relevant
3:30 if you're working on that specific repository and you know the files
3:34 that are in that repository; a bad counter example would be just
3:37 "changing code in the zeta module", well first off,
3:39 we'll know which files are changed as part of the commit,
3:42 and second thing is changing code doesn't give us any context,
3:45 of course we're changing code, this is Git repository, this is a commit,
3:49 what actually changed, in this case,
3:52 this message doesn't give us any context at all.
3:55 So now you know how to use the "git commit" command,
3:57 and you learned the difference between good and bad commit titles,
4:00 with that, you know the "git status", "add" and "commit" commands
4:04 which we'll be using constantly as you work on your projects.