‘Tis the season of many pull requests, so today I thought I’d share a tip for avoiding common pull request mistakes that arise from having an out of date master branch.
Becoming a repeat contributor of a project is one of the best things that can happen to anyone taking part in Hacktoberfest – but there are some things to look out for when you’re making a pull request that isn’t the first on a freshly forked repo. Today I’ll share my tips for making sure that every pull request is as good as the first one!
To do more than a fly-by, one-off contribution, there’s one small addition to your usual workflow that can make a very big difference. When you get set up for contributing to a new repo, try this:
- Fork the repo to your own account
- Clone that repo to your computer
- Now add the original repo as an “upstream” remote
That magical third step, before you start making changes or creating a branch or even setting up the project to work locally, will give you the link you need to collaborate with a project more than once.
With this upstream remote in place, it is easier to keep your local main or master branch in sync with the one on the upstream project.
Remember that you should never commit to your local
mainbranch directly. It should always follow the state of the main project, so that you can branch from it and not include any additional changes by mistake!
When you come to make the second contribution, update your local main or master branch before creating the branch you will be working on.
git checkout main
git pull upstream main
That’s it! Check the GitHub URLs for the project and your own fork – and you will see that your main branch is up to date with the project one.
Now you can go ahead and make another change … and another … and another. Happy Hacktoberfest!