README: perhaps briefly explain how to work with a fork, including pushing a change to the fork?

[thepudds]

In the README, maybe very briefly explain how to use a fork you created in GitHub, how to push a change back to that fork on GitHub, and then mention you can use that to open a PR on the original project?

For example, if you fork rsc.io/quote in the GitHub web interface to github.com/thepudds/quote, then use gohack + git to use that fork:

cd $(mktemp -d)                         # create an initially empty test module
go mod init testmod        
go get rsc.io/quote                     # not needed if already in go.mod

gohack get -vcs rsc.io/quote
cd $HOME/gohack/rsc.io/quote
git remote rename origin upstream
git remote add origin https://github.com/thepudds/quote
git remote -v
git checkout -b test-branch-on-my-fork 
touch new.file                          # make your edits
git add -A
git commit -am "test commit"
git push origin                         # push your changes

# then if desired, open a PR to the original project in the GitHub web interface

I purposefully modeled those steps above at least loosely on https://blog.sgmansfield.com/2016/06/working-with-forks-in-go/ because that is a somewhat common resource handed out to people who are new to Go.

@rogpeppe mentioned elsewhere that his personal workflow is usually slightly simpler than that:

cd $(mktemp -d)                         # create an initially empty test module
go mod init testmod        
go get rsc.io/quote                     # not needed if already in go.mod

gohack get -vcs rsc.io/quote
cd $HOME/gohack/rsc.io/quote/
git remote add rogpeppe https://github.com/rogpeppe/quote
git checkout -b test-branch-on-my-fork 
touch new.file                          # make your edits
git add -A
git commit -am "test commit"
git push origin

I'm not suggesting either of those be the exact text, but I am suggesting that at least mentioning a sample set of steps would be highly beneficial.

Also, people use git in many ways, so I'm not suggesting anything here be presented as "the one true way to do it", but some type of text like "There are multiple ways to do this, but one approach is ..." means someone new to modules and gohack can follow those steps, while someone more advance can map those steps to however they prefer to work with git (but doing that after having the benefit of at least understanding how gohack works with one git approach, even if it is not their personally preferred git approach).

One nuance is often someone will be using some specific version of a dependency to start in their day-to-day use (e.g., foo v1.2.3). gohack get -vcs foo will get that version by default, but that might not always be what you want if you are planning on sending a PR.

Finally, gohack probably could be tweaked to make some of this simpler, but might be easiest to start by adding something along these lines to the README based on gohack as it exists today.