github-workflow.txt

git-pull-request
https://github.com/jd/git-pull-request
"Once you've made your commits into a branch, just type:

git pull-request
This will:

Fork the upstream repository into your account (if needed)
Add your forked repository as a remote named "github" (if needed)
Force push your current branch to your remote
Create a pull-request for your current branch to the remote matching branch, or master by default."

A PR is updated with "push -f" if it exists already.
https://github.com/jd/git-pull-request/blob/master/git_pull_request/__init__.py#L317-L323
         _run_shell_command(["git", "push", "-f", remote_to_push, branch])
         pulls = list(repo_to_fork.get_pulls(base=target_branch,
                                             head=user + ":" + branch))
         if pulls:
             for pull in pulls:
                 LOG.info("Pull-request updated:\n %s", pull.html_url)
...
         else:
             # Create a pull request

"Difference with hub
The wrapper hub provides hub fork and hub pull-request as command line tools to fork and create pull-requests.
Unfortunately, it's hard to combine these tools in an automated implementation for a complete workflow. For example: If you need to update your pull-request, there's no way to identify existing pull requests, so calling hub pull-request would just open a new pull-request.
git-pull-request wraps all of these operations into one convenient tool."

https://github.com/jd/git-pull-request#workflow-advice
"Workflow advice

When sending pull-requests, it's preferable to do so from your own branch. You can create your own branch from master by doing:
$ git checkout -b myownbranch --track origin/master
This will checkout a new branch called myownbranch that is a copy of master. Using the --track option makes sure that the upstream source branch is written in your .git/config file. This will allow git-pull-request to know to which branch send the pull-request.

Since this is long to type, you can use an alias in git to make it faster:
$ git config --global alias.nb "!git checkout --track $(git config branch.$(git rev-parse --abbrev-ref HEAD).remote)/$(git rev-parse --abbrev-ref HEAD) -b"
This will create a git nb alias that will create a new branch tracking the current branch and checking it out. You can then use it like that:

$ git nb foobar
Branch foobar set up to track remote branch master from origin.
Switched to a new branch 'foobar'
"

https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/
~/.netrc
machine github.com
login <your-github-username>
password <your-token>

Documentation says "don't force push", however, an e-mail type of approach with reworking your commits and resending them is exactly that - a force push.
This approach is heavily used for kernel development.
https://help.github.com/articles/about-pull-requests/
"When pushing commits to a pull request, don't force push. Force pushing can corrupt your pull request."

At the same time in an article about rebasing:
https://help.github.com/articles/using-git-rebase-on-the-command-line/#pushing-rebased-code-to-github
https://help.github.com/articles/why-are-my-commits-in-the-wrong-order/
https://help.github.com/articles/resolving-merge-conflicts-after-a-git-rebase/
"Pushing rebased code to GitHub
Since you've altered Git history, the usual git push origin will not work. You'll need to modify the command by "force-pushing" your latest changes:"

A blog post that discusses problems with GitHub's approach:
why and how to correctly amend github pull requests | git push --force
https://blog.adamspiers.org/2015/03/24/why-and-how-to-correctly-amend-github-pull-requests/
"So really this whole blog post is a long way of saying:
When you force-push a new head for a pull request branch, GitHub handles it gracefully and automatically updates the pull request in the way you want."

"It’s almost like magic. For example, if a reviewer commented on two hunks in the original pull request, and your force-push effectively rewrites one of those hunks but not the other, then the GitHub pull request UI will get updated to say something like “@reviewer commented on an outdated diff” for the rewritten hunk, but any outstanding review comments on the changed hunk will be presented as before the force-push."

"Now don’t get me wrong – GitHub is not perfect. In some (but not all) ways, it is inferior to Gerrit’s review system which is better at exposing the complete history of the review cycle. I previously wrote another blog post examining GitHub’s review system in more depth. But in general, it’s usually plenty good enough."

"If you’ve previously been fed the mantra “git force-push is evil, don’t ever use it”, or the more specific version “don’t ever force-push to public branches” then hopefully you now realise neither are correct. There are many perfectly valid use cases for force push, otherwise the extremely clever developers who implemented it wouldn’t have bothered (and let’s face it, they know far more about git than you or I ever will)."

https://git-scm.com/docs/git-push#git-push---no-force-with-lease
"--force-with-lease alone, without specifying the details, will protect all remote refs that are going to be updated by requiring their current value to be the same as the remote-tracking branch we have for them."
https://developer.atlassian.com/blog/2015/04/force-with-lease/
"What --force-with-lease does is refuse to update a branch unless it is the state that we expect; i.e. nobody has updated the branch upstream. In practice this works by checking that the upstream ref is what we expect, because refs are hashes, and implicitly encode the chain of parents into their value."

http://willi.am/blog/2014/08/12/the-dark-side-of-the-force-push/

https://stackoverflow.com/questions/13148066/warning-push-default-is-unset-its-implicit-value-is-changing-in-git-2-0
"matching means git push will push all your local branches to the ones with the same name on the remote. This makes it easy to accidentally push a branch you didn't intend to.
simple means git push will push only the current branch to the one that git pull would pull from, and also checks that their names match. This is a more intuitive behavior, which is why the default is getting changed to this."

https://github.com/edx/edx-platform/wiki/How-to-Rebase-a-Pull-Request#force-push-to-update-your-pull-request
"As explained above, when you do a rebase, you are changing the history on your branch. As a result, if you try to do a normal git push after a rebase, Git will reject it because there isn't a direct path from the commit on the server to the commit on your branch. Instead, you'll need to use the -f or --force flag to tell Git that yes, you really know what you're doing. When doing force pushes, it is highly recommended`that you set your push.default config setting to simple"

"In Git 2.0, this behavior was changed to only push the current branch, but older versions still have this unexpected behavior."