squash and mergeしか使ってないけど全く困ってない
こういうことはレポジトリ構成・ワークフローと密接に紐づいているので、そういう前提を抜きにはどれがいいとかはいうことはできない。が、自分はいわゆるsquash and mergeのみの環境しかほとんど経験がないし、それで困ったことが一度もない、という話をしておきたいので書いておきたい、ので書いておく。 squash and mergeのメリットは書いてある通りで、基本的にPR内の細かい修正というのはゴミみたいなコミットが多く、メッセージも雑なことが多いので、それをコミットログに残しておくのは嫌だということがある。それよりは意味のある単位のコミットを残しておきたいし、それの単位はPRで行うのが良い、ということだ。 “Google-style” workflow デメリットの方は、いわゆるfeature branchというワークフローで顕在化する問題であると思う。で解決策はあり、それはワークフロ
ギットハブ、「マスター」の用語を変更--BLM運動がきっかけに
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます GitHubの最高経営責任者（CEO）は、奴隷制度に関係する用語を不必要に使用するのを避けるために、「マスター」という用語を「メイン」などの中立的な用語に変更する取り組みを進めていることを明らかにした。 既に、GitHub以外にも多くのIT企業やオープンソースプロジェクトが、黒人コミュニティーが不快に感じる可能性がある用語をなくす活動に対して支持を表明している。 これには、「マスター」や「スレーブ」を「メイン、デフォルト、プライマリー」や「セカンダリー」に変更することだけでなく、「ブラックリスト」や「ホワイトリスト」を「拒否リスト」や「許可リスト」に変更することなども含まれる。 ITコミュニティーでは、全米で巻き起こっている「ブラックラ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
