Remote Repositories and Team Collaboration
Learn fetch, pull, push, remotes, pull requests, fork-based collaboration, and safe synchronization with shared repositories.
Remote Repositories
A remote is a named reference to another Git repository. origin is the conventional name assigned to the repository from which a clone was created, but it is only a name and can be changed.
Use git remote -v to inspect configured URLs and git remote add to add another remote.
git remote -v
git remote add upstream https://example.com/team/project.git
git remote set-url origin https://example.com/my/project.git
git remote remove upstreamorigin and upstream.- A remote is a local name pointing to another repository.
originis conventional, not mandatory.- Multiple remotes can be configured.
Is `origin` a special Git keyword that must always refer to GitHub?
git fetch
git fetch downloads new objects and updates remote-tracking references without changing your current working branch. It is useful when you want to inspect incoming changes before integrating them.
git fetch origin
git log main..origin/main --oneline
git diff main origin/mainorigin/main. You can then inspect commits and differences before deciding whether to merge or rebase.git fetchdoes not normally modify your working branch.- It updates remote-tracking references such as
origin/main. - Fetching before integration gives you control over how incoming changes are handled.
What is a key property of `git fetch`?
git pull
git pull is commonly understood as fetch followed by integration. Depending on configuration, the integration can be a merge or a rebase. Because it combines multiple operations, understanding fetch separately is important when precise control is needed.
git pull --ff-only
git pull --rebase
git fetch origin
git merge origin/main--ff-only refuses non-fast-forward integration, while --rebase rebases local commits on top of fetched changes. Fetch plus merge makes the individual steps explicit.git pullperforms fetching and integration.- Pull behavior can be configured or specified explicitly.
- Use
git fetchwhen you want to inspect changes before integrating.
Why might a developer prefer `git fetch` followed by an explicit merge?
Pushing Changes
git push transfers local commits to a remote repository and updates remote references when permitted. Modern hosting platforms may reject pushes because of branch protection, authentication requirements, or non-fast-forward history.
A push does not normally send every object in your entire repository; Git transfers the objects required to update the remote.
When a history rewrite is genuinely required, prefer --force-with-lease because it helps avoid overwriting remote work that you have not seen.
git push -u origin feature/login
git push
git push --force-with-lease--force-with-lease is a safer history-rewrite mechanism than unconditional --force because it checks the expected remote state.- Push transfers commits and updates remote references.
- Protected branches can reject direct pushes.
--force-with-leaseis safer than blind--force.
Why is `--force-with-lease` generally safer than `--force`?
Pull Requests and Code Review
A pull request is a collaboration mechanism provided by platforms such as GitHub and GitLab. It allows a branch to be reviewed and discussed before integration. A pull request is not itself a Git object; it is a hosting-platform concept built around Git references and commits.
A good pull request is focused, explains the problem and solution, includes tests, and minimizes unrelated changes.
- Pull requests are platform-level collaboration features.
- Small focused pull requests are easier to review.
- CI checks and code review can be required before merging.
Is a pull request a native Git object?