Blog

GitHub Forks and Remote Repositories
Posted on September 1, 2020 in Git, GitHub by Matt Jennings

GitHub vs Git

Git

• Open source version control software

GitHub

• Repository hosting
• Pull requests
• Forks

Remotes

• A remote is a git repository that is stored somewhere else – on the web, in GitHub, etc.
• origin is the default name git gives to the server your cloned from.
• Cloning a remote repository from a URL will fetch the whole repository, and make a local copy in your .git folder.
• You have different privileges for a remote:
  Read/write for some and Read Only for others.

Viewing Remotes

• git remote -v

Fork

• A fork is a copy of a repo that’s stored in your GitHub account.
• You can clone your fork to your local computer.
• To merge code from a fork but into a repo use a pull request.

Upstream

• The upstream repo is the base repo you created a fork from.
• This isn’t set up by default, you need to set it up manually.
• By adding an upstream remote, you can pull down changes that have been added to the original repo after you forked it.
• Example code:
  git remote add upstream https://github.com/ORIG_OWNER/REPO.git

Tracking Branches

• To checkout a remote branch, with tracking:
  git checkout -t origin/feature
• Tell Git which branch to track the first time you push:
  git push -u origin feature
• Show which upstream or remote branch I’m tracking on my local branch:
  git branch -vv

Fetch

• Git fetch is important for keeping your local repo up to date with a remote.
• It pulls down all the changes that happened on the server.
• But, it doesn’t change your local repo.

Pull

• From a remote repo to a local repo.
• Under the hood:
  git pull = git fetch && git merge

Push

• From a local repo to a remote repo.
• git only allow you to push if your changes won’t cause a conflict
• To see commits which haven’t been pushed upstream yet use:
  git cherry -v

Git pull –rebase

• Git pull –rebase will fetch, update your local branch to copy the upstream branch, then replay any commits you made via rebase.
• When you open a PR, there will be no unsightly merge commits!
• A way to keep work cleaner:
  git pull origin/master --rebase

Note: Tags

• Git doesn’t automatically push local tags to a remote repo.
• To push tags:
  git push <tagname>
  OR
  git push --tags

Contributing to Open Source Projects – Pull Requests

• Before opening a PR:
  • Keep commit history clean and neat. Rebase if needed.
  • Run projects tests on your code.
  • Pull in upstream changes (preferable via rebase to avoid merge commits)
  • Check for a CONTRIBUTING (.md/.txt) in the project root
• After opening a PR:
  • Link to any issues that your pull request might fix
  • Check back for comments from the maintainers

Advice

• Encourage developers to work on their own forks of a repo.
• Mistakes are less likely to happen if no one is pushing directly to the “source of truth” for your codebase!
• You can rebase and force push freely to your own origin, as long as no one else is cloning your branch.
• It’s easier to merge, than rebase, when accepting a pull request.