GitHubでの”Merge pull request”の弊害 | POSTD
私は GitHub が大好きです。GitHubはオープンソースへの コントリビューション （寄与貢献）を何十倍も容易に、そして楽しいものにしたと思います。ですが、GitHubがPull RequestというwebのUI形式で前面に押し出しているオープンソースの メンテナー のワークフローが、プロジェクト品質とコントリビューションを受けつけるスピードの弊害になるということに気がつきました。そこで、GitHubの Pull Request にある「Merge pull request」ボタンをクリックする前に、少しお話をさせてください。 メンテナーの紹介 ジェーンはそこそこの成功を収めているオープンソースプロジェクトのメンテナーです。彼女は毎週プロジェクトのGitHubリポジトリに上がる新しい Issue を確認し、リクエストに対し速やかにフィードバックを返します。リクエストをすべて実行する時
GitHubな話 〜git rebase -i編〜 | ten-snapon.com
ペパボに入ってはや1ヶ月が経とうとしています。 おかげさまで毎日楽しく、新鮮な日々を過ごしています。 入社後2週間は研修やらオリエンテーションを実施してもらえたので 実務に入ってから2週間たったところです。 技術的な壁やコードがわからないといった状況は今のところ ないのですが、チームで開発するにあたって、まだまだ適応できていない 部分があるので週末ちょっと整理してみました。 ペパボではコードの履歴管理や業務でGitHubを利用しています。 既存コードの改修を行う際は、改修の単位でブランチを立てて、 プルリク投げて、各々ブランチを育てて、改修が終わったら チームメンバーがチェックしてマージするというのが基本的な流れで、 僕自身まだちょっとうまくやれてない感じです。 問題点 PR(プルリク)の記載情報、スコープがダサい コミットの単位がばらばら 特にコミットの単位がばらばらなのがちょっとつらた
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
