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

Talk Python's Mastodon Michael Kennedy's Mastodon