Gitのブランチをどのタイミングで切って、マージしていくかなども非常に大切ですが、ブランチやマージをするよりも頻繁におこなうコミットについて、あらためて基本に立ち返ってみましょう。 一つ一つのコミットを綺麗に積み重ねていくことは、ブランチを切るタイミングやマージ、歴史の改編などを容易にすることができます。コミットが綺麗に積み重ねられていないとマージや歴史改変で苦労するでしょう。 Gitのベストプラクティス（原文）に乗っかるためにもgit commitする前に以下のようなことをチェックしましょう。 Gitの操作に慣れている人はPushやMergeをする前に今回紹介するようなことを元にしてコミットの歴史を綺麗に整えましょう。 1コミットに1つの対応1コミットにはあれこれ詰め込めすぎるべきではありません。例えば以下のような2つのことがあったとします。 Aの機能を追加Bの機能のバグを修正2つの対応

Gitもいろいろ増えているんだと改めた@HIROCASTERでございませう。 過去のGitのバージョンでは、設定できないと言われていたことについて、最近のGitでは設定できるようになっています。（と、言っても何ヶ月も前に追加されている内容ですが…） そのなかでも「これが欲しかったんだ！」と思われる2点について取り上げます。 git merge –no-ffgit mergeをおこなう際には –no-ff をつけることによって、トピックブランチでおこなわれたコミットが明確にわかるようにするかと思います。 以下の図だと、Topic-bは別ブランチでコミットされましたが、masterへマージする際に ff だったために履歴を見ると別ブランチでコミットされたかどうかが判断できません。 一方、Topic-CはTopic-B同様に別ブランチでコミットされましたが、masterへmergeされる際に –

Bitbucket – 無料のプライベートリポジトリが魅力https://bitbucket.org/ 無料でプライベートリポジトリを無制限につくることができる。 プライベートリポジトリは5人までは無料で利用できる。GitHubクローンではないが、個人や数人で利用するだけならBitbucketのサービスだけでまかなえるのでおすすめ。オンプレミス製品は有償での提供。 Gitea – Go製セルフホスト型のGitHubクローン2016年にver1をリリースした期待の新星です。別途記事を書いてますので、詳細はそちらをどうぞ。 https://hiroki.jp/gitea Go製のためマルチプラットホームでさくっと動きます。DockerやVagrantの提供もしているため動作させるまでのハードルが低いです。 全文検索機能はありませんが、主要な機能は搭載されています。 GitPrephttp://

YAPC::ASIA Tokyo 2013（2日目）で「GitHubでつくる、たのしい開発現場」というトークをしてきました。 まず、利用した資料を公開します。 伝えたいことコードレビューを習慣化させたいのであれば、GitHubは最適なツールです。 コードレビューを習慣化させたい コードは書いた人以外の目にふれさせるべきと考えている人には特にオススメのツールです。 ですが、GitHubはあくまでツールです。このツールを利用することで、コードレビューの機会や良いコードを書くためのノウハウを学習する機会を生み出すことができます。 その結果、人やチームが行動を起こすことでチームが成長したり、結果として良いソフトウェアができていくはずです。 レビューをすると増えるコスト、減るコストレビューはすべきだけど、現在レビューを習慣化できていないチームにとって、新たにコードレビューをしていくのは単に時間的なコ

GitHubを利用して、Jenkinsを利用しているは結構いらっしゃいましたが、今回紹介したプラグインであるGithub pull request builder pluginを知っている方は少なかったので、お役に立てたかなと思っています。 このようなGitHubと連携するプラグインの導入やGitHubを利用した実践的な開発ワークフローについて解説しているGitHub本を執筆しておりますので、doorkeeperに登録いただければ、レビューアー募集や書籍の発売情報をお届けしまので、こちらもよろしくお願いします。

