Working with Remote Repositories

Objective. Students clone a remote repository, add and inspect remotes, push local branches to a remote, fetch and pull changes from a remote, and manage remote-tracking branches.

A remote repository is a version of your project hosted on a server—most commonly GitHub, GitLab, or Bitbucket—that your team shares. Working with remotes is the foundation of collaborative software development: you push your changes up so teammates can see them, and you pull their changes down so your local copy stays current.

Cloning a Remote Repository

Cloning creates a full copy of a remote repository on your local machine, including all commits, branches, and history. The command is:

```

git clone git@github.com:username/repository-name.git

```

Using the SSH URL (which starts with `git@`) requires that your SSH key is already added to your GitHub account—covered in Lesson 2. SSH is preferred over HTTPS in professional settings because it does not prompt for a password on every push or pull when keys are configured correctly.

After cloning, Git automatically creates a remote connection named origin pointing to the URL you cloned from. You can inspect all remote connections at any time:

```

git remote -v

```

This prints the fetch and push URLs for every remote. A freshly cloned repository will show `origin` twice—once for fetch, once for push—both pointing to the same URL.

Pushing a Local Branch to the Remote

When you create a new branch locally and want to share it, you must explicitly push it to the remote:

```

git push -u origin feature/about-page

```

The `-u` flag (short for `--set-upstream`) links your local branch to the remote-tracking branch `origin/feature/about-page`. After this one-time setup, you can run `git push` without extra arguments while on that branch. Always confirm the branch appears on GitHub before closing your terminal—check the repository's Branches dropdown on GitHub.com.

Remote-Tracking Branches

Git maintains remote-tracking branches such as `origin/main` and `origin/feature/about-page`. These are read-only snapshots of where the remote branches were the last time you communicated with the server. They live in your local `.git` folder and let you inspect the remote state without an active network call.

You can examine the history of a remote-tracking branch just like a local one:

```

git log origin/main --oneline

```

Fetching vs. Pulling

Understanding the difference between `git fetch` and `git pull` is essential for safe collaboration.

git fetch origin downloads all new commits and branch updates from the remote into your remote-tracking branches but makes no changes to your working directory or local branches. This is a safe, read-only operation. After fetching, you can review what changed:

```

git log --oneline HEAD..origin/main

```

This shows every commit that is on `origin/main` but not yet on your current branch—a preview of what you are about to integrate. When you are satisfied, merge manually:

```

git merge origin/main

```

git pull is a convenience command that runs `git fetch` followed by `git merge` (or `git rebase`, depending on configuration) in a single step. It is faster but gives you less opportunity to review incoming changes before they are merged.

When to use each approach:

Use `git fetch` + review + `git merge` when working on a shared branch in a team or before merging into `main`. This lets you catch conflicts or unexpected changes before they land.
Use `git pull` when you are working alone on a personal branch or when you trust that the incoming changes are straightforward and low-risk.

Safe Practices When Working with Remotes

Never force-push to a shared branch (such as `main` or `develop`) without team agreement. A force-push (`git push --force`) rewrites history on the remote and can destroy teammates' work.

Commit and push frequently on feature branches. Long-lived local branches that are never pushed create merge conflicts and make it harder for teammates to stay informed about your progress.

Verify your SSH connection before starting work each session if you are on a new or unfamiliar machine:

```

ssh -T git@github.com

```

GitHub will respond with your username if the key is recognized. This prevents wasted time debugging push failures caused by authentication issues.

Protect credentials. Never store passwords or API tokens in a repository. If a secret is accidentally committed, rotate it immediately—deleting the file in a later commit is not sufficient because the secret remains in history.

Workflow Summary

1. `git clone <SSH URL>` — get a local copy

2. `git remote -v` — confirm remote connections

3. Create a branch, do your work, commit

4. `git push -u origin <branch-name>` — share your branch

5. `git fetch origin` — download teammates' updates

6. `git log --oneline HEAD..origin/main` — preview changes

7. `git merge origin/main` — integrate when ready

Following this workflow keeps your local repository synchronized with the team and reduces the chance of destructive conflicts.

Key terms9

remote repositoryA version of a Git repository hosted on a network server (such as GitHub) that multiple collaborators can access to share code and history.

originThe conventional default name Git assigns to the remote a repository was cloned from; it stores the URL used for fetch and push operations.

git cloneA Git command that downloads a complete copy of a remote repository—including all history and branches—to the local machine and automatically sets up the origin remote.

remote-tracking branchA read-only local reference (e.g., origin/main) that records the state of a remote branch as of the last fetch or clone; it is updated by git fetch, not by local commits.

git fetchA Git command that downloads new commits and branch updates from a remote into remote-tracking branches without modifying the local working directory or active branch.

git pullA Git command that combines git fetch and git merge (or git rebase) in one step, immediately integrating remote changes into the current local branch.

git push -uThe command used to upload a local branch to a remote and set the upstream tracking link so that future git push and git pull commands on that branch work without extra arguments.

upstream trackingA configured relationship between a local branch and a remote-tracking branch that tells Git which remote branch to compare against, fetch from, and push to by default.

force-pushUsing git push --force to overwrite remote history; dangerous on shared branches because it can permanently discard teammates' committed work.

In class: Clone a provided GitHub repository using git clone with the SSH URL, inspect the remote configuration with git remote -v, and push a new local branch to the remote using git push -u origin feature/about-page; confirm the branch appears on GitHub. · Simulate a teammate's change by having a partner (or the instructor) push a commit to the main branch on GitHub; students run git fetch origin to retrieve the changes without merging, examine origin/main with git log origin/main, then run git merge origin/main to integrate the update. · Practice git pull (which combines fetch and merge) versus git fetch followed by git log --oneline HEAD..origin/main to preview incoming changes before merging; document in the lab log when each approach is preferable in a team setting.
Materials: GitHub accounts, SSH keys configured in Lesson 2, terminal, internet connection, lab log
Check: Instructor verifies the student's GitHub repository shows the pushed branch and a subsequent merged pull with correct history; lab log entry complete and signed off.

Practice check8

Answer each question, then check it. Nothing is recorded; this is your own practice.