Ask HN: How to guide contractor to properly use Git branches and pull requests? | Hacker News Reader

Ask HN: How to guide contractor to properly use Git branches and pull requests?

2 pointskfarr3 comments

I work on a side project with paid contractors. One in particular is very skilled with our target platform but I am spending lots of time trying to coach him on proper use of Github. He submits PRs that have lots of weird merging issues [1] that are too complicated to unpack and I end up creating new branches to cherry pick his contributions manually.

Has anyone faced this situation with contributors before? Is there a reliable 30 min guide for how to use branches and PRs for someone who is "just not getting it" so far?

https://imgur.com/a/xNu8RLr

View on HN

My tuppence worth of thoughts...

#1. Insist on hunked, with appropriate commit messsage, commits for their PR - can simplify code review

#2. Use git rebase from master to their branch - where they fix any merge conflicts - before submitting PR

#3. Make use of git commit --amend for updates that dont need to leave a trail of noise while working towards #1 - you still have all that noise in the reflog if you really need it

#4. Ensure git rebase --i is used to ensure no commit history noise prior to their PR

#5. Any formatting amendments should be done pre/post PR

#6. Use pre-receive hooks to block PR and reduce any unnecessary forgetfulness of the above points

At the end of the day, they should be following a sane set of coding standards that the project has outlined - which everyone should adhere to, but also be involved with setting, and then following.

There are plenty of coding standards out there, find one that fits your project best, and modify accordingly - be sure create a repo that provides guidance to the standard and keep it up to date.

> He submits PRs that have lots of weird merging issues [1] that are too complicated to unpack and I end up creating new branches to cherry pick his contributions manually.

You could start by not doing this and instead working your way together to fixing the problems because that's literally what PR's were made for, even more so on GitHub where unlike in email, you can discuss it in almost real time. It looks like you have as much to learn as him, because even if you have to make 500 commits to fix all issues, there's this git feature called commit squashing that helps you clean things up even after the fact, and branches, especially personal ones, can easily have their whole history overwritten without fear as many times as you need it.

https://learngitbranching.js.org

Reply on news.ycombinator.com