TDDがアジャイル開発では前提ここまでに説明した、アジャイル開発を支えるエンジニアリングのプラクティスをまとめておこう。 ユニットテストリファクタリングテスト駆動開発（TDD）継続的インテグレーションこれら4つを実践することなしにアジャイル開発を成功させることはかなり難しい。たちまち「書いて直す」だけの日々に逆戻りすることになるだろう。 アジャイルサムライでは成功させることはかなり難しいと甘い表現をされているが、ほぼ不可能であるといえる。 プラクティスとは習慣である。つまり、やることが当たり前なのである。やるべきことなのです。 テスト駆動開発を推し進めれば、必然とここにあげられている4つのプラクティスを実践することになる。 注意しなければいけないことは、テスト駆動開発をおこなうこと事態ががアジャイルソフトウェア開発ではありません。 アジャイルにソフトウェアを開発するためにエンジニア一人一人

近所にコーヒーショップがオープンしました。あなたは期待に胸躍らせながら、はじめてそのお店で1杯のコーヒーを買いました。笑顔の素敵な店員さんは、カードがスタンプで一杯になると、コーヒー1杯が無料になるポイントカードをくれました。 そのポイントカードは ポイントカードA 欄が10個あり、最初にカードを貰ったときにスタンプが1個も押されていない。 ポイントカードB 欄が12個あり、最初にカードを貰ったときにスタンプが2個押してある。 ポイントカードはあと10杯コーヒーを買って、スタンプを10個ためるものです。スタンプを一杯にするのにコーヒーを注文する回数に違いはありません。 AとBのポイントカードのどちらをもらうかで、何か違いはあるでしょうか？ インタフェースデザインの心理学この本はデザイナーのためのハウツー本ではありません。良いソフトウェアをつくるためのポイントを科学的に研究された事実を元に解

本書は裏表紙に「中級技術者向け」と明記されている。JavaScriptの言語仕様に関して、入門したことない人や、関数型の言語に見地のない人は、パーフェクトJavaScriptやサイ本あたりで、JavaScriptの言語仕様を身につけてから、取り扱うことを推奨する。それぐらい価値のある内容に本書は仕上がっている。 そして、 正統派なTDD(テスト駆動開発)について理解したい JavaScript自身の言語的な特徴を押さえておきたい テストできるJavaScriptのコードを多く閲覧したい 実際のプロダクトに活用できるアプローチを数多く知りたい と、考えているJavaScriptを日頃から書いている人、携わっている人に、必ず読んでもらいたい1冊である。 全体を通じて、テストできるコードの特徴は何か、単体テストとテスト駆動環境の利点を享受できる優れた単体テストはどのようなものかをサンプルとともに

NETWORK: * CACHE:キャッシュさせるファイルを記載します。 NETWORK:必ずネットワークから取得する内容を記述します。CACHEセクションに記載したデータ以外をネットワークから取得するようにするのでアスタリスクを記載します。 マニフェストファイルの自動生成上記でマニフェストファイルを作成しましたが、下記のmanifestRというサイトを利用して、現在閲覧しているURLのマニフェストファイルのひな形を自動生成してくれるサイトがあります。こういったサイトを利用してマニフェストファイルの作成をさくっとやってしまうのがオススメです。 manifestR作成されたマニフェストファイルの内容を確認してから利用してください。自動生成された物をそのまま利用すると何もかもキャッシュされてしまって、意図しない動作を招くと思います。 HTMLにマニフェストファイルを設定すべてのHTMLのDOC

Ruby を知らない人に Ruby の話をして欲しいと言われてないけど、ブログを書きました。(*1) 難しい話は抜きにしたいんだけど、抜きにしちゃうとまったく訳わかんないから簡単に説明する。 今回は Ruby の erb ってのを使って元ネタ同様のことを実現する。 mod_ruby が動くサーバなんて自分でつくらないとないだろうけど、 その辺はどうにかしてもらう。 erubyが導入されていれば、ファイルの1行目に #!/usr/bin/eruby -McKuCutf-8 とする。(*2) そんなこんなで、どうにかしてもらったら、 <%= と %> で囲めば動きます。 どうにかしてもらったサーバで example.html というファイルの拡張子を example.rhtml すれば良いだけです。 <%= Rubyスクリプト %> 拡張子を変えずに動かすこともできます。 .html ファイル