Must-Do Before Git Commits: Check Changes, Stage, and Commit Message
### The "Golden Three Steps" Before Git Commit Before committing code, you need to verify the changes to avoid accidentally committing sensitive information or incomplete code. The core steps are as follows: **1. Check Changes** Use `git status` to view the project status, distinguishing between "modified but unstaged" and "untracked files." Use `git diff <file>` to check specific modifications (e.g., added/deleted lines), and avoid committing irrelevant content like temporary comments or debug logs. **2. Stage Changes** Use `git add` to stage files for commit. For a single file, use `git add <file>`; for all changes, use `git add .` (proceed with caution to avoid adding unintended files). If staging is incorrect, use `git reset HEAD <file>` to undo. **3. Write Clear Commit Messages** Before using `git commit`, clearly describe the purpose of the changes. For short messages, use `-m "description"` (e.g., "Optimize homepage title"). For complex content, open the text editor (default Vim) to write multi-line messages, ensuring conciseness and meaningfulness. Developing the habit of "checking - staging - writing messages" can prevent error - prone commits and improve team collaboration efficiency.
Read MoreGit Branch Renaming: How to Safely Modify Local and Remote Branch Names
This article introduces methods for renaming Git branches, with the core being handling local branches first and then safely updating remote branches. Renaming a local branch is straightforward: first switch to another branch (e.g., `main`), execute `git branch -m oldbranch newbranch`, and verify. For remote branches, proceed with caution using the following steps: 1. Pull the latest code of the old branch (`git checkout oldbranch && git pull`); 2. Create and push a new branch (`git checkout -b newbranch && git push origin newbranch`); 3. Delete the remote old branch (`git push origin --delete oldbranch`); 4. Clean up the local old branch (`git branch -d oldbranch`) and tracking branches (`git fetch --prune`), then switch to the new branch. Verification can be done using `git branch` and `git branch -r`. Precautions include: notifying the team before renaming, ensuring uncommitted changes are addressed, having permissions to delete remote branches, and updating CI/CD pipelines for protected branches. The core principle is to first copy remote branches to new ones before deleting old ones to avoid collaboration conflicts.
Read More