| English | 中文 |
Many people naturally understand Git in an SVN way when they first encounter it.
This leads to a problem: you can complete commits and updates with Git, but it’s hard to leverage Git’s true value in local commits, branching, merging, and PR collaboration.
| Topic | SVN | Git |
|---|---|---|
| Repository Model | Central repository mainly | Everyone has a complete local repository |
| Commit Location | Usually committed directly to the central repository | Committed to the local repository first |
| Branching Cost | Relatively high | Very low, used daily |
| Offline Work | Weak capability | Can fully commit, view history, and switch branches |
| Collaboration Style | Tends to be centralized | Tends to be distributed |
| Review Method | Often relies on post-commit checks | Often through pre-merge review via PRs |
In the SVN era, many people were used to “committing only after finishing”.
Git recommends committing in logical batches, where each commit expresses a clear intent.
Git branches are very lightweight; daily tasks should prioritize isolation using branches.
Recommendation:
git switch -c feat/my-task
git pull actually consists of fetch and merge; improper use can generate many meaningless merge commits.
On personal feature branches, consider:
git pull --rebase
But avoid rebasing public branches that others have based their work on.
Git’s value lies not only in local commands but also in pre-merge review.
Teams should try to merge into the main branch via PRs as much as possible, avoiding everyone directly pushing to the main branch.
If you want to migrate, first unify the team’s branching strategy, commit conventions, and main branch protection rules before migrating the tools.