GitHub Forks and Remote Repositories
Posted on September 1, 2020 in Git, GitHub by Matt Jennings
GitHub vs Git
- Open source version control software
- Repository hosting
- Pull requests
- 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.
- 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.
- 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
- 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
- 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.
- From a remote repo to a local repo.
- Under the hood:
git pull = git fetch && git merge
- 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
- Git doesn’t automatically push local tags to a remote repo.
- To push tags:
git push <tagname>
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
- 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
To Top ↑