GitHub の使い方を決める

[nmaya]

trunk の名前

trunk のままでよいか。それとも main にリネームしたほうがよいか。

ワークフローの策定

修正の流れとブランチの使い方

• FreeBSD（昔は？今も？）のように、CURRENT->RELENG_13, RELENG_13->RELENG_13_1 と修正が流れていく（上のほうが自由にコミットできる・下の方へ反映するかどうか取捨選択がある）
• 今までのように trunk / 4-stable を修正し、ある時点の trunk / 4-stable がリリースになる
• Git-flow：開発集約用のdevelop ・開発機能ごとのfeature・リリース準備用のrelease・リリース用のmasterを持つ
• GitHub Flow：開発集約用のmaster・開発機能ごとのfeatureを持つ

コミットの方法

• 今までのように、直接 trunk / 4-stable に修正を入れていくのか。
• それとも修正は必ずブランチを作ってPRするのか。trunk / 4-stable をプロテクトするのか。

レビューが挟めるのでPRを使ったほうがいいように思う。「修正とドキュメント（変更部分について、また更新履歴）がすべて含まれているか」のチェックができる。

ブランチに対して AppVeyor でビルドをかけられたら、チェックもしやすくなるのではないか。
ほかの修正が混じらないバイナリを作れるはず。
（ビルドのたびにどのブランチをビルドする設定になっているのか確認/変更が必要になりそうだが）

修正と「issue」「コミット」「PR」間のリンク

このようにするとリンクできる。

• GitHub で issue を作る
• （ローカルに clone する）
• 派生元ブランチから修正ブランチを作る
• 修正を書く
• コミットする
  • コミットログに issue の番号を書く
• ブランチを push する
  • GitHub（リモート） に修正ブランチができる
  • Code ビューアのコミットログから issue に飛べる
  • issue にコミットIDの履歴が残る
• PR を作る（派生元ブランチ <- 修正ブランチ）
  • ブランチの選択により、PR では「コミットIDの履歴」「変更差分」が見られる
  • レビュー（チェック）する（してもらう）
• PR をマージする
  • issue にマージ履歴が残る
• 修正ブランチを削除する
• issue を Close する

「Git では push したら rebase してはいけない」と言われている

• 修正を他の人に見せるためには local から remote(GitHub) の feature ブランチへ push しなければならない
  • feature から main にマージするときに main が進んでいたら rebase するのは許されるのか？
• 誰かが作った feature ブランチは別の人は触らないことで、rebase しても誰にも迷惑をかけないようにするのか？
  • それでは共同開発できない？
  • 別の人が触るときは、feature ブランチからさらに fork するのか？

外部からのPRの扱い方

• 修正が十分でない（ドキュメントがないなども含む）場合にどう受け入れるのか？

参考になる？

https://qiita.com/riku929hr/items/15415d34ee5fc412c126
https://qiita.com/hitochan777/items/ea08df354b42be57e5fc
https://supersoftware.jp/tech/20221021/17928/
https://git.command-ref.com/basic-git-flow.html

TODO

• wiki:コミットルールを更新

[zmatsuo]

trunk のままでよいか。それとも main にリネーム
一般的な main がよさそうです。

GitHub Flow がいままでの svn と似ていてやりやすそうです。

今までのように、直接 trunk / 4-stable に修正を入れていくのか。
メンバーは svn と同様な運用で直接でもokでどうでしょう?

それとも修正は必ずブランチを作ってPRするのか。
PR作っても直接修正を入れてもよさそうです。

ブランチをマージしていく履歴も main に入れる前に
main に rebase すると結局1本になります。
(mainより古い修正履歴が1本になるのが私は好きかな)
PRを受けたりしてマージしたり、自分の修正を直に入れたりして
鬼車のようなブランチ具合になるのかなと思います。

↑ TortoiseGitのイメージです。

trunk / 4-stable をプロテクトするのか。

これはぜひそうしましょう。保護設定ですね。

誰かが作った feature ブランチは別の人は触らない

誰かが修正中のソースは触らないほうが安全です。
名前/feature(zmatsuo/featureなど) のようにブランチ名を付けるなどすると
お、こいつが修正中か、となりやすいので事故になりにくいと思います
自分が作業中のブランチをrebaseや削除されると困りますが、
気づいたときにローカルに別の名前をつければ何とかなります。

別の人が触るときは、feature ブランチからさらに fork するのか？

feature1 ブランチの途中から枝分かれして
feature2 ブランチなど別名を付けて枝分かれして
そこで作業すれば大丈夫だと思います。
こっそり修正ならfork、修正中も見てもらったりテストしてもらうときは
ブランチを作る、でしょうか。
まあ push しなければこっそり修正となりますね。

