5 metrics Engineering Managers can extract from Pull Requests – SourceLevel
HomeBlogEngineering Metrics5 metrics Engineering Managers can extract from Pull Requests 5 metrics Engineering Managers can extract from Pull Requests Many Engineering Managers promote Pull Requests as part of the development workflow. It’s a consolidated practice that brings lots of benefits. It consists of comparing the changes of a branch with the repository’s base branch (conventionally called
Pull Requestに動作確認方法を書け - 橋本商会
ある程度アプリケーションの規模が大きくなってくると、ある変更がどこまでの影響範囲だと思っているのかがコミュニケーションにおいて重要
Managing generated files in GitHub
Is this actually a large Pull Request or are you just looking at too many generated files? Are those generated files even reviewed? If you’re using GitHub and work with generated files in your repository you may be seeing large diffs and merge conflicts as you update your newly generated files. I’m going to show you how you can use the .gitattributes file in your repository to suppress the display
[GitHub] ブランチの保護設定を活用しよう 【レビューが通るまでマージさせんぞ】 | DevelopersIO
ブランチを保護していますか？ master ブランチにマージしたらテストに失敗！ みたいな経験をしたことはないでしょうか？開発の中心となるブランチは、問題なく動作する状態を健全に保ちたいですよね。 GitHub では、リポジトリの設定にて ブランチの保護 が可能です。この機能を使うと、以下のような保護を実施できます。 CIが通らなければマージできない 他のメンバーからレビューを承認(Approve)されなければマージできない 特定のメンバーはマージできない 設定方法 ブランチの保護の設定は「Settings」の「Branches」から行うことができます。何もコミットがないリポジトリは、設定そのものが出てきませんのでご注意ください。 「Protect branches」セクションの「Choose a branch...」をクリックし、保護対象とするブランチを選択します。 ページが切り替わりま
![[GitHub] ブランチの保護設定を活用しよう 【レビューが通るまでマージさせんぞ】 | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/fdcc20784930f9e696050408d2bf25b1fbfb0f9f/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2016%2F05%2Foctcat-eyecatch.png)
Quickly review changed functions in your Python pull requests
ProductQuickly review changed functions in your Python pull requestsLast month, we released a new way to quickly review pull requests by listing the changed functions or methods in the pull request file finder. Now Python enthusiasts can quickly… Last month, we released a new way to quickly review pull requests by listing the changed functions or methods in the pull request file finder. Now Python
Slack 上のエンジニア同士の会話を増やした一つの工夫 + ちょっとした OSS の紹介 - クックパッド開発者ブログ
こんにちは、技術部開発基盤グループの小室 (id:hogelog) です。 最近エンジニアが全員集まる Slack のチャンネルからデプロイ通知等の機械的な通知を排除したらエンジニア同士のコミュニケーションがほぼ毎日発生するようになり満足しています。自分のような無名なペーペーエンジニアも業界に名を馳せる著名エンジニアもフラットに属しているチャンネルが通知で埋まっていて人間の会話がまったく発生しないなんてもったいないですからね。Slack のチャンネルをどう運用するか会社によって文化の違いがあると思いますが、良い運用は参考にしたいので各社どんどん発信してほしいのでよろしくおねがいします。 さてそんな話で終わっても良いのですが、ここは開発者ブログだしせっかくなので最近開発した Slack 関連のアプリケーションを紹介します。 tokite で GitHub から Slack への通知をカスタマ
コードレビューのクオリティとスピード，とくにスピードについて，それとコミュニケーションについて - hitode909の日記
ソフトウェアを作るときにクオリティとスピードのバランスをとりたくて，どちらかに偏ってはいけなく，どちらもキープしないといけない．すごく雑に*1とらえると， クオリティ→正しく動き，不具合がないほうがよい スピード→(計算時間ではなく)早く作れるほうがよい ということになる． コードレビューでは，不具合を見つけて直してもらったり，動きはしてもコードの可読性に問題があって直してもらったりと，クオリティに目を向けられがちだと思う． ところで，コードレビューとスピードの関わりについて考えてみる．スピードのためにできることはいくつかあり， 早く読み始める→他のことやってても手を止めて読み始めたり，1日のうち決まった時間にレビュータイムを設けたり 速く読む→これはコツとかある*2けど精読しないといけないので難しい 不具合を見逃さない→リリース後とか，リリース直前に正しく動かないことが分かったら大きな手
「速」を落とさないコードレビュー
Forkwell Meetup #3 https://forkwell.connpass.com/event/48147/
許可を得る前にプルリクしよう、って言ってきた。 - ppworks.jp
2016年12月17日(土)、松江テルサ4階にて開催された松江Ruby会議08に参加しました。初の島根！初の松江！ キッカケは、フルタイムRubyコミッター採用までの道のり | Money Forward Engineers' Blogという記事が松江Ruby会議スタッフの目に止まり、僭越ながらゲストスピーカーにお招きいただきました。 許可を得る前にプルリクしよう、とは About pull requests - User Documentation プルリク = GitHubのPull Requestという機能です。GitHubはGitのRepositoryをホスティングするサービスで、Pull Requestを使うことで、そのRepositoryの本筋の歴史に対してある時点で分岐した歴史を統合する提案が出来ます。 『許可を求めるな謝罪せよ(Don’t ask for permissi
prpr でプルリクエスト運用を自動化する /Introduction-of-prpr
GitHub のプルリクエストに反応する bot 「prpr」の紹介
Wiplock - 作業途中の Pull Request を間違えてマージするのを防止する
English TL;DR 未完了のタスクやタイトルに WIP という文字列を含む Pull Request からメインブランチを保護する Wiplock をリリースしました。 よかったら試して下さい。 https://wiplock.com ソースコードを公開しています。Go と React + Redux で開発しました。 https://github.com/ngs/wiplock 動機 日々の GitHub を使った開発フローで、作業途中 (WIP) の Pull Request を作成し、同僚と実装に関する議論に役立てたりします。 これらの Pull Request を、タスクが未完了のままマージしてしまったり、タイトルに WIP を付けたままマージしてしまい、紛らわしいマージコミットを作成してしまいます。 このようなミスオペレーションを防止するため、Wiplock という、小さ
開発速度を上げるための Pull-Request のつくり方 - クックパッド開発者ブログ
こんにちは、投稿開発部の森川 (@morishin127) です。クックパッド、お料理アルバム、みんなのお弁当の iOS アプリの開発等に携わっています。 クックパッドでの開発は GitHub Enterprise 上で行われており、書いたコードをプロダクトに取り込む前には基本的に第三者のコードレビューが必須です。コードレビューはプロダクトの品質向上に貢献していますが、往々にして結構な時間と労力がかかるものです。Pull-Request を出してレビューをしてもらい指摘の修正を繰り返していると、場合によってはマージに数日〜1週間ほどかかってしまうこともあります。自分の開発速度を速めるため、また周りのエンジニアの開発速度を下げないためにレビューしやすい Pull-Request を出すことは重要です。この記事ではレビューしやすい Pull-Request のために心がけていることを紹介したい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Mergify - CI/CD pipeline optimizer
Sedy - Brings the power of the sed Linux command to Github
GitHub - danger/danger-js: ⚠️ Stop saying "you forgot to …" in code review