僕の考える、GitHubでチーム開発をする際のプルリクエスト（プルリク）の作法を書いてみました。プルリクという名前から当たり前ですがGitHubを使うことを想定してます。 十分小さくプルリクを作ろう プルリクが小さいと、レビューが簡単になり、変更がすばやく中央のブランチに取り込まれるため、レビューの精度が高くなり開発スピードも早くなります。 タスクやIssueが一つで表現されていても、やりたいことを予めいくつかに分けて、それに対して一つプルリクを出しましょう。コードレビュー中に他にやりたいことややるべきことが出てきたら、同じプルリクで作業せずに別のプルリクで行いましょう。 プルリクを出す前に「これとこれとこれのプルリクを出します」とIssueなどで宣言されている状態がベストです。プルリクの分け方に不安があるならこの状態でもレビューをもらっておくと良いでしょう。 単体でリリースできる単位でプ
はじめに 今まで commit message を「なんとなく」書いていたが、プレフィックスをつけることで、コミットメッセージに対する考え方が変わった。 そのおかげで開発効率が上がったので、その内容をシェア。 プレフィックスをつけるってどういうこと？ 以下のようにコミットメッセージの先頭に、なんらかの文字をつけること。 feat: xxx という機能を追加 fix: yyy で発生するバグを修正 refactor: zzz の機能をリファクタ のように feat, fix, refactor などがプレフィックスです。 最近 OSS の Contribution Guide などでよく見かけます。 導入したプレフィックスルール Angular.js/DEVELOPERS.md Angular.js の開発者ガイドに書いてあるメッセージを参考にしました。 以前のコミットメッセージ（例 ちなみ
5. Self Introduction • きょん(@kyon_mm) 26歳 うさみみエンジニア • Test Architect in Nagoya • Groovy, F#, C#, Scala 6. Self Introduction • きょん(@kyon_mm) 26歳 うさみみエンジニア • Test Architect in Nagoya • Groovy, F#, C#, Scala • SCMBC, Nagoya.Testing, TDDBC 7. Self Introduction • きょん(@kyon_mm) 26歳 うさみみエンジニア • Test Architect in Nagoya • Groovy, F#, C#, Scala • SCMBC, Nagoya.Testing, TDDBC • TDD/BDDチョットデキル
こんにちは。 アグリゲーション開発担当の中川です。 今回は、みんなが大好きな構成管理ツール「Git」について話したいと思います。 私は Git を使い始めてから、バグの発生数が激減しました。 Git を使ったとある手法によってレビューが充実し、バグの少ないコードを書くようになったと考えています。 では、今回はその手法について紹介したいと思います。 ※ 本稿は Git 以外の第三世代構成管理ツール（Hg、Bzr など）にも適用するかと思いますが、Git の用語とコマンドを使って紹介していくため Git の基本知識が必要となります。ご了承ください。 レビューしやすいコミット履歴と、開発の流れで自然にできるコミット履歴の乖離 以下のようなコミット履歴があるとします。 1. wip: 仕様変更○○を行い始めた 2. wip: 仕様変更○○の続き 3. wip: ちょっと設計を変更、それと過去のバグ
いろいろ勉強になったのでメモ。 githubにアカウントを作ったのはいいものの、さてどうやってさくらのレンタルサーバからpushするのかと調べていたら、SSHの公開鍵を設定しないといけないことがわかった。 こちらを参考にさせてもらった。 初心者Git日記その五～GitHubにSSH公開鍵登録～ | SetucoCMSプロジェクト ありがとうございます。 まずはそのSSH鍵である、公開・秘密のペアをローカルに作る。 "ssh-keygen"を使う。 $ ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/home/rightgo09/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same
gitの入門用のチュートリアル"Learn Git Branching"を訳した 2013/03/18 ここで公開してます。スマホからだと動かないのでPCで見てください。 http://remore.github.com/learnGitBranching-ja ChromeとFirefoxでは動作確認してます。翻訳リソースはgithubに置いてあります。 Laern Git Branchingは： グラフィカルにgitツリーを操作しながらrebaseとかmergeとかを学べる IDEA * IDEAさんとかHackerNewsとかで、1か月くらい前に話題になってた MIT Lisenceで公開されてて自分で演習問題も作れる というツール。公開されてから1か月くらいしか経ってないのに、既に中国語、韓国語、フランス語の3か国語に翻訳されてる。海外の人仕事はえーと感心しました。 春だし新人さん
みなさん、Git使ってますか？僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
最近の更新 (Recent Changes)2016-04-25FrontPage 2014-04-08機能一覧 今後対応を予定している機能 2013-02-16新規メンバーのミッション 2012-12-22リリース手順 2012-11-25議事録一覧 最新リリース情報setucocms (1.6.1)2013-03-24 21:20 Wikiガイド(Guide)Wikiの文法 リンクの種類と文法 ブロックプロセッサ 拡張文法 サイドバー プロジェクトWikiでの広告設定 サイドバー (Side Bar)このサイドバーについて このサイドバーの編集 Gitリポジトリ運用ルールOutlineバージョン番号の構成 githubのリモートリポジトリのブランチ 各自のローカルリポジトリのブランチ 開発の流れ シナリオ1 次リリースに向けた変更（過去のリリースへのフィードバックが必要ない場合） シナ
先日、皆さまにお願いした CreateJS のドキュメント翻訳では GitHub を利用しています。GitHub を使うのは初めてという方もいるかもしれませんので、いまさらながら簡単な使い方をご紹介します。 一般的な （といっても GitHub の使い方が指定されているわけではないですが） GitHub を利用した共同開発には以下の 2 種類があるようです。 共有リポジトリ リポジトリ （しばしば "repo" と呼ばれます） は、GitHub が、プロジェクトに関連するファイルをまとめて保管する単位です。CreateJS 翻訳プロジェクトも CreateJS/localization という名前のリポジトリを持っています。 これをチーム内で共有して、作業目的ごとにブランチ （Branch） と呼ばれるコピーを作り、適当なタイミングでブランチに対して行われた更新をオリジナル （Master
これはGit Advent Calendar / Jun.20日目の記事です。前回は、fukajunさんの変更を一時的に退避！キメろgit stashでした。 この記事ではgithubでpull requestを送る時に私が気をつけていることを共有したいと思います。 私が気をつけていることは次の3つです。 masterにコミットしない 簡潔なコミットメッセージを書く コミットを1つにまとめる この話の前提 以降では、次の2つのリモートリポジトリが登録されている前提で説明します。 upstream: fork元のリポジトリ origin: upstreamからforkされた自分のリポジトリ masterにコミットしない 修正作業は必ず新しいブランチを作ってから行ない、masterブランチはあくまでupstreamの更新を取り込むためだけに使って下さい。 このルールを守らないでpull req
GitHubの特に重要な機能である「プルリクエスト」の活用方法についてGitHub社内でのノウハウが公式ブログの記事になっていました。GitHubが今回更新をしたAboutページの開発でも2ヶ月の間に10人のメンバーが130のコミットと91のコメントのやりとりがブランチ上で行われていました。 GitHubberによる講演などでもプリリクエストが重要な機能であると強調されているようです。 記事によるとプルリクエストは新しいアイデアについてのディスカッションを生み、協力してくれる人を見つける為のとても良い方法との事で活用するコツとして以下の3つの点を紹介しています。 プルリクエストはなるべく早く起こす プルリクエストは機能についての意見交換をする良いきっかけになります。コードの修正が終わっていなくてもなるべく早くプルリクエストをする事で、最後にまとめてフィードバックをするのではなく発展的にコメ
Mandarine-wp7ではリポジトリにgitを選択している。 svnがgitになってもやることは変わらなくて、最初はローカルにあるファイルをGoogle Codeのサーバにアップするが、gitの場合は既にローカル側にリポジトリがあることが殆どなので、まずはこれをリモートにプッシュする。 その時のプッシュは全く問題無く終わったのだが、その後幾つかのファイルを修正して追加でコミットし、その後再度プッシュした時に問題は発生した。 >git push To https://〜.git ! [rejected] master -> master (non-fast forward) error: failed to push some refs to 'https://〜.git' To prevent you from losing history, non-fast-forward upda
gitでリモートのリポジトリにpushしたcommitを取り消したいときにはrebaseを使います。 git rebase -i HEAD~2 とすると、エディタが開いて過去２回分のコミット時のコメントが表示されます。 コメントの2行目を削除して保存すると、前回のコミットが取り消されます。 その後、 git push origin +master すればＯＫ。 rebaseはリモート・ローカル共にHEADの位置が変更されます。 リモートのみ、またはローカルのみの場合は ＜リモートのみ＞ git push -f origin HEAD^:master ＜ローカルのみ＞ git reset HEAD^ ローカルのみコミットを取り消した場合、リモートのほうが世代が進んでいることになるので、reset後にpushしようとするとエラーになります。 その場合は一度rebaseして世代を合わせる必要があ
NekostagramとInustagramで使用しているファイル一式をGitHubに公開してみた。技術的にはなんにもすごいことはしてなくて、さらにSassとか初めて使ってみたので、いろいろとツッコミどころ満載かもしれない。 共通化・汎用化 最初にNekostagramを公開したときは、とりあえず動くようにすることを第一目的に、きったない書き方で殴り書きしてたんだけど、次のInustagramを作るときに、できるだけコードを共通化・汎用化させていき、最終的には現在公開しているコードのように、まったく同じ1つのRubyファイルでNekostagramとInustagramの両方を動かせるようにできた。 ruedap/nekostagram - GitHub Gitリポジトリがゴミだらけ なかなかGitHubに公開できなかった理由は、恥ずかしながらこれ…。 このツイートに対して、いくつか方法を
前回 git diff を図に書いてみたところ、自分の中で意外と整理できたので、これまたなんとなく使っていた git reset についてもまとめてみた。 とりあえず結論を先にまとめよう。 git reset とは？ HEAD の位置を変更するコマンド。 オプションによってインデックス、ワーキングツリーの内容も変更できる。 git reset のオプションは？ --soft、--mixed(オプションなしと同等)、--hard オプションがあり、影響度の小さい順に以下のようになる。 --soft HEAD の位置のみを変更する。インデックス、ワーキングツリーには影響なし。 --mixed (またはオプションなし) HEAD の位置とインデックスを変更する。ワーキングツリーには影響なし。 --hard HEADの位置、インデックス、ワーキングツリーをすべて変更する。 さて、git reset
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
