Skip to main content
黯羽轻扬Keep Growing Daily

Git Usage Common Sense

Free2015-05-20#Tool#git教程#git指南

Using Git requires knowing some common sense, or rather techniques, including how to write commit -m messages

A commit should be a bundle of related changes. For example, fixing two different bugs should be two separate commits. Such granular commits make it easier for other developers to understand the changes and easily roll back when something goes wrong. The staging area and staging capability in Git are actually just for parts of files, so it's easy to create fine-grained commits.

II. Commit Often (COMMIT OFTEN)

Committing often ensures each commit is granular enough and helps ensure only related changes are bundled together. More importantly, it allows you to share code with others frequently. This way, everyone can integrate changes more easily on a periodic basis, avoiding merge conflicts. Conversely, if there are only a few major commits and sharing is infrequent, merge conflicts become difficult to handle.

III. Don't Commit Half-Done Work (DON'T COMMIT HALF-DONE WORK)

You should only commit finished code. This doesn't mean you must complete an entire large feature module before committing. Quite the opposite: divide the implementation of the entire feature module into logical blocks and remember to commit early and often. Never make it a habit to commit routinely before leaving work each day. If you want to commit just because you need a clean working directory (to check out a branch, or to pull changes, etc.), consider using Git's stash command instead of commit.

IV. Test Code Before You Commit (TEST CODE BEFORE YOU COMMIT)

Don't rush to commit just because you think you're done. Thoroughly test to ensure it's truly complete and has no (known) side effects. Committing half-finished work to the local repository will only cause trouble for yourself. When you want to push or share code with others, ensuring the code has been tested is very important.

V. Write Good Commit Messages (WRITE GOOD COMMIT MESSAGES)

A commit message should start with a brief summary of the changes made (recommended no more than 50 characters), then separate the summary from the body below with a blank line. The body should explain in detail:

  1. What is the reason for this change?

  2. What is the difference from the previous implementation?

Keep consistency with Git's native messages, such as git merge. Use imperative mood and present tense, not past tense or third-person singular form.

VI. Version Control Is Not a Backup System (VERSION CONTROL IS NOT A BACKUP SYSTEM)

Backing up files on a remote server is a significant side effect of version control systems, but you shouldn't use VCS (Version Control System) as a backup system. When using CVS, you should pay more attention to the semantics of commits (see Only Commit Bundles of Related Changes), not just blindly fill it with files.

VII. Use Branches (USE BRANCHES)

Branches are actually Git's most powerful feature, and this is no accident: fast branch operations have been a core requirement from the beginning. Branches are the perfect tool for avoiding confusion between different tasks during development. Branches should be used extensively in development workflows: adding new features, fixing bugs, trying new ideas...

VIII. Agree on a Workflow (AGREE ON A WORKFLOW)

Git supports various workflows: long-running branches, topic branches, merge or rebase, git-flow... Which one to choose depends on many factors: the specific project, overall development and development workflow, and (perhaps most importantly) team member preferences. Whichever you choose, just make sure everyone agrees on the workflow.

IX. Help & Documentation (HELP & DOCUMENTATION)

Command-line help can be conveniently accessed: git help

X. Free Online Resources (FREE ONLINE RESOURCES)

References

Comments

No comments yet. Be the first to share your thoughts.

Leave a comment