I maintain a main repository that has been forked by several contributors. Each fork contains multiple commits with various changes and improvements. I need advice on the proper workflow for reviewing and selectively incorporating these commits.
Currently, I create branches named after each contributor and merge everything, then manually revert the changes I don’t want to keep. This works but feels clunky and inefficient.
What I’m looking for is a clean way to examine each individual commit from different forks and choose which ones to include in my main branch. I want to preserve the commit history properly while maintaining control over what gets merged.
Is there a recommended Git workflow for this scenario? Which tools or GUI applications work best for visualizing commits across multiple forks? I’ve heard about using interactive rebase but I’m not sure if that’s the right approach here.
I’m also wondering about the trade-offs between cherry-picking versus merging in this context. Any guidance on maintaining proper Git history while being selective about which changes to accept would be helpful.
just use github’s web interface - way easier than cherry-picking from command line. you can review each commit in the pr individually and create a new branch with only what you want. saves tons of time and avoids those annoying cherry-pick merge conflicts.
Interactive rebase is perfect here, but you’re going about it wrong. Don’t merge everything first. Instead, fetch commits from each fork as separate remotes and run git rebase -i on a feature branch with just the commits you want to check out. Create a temp integration branch where you can reorder, squash, or drop commits before they hit your main branch. This beats cherry-picking because you see how commits interact during the rebase. Way better than your current workflow since you’re being selective upfront instead of cleaning up after. One heads up though - if contributors have messy history with tons of ‘fix typo’ commits, either ask them to clean their branches first or be ready to squash related commits during the rebase.
I’ve been doing this for years with open source projects. Cherry-picking works great, but there’s a cleaner workflow than what you’re doing now. Don’t merge entire branches - instead, add each contributor’s fork as a remote with git remote add. Then run git log --oneline --graph --all to see all commits visually without creating temporary branches everywhere. Create one staging branch and cherry-pick commits one by one. You’re choosing what goes in upfront instead of adding everything then removing stuff later. Your history stays clean and you won’t get those annoying revert commits cluttering main. Pro tip I learned the hard way: always test your cherry-picked commits together in staging before merging to main. Individual commits might work fine but break when combined, and it’s way easier to fix conflicts in isolation.