tigでコミットログ見てるときに「このコミットが含まれたプルリクに飛びたい」と思うときがあるので見れるようにした - パルカワ2
@hisaichi5518 .tigrc とかで設定して、閲覧している commit をキーボードショートカットで開けるようにしておけば、commit のページに Pull Request へのリンクが含まれていそう— ホームページビルダー (@r7kamura) 2017年2月7日 ツイッターでボソっと言ったら、良い感じのアドバイスをもらったので、雑に会社のGHEだけ対応するかと思って対応した。 hub インストールして .tigrc に以下を追加して、コミットログ見てるときに shift+pを押せば、コミットページに飛ぶので、そこからプルリクへ遷移出来る。 bind generic P @sh -c 'hub browse -- commit/%(commit)'直接プルリクに遷移したいと思って頑張ろうとしたけど、複数プルリクがあるとかめんどくてこれが一番かなと思った。 追記: git
開発速度を上げるための Pull-Request のつくり方 - クックパッド開発者ブログ
こんにちは、投稿開発部の森川 (@morishin127) です。クックパッド、お料理アルバム、みんなのお弁当の iOS アプリの開発等に携わっています。 クックパッドでの開発は GitHub Enterprise 上で行われており、書いたコードをプロダクトに取り込む前には基本的に第三者のコードレビューが必須です。コードレビューはプロダクトの品質向上に貢献していますが、往々にして結構な時間と労力がかかるものです。Pull-Request を出してレビューをしてもらい指摘の修正を繰り返していると、場合によってはマージに数日〜1週間ほどかかってしまうこともあります。自分の開発速度を速めるため、また周りのエンジニアの開発速度を下げないためにレビューしやすい Pull-Request を出すことは重要です。この記事ではレビューしやすい Pull-Request のために心がけていることを紹介したい
仕様や実装方針の相談をPullRequestで行う取り組み - $shibayu36->blog;
これまで少し大きめな機能であれば、コードを書く前にまず仕様や実装の方針をissueのdescriptionにまとめ、それを先にレビューしてもらってから実装にとりかかるということをしていた。最近、その方針をそもそもrepositoryのファイルとして書いて、PullRequestしてレビューしてもらうようにしたら便利だったのでご紹介。 なぜコードを書く前に仕様や実装の方針をレビューするのか 前提としてなぜコードを書く前に仕様や実装の方針をレビューして欲しいのかについて書いておく。これはとにかく手戻りの量を少なくしたいという要求のためである。 実装に取り掛かろうとすると、実装の方針はいくつか思いつくが、どれが一番よいか迷うことはよくある。その場合に誰にも相談せず自分だけで判断し、コードを書いてからPullRequestを送った場合、もしその選択に重大なミスがあった場合全て書きなおさないといけな
Jenkinsを使ってGitHubのPull Requestが自動でテストできちゃう？ - Qiita
できちゃうんです。 CIの一環で、表題のような開発フローを試してみました。 What's CI? Continuous Integration（継続的インテグレーション）は、こちらの記事によると、 1度限りもしくは数回限りではなく、継続的に小まめにビルドを実行していくプラクティス のことです。 Merits ここも、上記の引用ではありますが・・・。 想定外の状況が起こったときに、素早く検知できる 仕込んでしまったバグを即座に検知できる 開発者の環境依存の問題を検知しやすくなる 「私の環境では動くけど・・・」 ビルドが属人化せずに画一的になりやすい 「◯◯さんがビルドしたら失敗/成功した」 こういう状況に思い当たる節のある人も、いますでしょうか・・・？ 役に立ちそうなツール Travis CI 最近GitHubのプロジェクトに"build"とか"passing"とかタグがついてるあれ Tra
プルリクエストをより使いこなす | POSTD
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にプルすることは、 得策 ではありませ
GitHub「完璧なプルリクの書き方を教えるぜ」 - Qiita
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の中に私達が望む文化を育んでいくためには、我々が何を自覚してコミュニケーションするべきなのか分かってきました。私達のチームが最強であり続けるために、最近以下のよ
[※Gitコマンド使いません] Githubのブラウザのみでブランチ切ってプルリクするまで - Qiita
Github使って開発してると新しいブランチ切ってプルリクを投げるのにどうしてもコマンドを使わなきゃいけない雰囲気あって、特にエンジニアじゃない人たちには嫌われる傾向（ちょっと減ってきたのかな）あるけど、Github使ってればコマンド一切不要でプルリク投げれます。 特に「このお知らせの追加になったので更新しておいてー」とか、「ここタイポだから直しておいてー」とかいう依頼はエンジニアサイドに依頼を投げるよりプルリク投げてもらった方が効率いいですよね。 1. 新しいブランチを作成する プロジェクトのトップページにbranchのボタンがあります。 そこをクリックしてbranch名を入力することで新しいブランチが作成できます。 2. 修正したい箇所を探す Githubの画面の上部には検索フォームがついてます。 プロダクトの中で変更したい所があればこちらから検索するといいですね。 3. コードの追加
![[※Gitコマンド使いません] Githubのブラウザのみでブランチ切ってプルリクするまで - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/258711ccb6d85b612d5ea956a8812ed6fc995f20/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Fadvent-calendar-ogp-background-7940cd1c8db80a7ec40711d90f43539e.jpg%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCJUUyJTgwJUJCR2l0JUUzJTgyJUIzJUUzJTgzJTlFJUUzJTgzJUIzJUUzJTgzJTg5JUU0JUJEJUJGJUUzJTgxJTg0JUUzJTgxJUJFJUUzJTgxJTlCJUUzJTgyJTkzJTVEJTIwR2l0aHViJUUzJTgxJUFFJUUzJTgzJTk2JUUzJTgzJUE5JUUzJTgyJUE2JUUzJTgyJUI2JUUzJTgxJUFFJUUzJTgxJUJGJUUzJTgxJUE3JUUzJTgzJTk2JUUzJTgzJUE5JUUzJTgzJUIzJUUzJTgzJTgxJUU1JTg4JTg3JUUzJTgxJUEzJUUzJTgxJUE2JUUzJTgzJTk3JUUzJTgzJUFCJUUzJTgzJUFBJUUzJTgyJUFGJUUzJTgxJTk5JUUzJTgyJThCJUUzJTgxJUJFJUUzJTgxJUE3JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMzQTNDM0MmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz1iMmIxMzY3YjlhZGE4NjM0ZmRkNTRlOGI5ZTg5ZWE1OA%26mark-x%3D120%26mark-y%3D96%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9OTcyJnR4dD0lNDBzdWU3MzgmdHh0LWNvbG9yPSUyMzNBM0MzQyZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPWMwN2ZkNjlkNWExYzg2MmIwNmJiMTZlNjY0ZTQzYTZi%26blend-x%3D120%26blend-y%3D445%26blend-mode%3Dnormal%26txt64%3DaW4g5qCq5byP5Lya56S-44Kw44Ot44O844OT44K5%26txt-width%3D972%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%25233A3C3C%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D134%26txt-y%3D546%26s%3Ddd2482c8a0c19dd4b45a7fea9e322fd7)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Elastic Blog: Stories, Tutorials, Releases
http://post.simplie.jp/posts/37