Remote Synchronization and Pull Requests

Remote collaboration has two layers: synchronization between local and remote repositories, and review before branch changes are merged.

Push sends local commits to a remote branch. Fetch downloads remote updates without applying them to the working directory. Pull fetches and merges in one operation. A pull request asks collaborators to review one branch and merge it into another, usually into main.

To send the local main branch to the remote named origin, use:

git push origin main

Here, origin identifies the remote repository and main identifies the branch being pushed.

Pushing main does not automatically push other local branches. To publish staging:

git checkout staging git push origin staging

If staging does not yet exist on the remote, the push creates the remote staging branch and sends its commits.

The same pattern applies to development:

git checkout development git push origin development

Each branch is synchronized independently.

Suppose a file is edited and committed directly on GitHub. The remote main branch is now ahead of the local main branch.

git fetch

Fetch downloads information about the remote changes into the local repository, but the working files do not yet show those updates. A merge step is still needed to bring the fetched changes into the current local branch.

To fetch and merge remote changes in one operation, use:

git pull

The relationship is:

pull = fetch + merge

After pull completes, the working directory reflects the merged remote updates.

A pull request, or PR, is a request to merge changes from one branch into another after review.

When creating a pull request on GitHub, choose:

• Base branch: the branch that should receive the changes, commonly main.
• Compare branch: the branch that contains the proposed changes, such as development.

GitHub compares the branches and displays which files changed, which lines were added, and which lines were removed.

Create the pull request with a title and description that explain the proposed integration. A pull request page then provides sections for:

• Conversation: discussion and review.
• Commits: the commits included in the request.
• Files changed: the exact file-level and line-level differences.

After review, use the merge action and confirm the merge. The pull request is then marked merged and closed, and the base branch contains the accepted changes.

Push, fetch, and pull coordinate repository state. Pull requests coordinate human review.

Without synchronization, developers work from different versions. Without review, branch changes can enter main without a shared inspection point.

The combination supports a controlled collaboration loop:

1. Develop and commit locally.
2. Push the branch.
3. Open a pull request.
4. Compare and discuss changes.
5. Merge after review.
6. Pull the updated main branch locally when needed.

This keeps the central branch more stable because changes are visible before they are accepted.

Publishing a completed development branch:

git checkout development git status git push origin development

1. Open Pull Requests.
2. Select New Pull Request.
3. Set base to main.
4. Set compare to development.
5. Review the displayed differences.
6. Add a title and description.
7. Create the pull request.
8. Review Conversation, Commits, and Files changed.
9. Merge and confirm when approved.

Updating a local repository after a remote change:

Option A: separate inspection and integration.

git fetch

Then merge the fetched remote changes into the intended local branch.

Option B: immediate combined update.

git pull

Push affects only the branch you specify. Local branches that have not been pushed remain unavailable on the remote.

Fetch provides separation between downloading and merging. This gives more control over when the working directory changes.

Pull is more convenient because it combines the operations, but it also applies the remote updates immediately through a merge.

A pull request does not replace committing or pushing. The proposed commits must already exist on a branch available to GitHub.

A pull request also does not make the decision automatically. Reviewers still need to inspect the comparison and decide whether the changes should be merged.

Use push to publish local commits, fetch to download remote updates without applying them, pull to fetch and merge at once, and pull requests to review branch changes before integrating them into main.