Check and Modify: First Confirm “What Changed”¶
Before committing code, the most common mistake is “unintentionally pushing something that shouldn’t be submitted.” For example, accidentally committing passwords, log files, or even binary files like game saves, or forgetting to finish writing code before rushing to commit. Therefore, the first step is to use Git’s “eyes” to see exactly what changes you’ve made.
How to Check?
Use the git status command, which tells you the current project’s “status”: which files have been modified, which are new, and which are not yet tracked by Git. For example, if you just modified an index.html file, running git status might show output like this:
On branch main
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: index.html
Untracked files:
(use "git add <file>..." to include in what will be committed)
newfile.txt
modified: index.html: This file has been modified but not yet “staged” (staging = telling Git “I confirm I want to commit this change”).Untracked files: newfile.txt: This is a new file that Git is unaware of; you need to manually decide whether to commit it.
See What Changed Specifically?
To see exactly what was changed in index.html, use git diff index.html. It will display the added/deleted content like this:
diff --git a/index.html b/index.html
index 1234567..89abcde 100644
--- a/index.html
+++ b/index.html
@@ -1,3 +1,5 @@
<html>
<head>
+ <title>New Title</title>
<body>
- Old content
+ New content
+ This line is added
</body>
</html>
This way, you can clearly see where changes were made and avoid committing unintended content (e.g., temporary comments, debug console.log statements).
Stage Changes: Prepare a “Commit List”¶
Once you’ve confirmed the files to commit, use git add to “stage” them. Staging is like putting your completed homework into your bag, ready for the teacher to check, rather than just throwing it into the bag (unstaged files are like draft paper, which may be modified or discarded at any time).
Common Commands:
- Stage a single file: git add index.html (adds the modified index.html to the “bag”).
- Stage all changes: git add . (. represents all modified and new files in the current directory; suitable for quick commits, but be careful not to add files you don’t want to commit).
After running git add index.html, check with git status again. index.html will change from “unstaged” to “to be committed”:
On branch main
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: index.html
If you staged something by mistake?
For example, if you accidentally git added a temp.log log file, use git reset HEAD temp.log to remove it from the staging area (returning it to the unstaged state).
Write a Clear Commit Message: Label Your Changes Clearly¶
After staging, use git commit to submit, but always write a clear description of “what this change is for” before committing. The commit message is like a note on a package; others (or future you) can see what you did.
How to write it?
Use the -m parameter with double quotes for a short message (suitable for 1-2 sentences), e.g.:
git commit -m "Modify homepage title and content, add welcome message"
If the message is long?
If you need to write multiple lines or more detailed content (e.g., “why the change” or “what parts were modified”), simply run git commit without -m to open a text editor (e.g., Vim). You can write multi-line messages here, then press ESC, and type :wq to save and exit.
Note: The commit message should be concise but not too brief. For example, “Fixed it” is unclear; instead, write “Optimize homepage loading speed, reduce redundant code.”
Summary: The “Golden Three Steps” Before Committing¶
- Check Changes: Use
git statusto see which files are to be committed, andgit diffto see exactly what was changed. - Stage Files: Use
git addto put the files you want to commit into the staging area; avoid accidentally adding unwanted files. - Write Clear Messages: Use
git commit -m "Clear description"to submit, ensuring your code history is clear.
By forming this habit, you can avoid committing incorrect content and ensure smoother team collaboration. Remember: Good commit history is the “invisible business card” of code quality!