アカウント名:
パスワード:
分かりやすくドキュメント化されてないと初見は戸惑うだけだし。GitHubにローカル・ルールに沿ったチェックやワークフロー機能が追加されると良いかも。
masterではなく、テスト用のブランチにマージしろこのルールを無視したら、一度目は警告で済ませるけど、二度目は雇用契約を解除するなんてルールがある
ローカルルールに沿っていなければマージやプルリクできない仕組みとかあってもいいかも
> 一度目は警告で済ませるけど、二度目は雇用契約を解除するなんてルールがある
それこそ GitHub でも、ブランチの保護と承認マージの機能はあると思うんだけど、なんでルールで縛るんですかね?
> ローカルルールに沿っていなければマージやプルリクできない仕組みとかあってもいいかも
これは commit hook とか merge hook がその「仕組み」なんじゃないん?
問題はやりたい事がhookで完結できない点。テストか否かとかhookじゃ判別できない。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
ローカル・ルールの話か。 (スコア:0)
分かりやすくドキュメント化されてないと初見は戸惑うだけだし。
GitHubにローカル・ルールに沿ったチェックやワークフロー機能が追加されると良いかも。
某クラウド会計ソフトを作ってる会社では (スコア:0)
masterではなく、テスト用のブランチにマージしろ
このルールを無視したら、一度目は警告で済ませるけど、二度目は雇用契約を解除するなんてルールがある
ローカルルールに沿っていなければマージやプルリクできない仕組みとかあってもいいかも
Re:某クラウド会計ソフトを作ってる会社では (スコア:1)
> 一度目は警告で済ませるけど、二度目は雇用契約を解除するなんてルールがある
それこそ GitHub でも、ブランチの保護と承認マージの機能はあると思うんだけど、
なんでルールで縛るんですかね?
> ローカルルールに沿っていなければマージやプルリクできない仕組みとかあってもいいかも
これは commit hook とか merge hook がその「仕組み」なんじゃないん?
Re: (スコア:0)
問題はやりたい事がhookで完結できない点。
テストか否かとかhookじゃ判別できない。