I’ve been working with GitHub pull requests and I’m struggling with the proper workflow. Here’s my situation:
- I fork a repository and make various changes
- Some changes are useful for the main project, others are just for my personal use
- I want to submit only specific changes to upstream while keeping all my modifications
The problem is when I make personal changes in my master branch, they get included in future branches. How do I properly separate the changes I want to contribute from my personal modifications?
For example:
- I made fix X and submitted a PR (accepted)
- Then I added feature Y (personal use only)
- Now I want to submit bugfix Z without including feature Y
What’s the correct branching strategy to keep my complete version while being able to submit clean pull requests? Should I create branches from upstream master instead of my own? I want to make it easy for maintainers to review and merge my contributions.
yep, totally agree! keeping master clean is key. i usually have a personal branch for my stuff. when it’s time to contribute, just branch off the upstream master. for bugfix Z, always sync with upstream before. trust me, simplicity is the way to go!
You need to set up multiple remotes properly. I always configure my fork with both origin (my fork) and upstream (original repo) right from the start. Here’s what I do differently - I keep master synced with upstream/master and use separate branches for different stuff. I’ve got a long-running branch for my personal changes that I rebase onto updated master regularly. When I’m contributing back, I always create feature branches straight from the latest upstream master - never from my personal work. This way each PR only has the changes I actually want to contribute. For your bugfix Z situation, fetch from upstream first, then branch off upstream/master instead of your local master. After the PR gets merged, I pull those changes into my personal branch with a rebase. This workflow has saved me tons of time dealing with cherry-picking and merge conflicts. Plus maintainers love getting clean, focused contributions without your personal stuff mixed in.
Treat your fork’s master branch as a mirror of upstream master, not your personal dev branch. I learned this the hard way after submitting messy PRs early on. Here’s what works: keep a separate branch for your personal stuff - call it ‘personal’ or ‘local-mods’. Keep master clean and sync it regularly with upstream. When you need to fix a bug or add a feature for contribution, branch off your clean master, not your personal branch. For your bugfix Z scenario, branch from upstream master, implement just the bugfix, and submit the PR. This prevents personal code from leaking into contributions. The workflow: upstream master → your master → feature branches for PRs, with your personal branch maintained separately. You can rebase your personal branch onto updated master occasionally to grab accepted changes. This separation makes reviews cleaner and maintainers love focused commits.