rebase しても
誰にも迷惑をかけないようにするのか？
「Git では push したら rebase してはいけない」と言われている

rebaseしても大丈夫じゃないかなと思います
リモートリポジトリが変更されても、
ローカルブランチは修正されないですし
リモートをローカルに反映(fetch)しても、
ローカルが壊れることはないと思います。
枝分かれして別のブランチを作っていれば、rebaseや削除の影響を受けません。

外部からのPRの扱い方

ちょっとした修正ならそのままマージ、
大きな機能追加ならマニュアルも欲しくなります。
その時相談でしょうか。レビュー機能使えれば便利そうです。
https://duckduckgo.com/?q=github+merge+review+approve

[nmaya]

trunk のままでよいか。それとも main にリネーム

一般的な main がよさそうです。

私も main で大丈夫です。

今までのように、直接 trunk / 4-stable に修正を入れていくのか。
それとも修正は必ずブランチを作ってPRするのか。

メンバーは svn と同様な運用で直接でもokでどうでしょう?
PR作っても直接修正を入れてもよさそうです。

これには、これまでの傾向から反対します。

ttssh2-devel 4606:
・ある修正がリリースをまたぐ問題なので変更履歴の執筆が必要である
・コードの修正が行われたときにドキュメントの修正が必要である
ttssh2-devel 4609:
現状に誤りのないドキュメント、でしょうか。
ですがドキュメントは修正入れてない状態です。
ダイアログのUI、とそれに関連する翻訳(lngファイル)も
検討が必要ですね。
ttssh2-devel 4625:
・メニュー項目、ダイアログの項目すべて
・コマンドラインオプション(一部の意図的に隠している物を除く)
・マクロコマンドすべて
・動作に現れる変更の履歴

ttssh2-devel 4727:
何度か書いていますが、リリース直前に
- trunk と 4-stable で同期をとるべきものが取れていない
- コードは修正されているがドキュメントや変更履歴がない
というものを調べ始めると、負担がかかったり見落としたりします。
メンバーの誰もがリリース物件を作成する可能性があるならなおさら、
未対応な件を誰もが容易に確認できる状態にしておくのが望ましいと
思います。

Tera Term 5.0 リリース時:
日本語にだけあり英語にはないドキュメントの翻訳に時間がかかった。

これらは依然として、リリースまで放置されがちです。
main を素早くリリースできる状態にしておくためには、ブランチで耳がそろうまで作業して、そのあと main にマージするのがよいです。

ブランチをマージしていく履歴も main に入れる前に
main に rebase すると結局1本になります。
(mainより古い修正履歴が1本になるのが私は好きかな)

それは GitHub の "Rebase and merge" または "Squash and merge" を使うということでしょうか。
私は日頃 "Create a merge commit" を使っていて、こちらの方が慣れています。

rsa-sha2 のときのように、一つの feature であり、かつそれぞれの修正を明確に分けて保存する意義がある場合には、"Create a merge commit" のほうがよいと思います。

ホスト鍵方式: r10064 (分離), r10065 (rsa-sha2-256/512 対応)
ユーザ認証: r10064 (分離), r10066 (SSH_MSG_EXTINFO 対応), r10068 (rsa-sha2-256/512 対応), r10070 (Pageant rsa-sha2-256/512 対応), r10073 (ホスト鍵確認中 SSH_MSG_EXTINFO)
その他の修正: r10063, r10067, r10069, r10071, r10072
ドキュメント: r10074 (変更履歴), r10075 (HostKeyOrder)

保護設定

これはコラボレーターに対する制限で、メンバーには効かないようですね。
有効にした方がいいですが、効力を発揮するのは人が増えてからですね。

誰かが作った feature ブランチは別の人は触らない

誰かが修正中のソースは触らないほうが安全です
rebaseしても大丈夫じゃないかなと思います

そのかわり本人は rebase してもよい、となるでしょうか。
ここで言う rebase は GitHub の "Rebase and merge" のことではなく、feature ブランチを切ったときより main が進んでいる場合に、feature ブランチの派生元を現在の main に移動することです。（おそらく r8306 がこれに相当）
他人のコードになにか見つけて直したかったら、feature からさらにブランチを切って修正する、でいいでしょうか。その後 PR を投げて feature にマージしてもらう必要がありますね。

レビュー機能使えれば便利そうです。

差し戻したときに、言うとおり直してくれるといいですね。

大きな機能追加ならマニュアルも欲しくなります。

バグ修正ならそれだけで変更履歴があります。

[zmatsuo]

main を素早くリリースできる状態にしておくためには、ブランチで耳がそろうまで作業して、そのあと main にマージするのがよいです。

