How to write the perfect pull request
EngineeringHow to write the perfect pull requestAs a company grows, people and projects change. To continue to nurture the culture we want at GitHub, we've found it useful to remind ourselves what we aim for when… As a company grows, people and projects change. To continue to nurture the culture we want at GitHub, we’ve found it useful to remind ourselves what we aim for when we communicate. We re
イケててヤバいGit入門 | GREE Engineering
この投稿はGREE Advent Calendar 2013 20日目の記事です。 プロデューサーの皆さん、みりっほー。進捗どうですか？私はダメです。ごめんなさい。（´・ω・｀） WG事業部の二宮です。今日はアイマス駆動開発の話をしようかと思ったのですが、急遽Gitの使い方の話に変更しました(Inspired by 堀口先生)。 アイマス駆動開発の話が気になる方は、是非一緒に飲みに行きましょうw ※この記事では、ツールにGitやGitHubを利用することを想定しております。 Gitをスマートに使いたい グリーでは、基本的にA successful Git branching model（有志の方による日本語訳）にのっとって開発しています。 Gitについて基本的な考え方の部分は堀口さんの記事で言及されているので、私は現場で具体的にどのような使い方をしているのかについて書きたいと思います。 と
非開発者もGitHub Flowに巻き込んでみんなハッピーになった話 - Masatomo Nakano Blog
前提: GitHub flow を使っていてCIサーバーはJenkins 最近ちょっと開発フローの改善をして、とてもよく機能してて満足しているので紹介してみる。 この改善をやる前の悩み: pull-requestでコードレビューはできるのだけど、cssとかjavascriptなどの見た目や動作の変更ってコードだけだとわかりにくい。レビューする人が各自ローカル環境で実行するのもだるい。 コードを読まないデザイナーとかプロダクトオーナーとかの人が、pull-requestのレビュープロセスに簡単に参加できない(非開発者全員のところでローカル環境設定するのはだるすぎる)。 コード的にokに見えてmasterにmerge後、何か問題(特に仕様的な問題や、デザイン的な問題)が発生した場合、「修正branchを作ってpull-request」というフローを再度回さないといけない。最初のpull-req
continuous commit のお供、git rebase を決定的に刷新する最強ツール Uchronie をリリースしました - tomykaira makes love with codes
2013-07-13 continuous commit のお供、git rebase を決定的に刷新する最強ツール Uchronie をリリースしました Scala Git いままで git rebase -i に何度泣かされたことでしょう。 git は最高のツールですが(他の SCM に勝るという意味ではありません)、あれは非常に出来がわるい。 テストを回すたびに自動コミットする continuous commit のプラクティスを採用している私達にとって、 interactive rebase は頭痛の種でした。 (continuous commit については Continuous Commit (kyon_mm さんの発表資料)、最近の git の使い方について - tomykaira makes love with codes など)。 git-rebase--interact
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
github を用いた開発フローテンプレート
