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.

Leave a Reply