search

TeraTermProject / osdn-download

64 stars 5 forks source link

GitHub の使い方を決める #13

Open nmaya opened 1 year ago

nmaya commented 1 year ago

trunk の名前

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

ワークフローの策定

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

コミットの方法

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

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

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

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

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

外部からの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

zmatsuo commented 1 year ago

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

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

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

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

ブランチをマージしていく履歴も main に入れる前に main に rebase すると結局1本になります。 (mainより古い修正履歴が1本になるのが私は好きかな) PRを受けたりしてマージしたり、自分の修正を直に入れたりして 鬼車のようなブランチ具合になるのかなと思います。 #13_20231004 ↑ 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 commented 1 year ago

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" を使っていて、こちらの方が慣れています。 cakephp

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 commented 1 year ago

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 commented 1 year ago

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

ありがとうございます。

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

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

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

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

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

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

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

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

nmaya commented 1 year ago

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

zmatsuo commented 1 year ago

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

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

zmatsuo commented 1 year ago

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

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

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

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

nmaya commented 12 months ago

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

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

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

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

そうですね。

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

nmaya commented 12 months ago

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

になりますか？

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

zmatsuo commented 12 months ago

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

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