そうですね、未対応な件を誰もが容易に確認できる状態にするには
ブランチで管理しておくのがよさそうです。
すみません。

私は日頃 "Create a merge commit" を使っていて、こちらの方が慣れています。

"Rebase and merge" と思っていました
(コミットをまとめると "Squash and merge" ですね)。
"Create a merge commit"でやってみましょう。

そのかわり本人は rebase してもよい、となるでしょうか。

rebaseしてよいと思ったのですが、
他の人から見てブランチが見えなくなって困ることがあるかもしれないです。
svnにはrebaseはなかったのでわからないところがありますね。
そのうち試してみましょう。

他人のコードになにか見つけて直したかったら、feature からさらにブランチを切って修正する、でいいでしょうか。

そんな感じになると思います。

"Create a merge commit"で進めて、わからないことがあったら
相談して決めましょう。

[nmaya]

そうですね、未対応な件を誰もが容易に確認できる状態にするには ブランチで管理しておくのがよさそうです。 すみません。

ありがとうございます。

そのかわり本人は rebase してもよい、となるでしょうか。

rebaseしてよいと思ったのですが、 他の人から見てブランチが見えなくなって困ることがあるかもしれないです。 svnにはrebaseはなかったのでわからないところがありますね。 そのうち試してみましょう。

ブランチを削除するのは構わない（先端がなくなるので追跡できなくなる・コミット自体は消えていない）のですが、rebase してコミットがなくなると、そのコミットから生えた別のブランチがどうなるのかわかりません。

他人のコードになにか見つけて直したかったら、feature からさらにブランチを切って修正する、でいいでしょうか。

そんな感じになると思います。

「他人の修正が明らかに間違っているのでえいやと直してしまいたい」という場合はありそうで、これがだめとなると「main を多人数で直接いじる運用」では同じ問題が起きるわけなので、git pull --rebase でローカルを更新して解決すれば回避できるような気がしてきました。（今までの svn update と同じ）
また、「ブランチを切って修正したがPRを取り込んでもらえない」というパターンもありそうです。

"Create a merge commit"で進めて、わからないことがあったら 相談して決めましょう。

マージの方法はこれで始めてみましょう。

[nmaya]

こんな感じでどうでしょうか。

• できるだけissueを切って、コミットログにissue番号を書くとよい
• ソースとドキュメントにまたがる修正はブランチを切る
• 直したブランチでAppVeyorにかけてバイナリを作れる
• マージは Pull Request で行う
  • "Create a merge commit" を用いる
• マージがコンフリクトしたらローカルでrebaseして再度pushしてマージする

[zmatsuo]

よさそうです。
そのように進めましょう。

git使って開発している人がたくさんいて何とかなっているので
たいてい大丈夫にちがいないです。

[zmatsuo]

これぐらいの小さな修正なら
mainに直接入れてしまっていいかなと思います。
TeraTermProject/teraterm#15

直接入れるかブランチを切るかは

ソースとドキュメントにまたがる修正はブランチを切る
これを基準にすればよいですね。

しかも Email にメールを入れてコミットしまいました。
こういう時どうするのが定石なのかな・・。

[nmaya]

これぐらいの小さな修正なら mainに直接入れてしまっていいかなと思います。 TeraTermProject/teraterm#15

直接入れるかブランチを切るかは

ソースとドキュメントにまたがる修正はブランチを切る

これを基準にすればよいですね。

そうですね。

• 「ひとつの件だが内容ごとにコミットに分ける」場合（#2-move_to_github とか、rsa-sha2 のとき）
• 「この件の修正がこのコミットで終わるか分からない」場合（意見を求めて改善が予想されるなど）

もブランチを切るほうがよいです。

[nmaya]

理屈だけ言うと、該当のコミット a2ab77f79321caef35cffbac66f3d3f8935d0118 はマージされて親になっているので

• 子供である 0d83f80a03866079f863a0a21a0df4af59f4d459 の削除
  • main をずらす
• a2ab77f79321caef35cffbac66f3d3f8935d0118 の削除

になりますか？

GitHub で参考になりそうなのはこのへんでしょうか？割とおおごとな気がします。

• https://zenn.dev/kagerou_ts/books/kts-github-use-tips/viewer/delete-commit
• https://docs.github.com/ja/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository

[zmatsuo]

間違ったと思ったとき、すぐ修正すればよかったですね。
パスワードといった困ったものというわけではないのと
別のコミットも入っているので
今回のコミットはそのままにしておこうと思います。

ただ、間違って入ってしまったメールアドレス自体も
間違っていて2重に間違っています。かなり残念です。