If you've ever dealt with a team where different people had different versions of linters installed, you'll quickly realize that you should also lock your tools.
Before Go 1.13
Before Go 1.13 the recommended solution was to use tools.go file like this:
We have a s3cr3t repository (ok, you can probably find it, but don't peek) that we will announce right before the contest start. It's some of the exercises that were literally and liberally stolen from literally and liberally stolen from the Exercism.io Go track.
Fork this repo, solve the exercises, and submit a pull request TO THAT REPO, NOT EXERCISM/GO for judging with the description containing your personal Tally (see rubric). No more commits after the time limit, but you can fuss with your Pull Request more after the time is up (like counting your score).
Please notify the judges in Slack the #go-contest channel which one, if any of your fully 100% passing solutions, should be considered for Special Awards:
Greased Lightning Performance Award - for exercises with benchmarks showing that you made yours go so dang fast
Elegant Étude Award - for exceptional cleverness, radical simplicity, and amazing aesthetics to your solutions.
From Apache Arrow Git Tips
I’m used to working with git merge and this has made life difficult for me when working with Apache Arrow because it doesn’t use a merge model and pull request branches often need to rebased against master and force pushed.
There are numerous ways to work in this model but this article documents the approach I use, based on some guidance I was given on one of my PRs. I’m documenting this for my own benefit but hopefully it helps others too.
Creating a Fork
When you first fork the repo, you need to set up the upstream apache git repo as a remote. I prefer to name this remote apache rather than upstream since it is more explicit, especially if I add other remotes (such as other contributors forks).