
GitHubを使っていて今まで不便だった点として、「IssueやPull Requestの投稿内容を規定することができなかった」ことがあると思います。最初の投稿内容がどうしても不十分なものになってしまい、詳細を聞き出すことから毎回始めなければならない、といった苦痛をいつも感じていた人は多いはずです。 この苦痛も過去のものとなりそうです。IssueやPull Requestにテンプレートが作れるようになりました。Issue and Pull Request templatesという題名で新規機能のアナウンスがありましたので、さっそく日本語に訳してみました。参考になると幸いです。 IssuesおよびPull Requestsのテンプレート 重要な詳細が欠けている問題を解決することは困難です。今、プロジェクトの管理者は、プロジェクトのIssuesやPull Requestsのためにテンプレートを
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
こんにちは。 DMM.makeで開発をしておりますコーイチです。 春に入った新人も活躍するようになり、最近業務でプルリクエストをレビューする機会が増えてきました。 日頃どのようにレビューを行っているのかの自分なりの整理と、誰かの多少の参考例になればと 今回プルリクレビューに関して書きました。 レビュー消化ポリシー 差分は全部みる 気になる事柄を残さない 分かっていない事柄を残さない レビュー消化フロー 基本的に私はプルリクエストに対しては2回目を通すようにしています。 【1回目】全部の差分に目を通す 気になったところがあった場合 気になった点が個人の好みの問題である場合 →保留する 気になった点が個人の好みの問題でない場合 →改善案をコメントする よく分からなかったところがあった場合 意味分からん旨をとりあえずコメントする 【2回目】全部の差分に目を通す 保留した好みの問題がまだ気になる場
はじめに GitHub Pull Request Builder Plugin とは何ぞや?的な内容については、下記のページを参考にしてください。 私も非常に参考になりました。ありがとうございます。 Jenkinsでプルリクエストをビルドする Pull Request Builder PluginをJenkinsに導入する jenkins で GitHub のプルリクエストをマージしてテストする その上でこのページでは、多すぎる設定項目について、上記参考ページでは書かれていない部分や、私がハマった部分などをベースに解説できればと思います。 システムの設定 GitHub Pull Request Builder のブロックまで移動。 トークンの生成 Create API Token... から、ID/PW を使ってトークンを生成する。 このとき、前回生成したときのゴミなどが残っていると生成に
できちゃうんです。 CIの一環で、表題のような開発フローを試してみました。 What's CI? Continuous Integration(継続的インテグレーション)は、こちらの記事によると、 1度限りもしくは数回限りではなく、継続的に小まめにビルドを実行していくプラクティス のことです。 Merits ここも、上記の引用ではありますが・・・。 想定外の状況が起こったときに、素早く検知できる 仕込んでしまったバグを即座に検知できる 開発者の環境依存の問題を検知しやすくなる 「私の環境では動くけど・・・」 ビルドが属人化せずに画一的になりやすい 「◯◯さんがビルドしたら失敗/成功した」 こういう状況に思い当たる節のある人も、いますでしょうか・・・? 役に立ちそうなツール Travis CI 最近GitHubのプロジェクトに"build"とか"passing"とかタグがついてるあれ Tra
Gitを使用している人であれば、プルリクエストには馴染みがあるでしょう。これは、分散バージョン管理システムが世に出始めてから、何らかの形で使われています。BitbucketやGitHubのように凝ったWebユーザインターフェイスが構築される前は、プルリクエストは単純に電子メールベースで行われており、Aliceのリポジトリから変更をプルするように依頼していました。プルリクエストを受けた側がこの変更を妥当だと判断すれば、いくつかのコマンドを実行しmasterブランチに変更をプルするという流れです。 $ git remote add alice git://bitbucket.org/alice/bleak.git $ git checkout master $ git pull alice master もちろん、手あたり次第Aliceの変更をmasterにプルすることは、 得策 ではありませ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに この記事は How to write the perfect pull request - GitHub を和訳というか、意訳した記事です。 ご指摘などありましたら大歓迎です! 良いプルリクエストを書くには (原題 : How to write the perfect pull request) 会社が成長していくと、人もプロジェクトも様変わりしていきます。GitHubの中に私達が望む文化を育んでいくためには、我々が何を自覚してコミュニケーションするべきなのか分かってきました。私達のチームが最強であり続けるために、最近以下のよ
Github使って開発してると新しいブランチ切ってプルリクを投げるのにどうしてもコマンドを使わなきゃいけない雰囲気あって、特にエンジニアじゃない人たちには嫌われる傾向(ちょっと減ってきたのかな)あるけど、Github使ってればコマンド一切不要でプルリク投げれます。 特に「このお知らせの追加になったので更新しておいてー」とか、「ここタイポだから直しておいてー」とかいう依頼はエンジニアサイドに依頼を投げるよりプルリク投げてもらった方が効率いいですよね。 1. 新しいブランチを作成する プロジェクトのトップページにbranchのボタンがあります。 そこをクリックしてbranch名を入力することで新しいブランチが作成できます。 2. 修正したい箇所を探す Githubの画面の上部には検索フォームがついてます。 プロダクトの中で変更したい所があればこちらから検索するといいですね。 3. コードの追加
いつも忘れてしまうので、GithubであるプロジェクトをForkしてからPull Requestをするまでの流れをメモしたいと思います。今回、実際に私がこの流れを使っているCordova (PhoneGap) ドキュメントのプロジェクト、 https://github.com/apache/incubator-cordova-docs を例にやっていきたいと思います。 1. Fork する GithubでForkしたいプロジェクトまで行って、右上にあるForkボタンを押します。今回、 https://github.com/apache/incubator-cordova-docs をForkしたので、私のGithubアカウントkeiko713上では https://github.com/keiko713/incubator-cordova-docs というリポジトリが作成されます。 2.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く