In daily development, we often need to share code with team members or back up our own code to a remote server. At this time, Git’s Pull and Push operations come in handy. They are like “taking” and “putting” actions, keeping the code in the local repository and the remote repository consistent.

1. Understand “Local” and “Remote” First¶

Think of the local repository as a “draft notebook” on your computer, where you can freely write and modify code. The remote repository (such as a repository on GitHub or GitLab) is a “shared blackboard” for the team, where everyone can see and modify the content. Pull and Push are like “taking” and “putting” content between the draft notebook and the blackboard.

2. Pull: “Take” Code from the Remote Repository¶

When to Use Pull?¶

Use Pull when you need to get updates from others in the remote repository (e.g., a colleague modified the code or the remote repository has new content), or when you want to sync your local code with the latest version on the remote.

Pull Command: git pull¶

Format: git pull [remote-repo-name] [branch-name]
- Remote repository name: Default is origin (if not changed), representing the remote repository address you cloned.
- Branch name: Such as main or master (now main is the mainstream branch).

Example Steps:¶

1. First, confirm you’re on the correct branch (e.g., main):
   git checkout main (if not on the main branch, you may need to switch).
2. Execute the pull command to get the latest code from the remote:
   git pull origin main
   (If the remote repository is already associated with the local branch, you can directly use git pull).

Pull Result:¶

• If there are no updates on the remote, it will show Already up to date. (meaning it’s already the latest).
• If there are updates, Git will automatically merge them (in simple cases), and your local code will match the remote version.

3. Push: “Put” Local Code to the Remote¶

When to Use Push?¶

Use Push when you’ve completed code modifications locally and want to share these changes with the team (or back them up to the remote).

Push Command: git push¶

Format: git push [remote-repo-name] [branch-name]
- When pushing for the first time, you may need to add -u (--set-upstream) to associate the local branch with the remote branch, avoiding repeated input next time:
git push -u origin main
Subsequent pushes can directly use git push (Git will remember the associated branch).

Example Steps:¶

1. First, confirm you have local modifications and have committed them (if not committed, run git add . and git commit -m "modification description" first):
   - git add . (Add all modified files to the staging area).
   - git commit -m "Added user login functionality" (Commit to the local repository).
2. Execute the push command to send local content to the remote:
   git push origin main
   (If the branch is already associated, you can directly use git push).

Push Result:¶

After success, the remote repository (e.g., GitHub) will display your newly committed code, and team members can see and pull your changes.

4. Tips for Keeping in Sync¶

1. Pull First, Then Push
   Before starting work, always run git pull to get the latest code to avoid local code being “out of sync” with the remote, which could cause conflicts.
   (For example, if a colleague modified the same line in the same file, pushing directly would overwrite their changes, causing a conflict.)

2. Simple Conflict Resolution
   If a conflict occurs during Pull or Push (e.g., the error Automatic merge failed appears), Git will mark the conflict area in the file with symbols like <<<<<<< HEAD. At this point:
   - Open the conflicting file, find the marked section, and manually modify the code (e.g., merge content or keep your/their changes as needed).
   - After modification, run git add . and git commit -m "Resolved conflicts", then push again.

3. Check Status to Avoid Accidental Pushes
   Before pushing, use git status to confirm there are no uncommitted changes or incorrect branches, avoiding pushing incomplete code.

5. Summary¶

Pull and Push are core operations in daily Git usage, like “communication” that makes the local and remote repositories “talk” to each other. Remember: Pull is for “updating yourself”, and Push is for “sharing yourself”. Developing the habit of “Pull first, then Push” can effectively reduce code conflicts and make collaboration smoother!

At first, the commands may seem overwhelming, but with practice, you’ll get familiar. If you encounter issues, use git status to check the status or git --help for documentation—you’ll master it gradually!