Git / GitHubがよくわからなかったので整理してみた。
元々の整理の発端はなぜベンダーが納品してくる成果物が頻繁に先祖返りするのかわからなかったから。GitHubで管理しているというが、なぜだ〜って感じ。調べてみたところ、Subversionと昔使われていたツールにしても最近使われているGitHubないしは類似サービスにしても人に依存する部分もあり先祖返り完全防止機能はないことがわかった（管理を間違えれば先祖返りはありうるということ）。
GitHub はコマンドベースで動く Git が使いやすくなっているサービスということも理解できた（メールで言うとGmail的な感じ）。この手の話題はネット上の資料だと日英問わず間違っている物や不完全な説明も多そうで、実際のところ私のまとめもただしいかどうかわからない状況。様々な文献をベースに図式化してみると次のようになった。
・リモートレポジトリと呼ばれるものが正、作業用としてローカルレポジトリがある。
・ローカルにはUpstreamブランチ、Trackingブランチと呼ばれる中継がある（一つのブランチ名が両方を指していることがあるが、別々にすることもでき、このことについて言及されていない記事が多い）
・実際のローカルで作業を行うブランチは中継目的のUpstreamブランチ、Trackingブランチとは異なる
・pull = fetch、merge の同時実行
・pullとrebaseの違いは他の記事を参照、履歴の残し方の問題でrebaseだと簡略化されたイメージ（履歴は少なくなるがバグが発生するとどこが原因だか追いづらい）
先祖返り問題・・・結局なんで？防止策？
これについてはネット検索してもいまいち確実な理由がわからなかったが、いくつかのパターンは考えられた。
・fetch+merge/pull/rebaseからmerge, pushで確定するまでの間で同一ファイルの複数作業（複数人または同一人だが別々の端末など）が発生の原理原則
・コード数が多いファイルで起きやすい（コード数が小さいファイルに分割されている環境では同一人物ないしは異なる人物が一つのファイルで同時多発的に作業をするケースが少なくなるため（競合発生が低くなり、commmitの撤回（reset）による影響度合いも必然的に少ない））
・意図してreset を流すが（その後必要でpushし上書きもするが）、意図された事項以外も元に戻ってしまうケースがありうる
・merge/push時にエラー/警告がでて解決が面倒である際に
git push 時に-f ないしは --force で強制上書きできる（複数人作業でローカルにコピーをしまくりこれをされると先祖返りが極めて発生しやすい）
防止策：
・一つのソースファイルで全てを抱え込まないようにする
・まずは単独作業者自身においてこまめにcommitさせる
・互いに声をかけ短時間の間隔で、こまめにmerge/pull, pushする
ベンダーに依頼するとなるとこんな感じですかね。。。？
参考資料
https://qiita.com/wann/items/688bc17460a457104d7d
https://teratail.com/questions/79531
https://kray.jp/blog/git-pull-rebase/
https://blog.codecamp.jp/git_rebase
https://www.clear-code.com/blog/2016/9/2.html
https://www.ricksoft.jp/blog/archives/9483/
https://dev.classmethod.jp/tool/git/development-flow-with-safty-merge/
https://frasco.io/why-you-should-stop-using-git-rebase-535fa30d7e25
https://qiita.com/seri1234/items/e651b3e108a695a92809
https://yu8mada.com/2018/08/11/how-to-confirm-and-set-up-tracking-branches-in-git/
https://codeday.me/jp/qa/20190104/109718.html