開発環境

Gitに入門し終わった人のためのGitの使い方一覧

使い始めるとき

リポジトリの作成

Gitで管理するようにディレクトリを初期化する。

リポジトリを作成するディレクトリにて次を入力。

git init

リポジトリのクローン

既存のリポジトリの続きから開発したい場合、既存リポジトリの内容を自分のリポジトリへコピーするのが、クローン。

リモートからクローンする場合。

$ git clone https://github.com/<userid>/<repo>.git

状況確認のコマンド

今の状態を確認

git status

ログを確認

git log

見にくい場合は、1コミット一行でログ表示する。コミットIDを確認したい場合にも便利。

git log --oneline

コミットログだけじゃなくて、より細かいHEADの辿った履歴をみたい場合。

git reflog

コンフィグ一覧

ユーザ名、メールアドレス、”origin”のエイリアスの確認をしたい場合。

git config

ブランチ一覧

ブランチの一覧と、現在使用しているブランチの確認をする場合。

git branch

ファイルの管理

indexに加える

作成/変更したファイルを、次回のコミット対象に加える作業が index。

git add <filename>

で、ファイルをindexに追加(stage)する。

indexから外す

git rm --cached <filename>

indexから消して、さらにファイルの実体も消す。

git rm -f <filename>

間違えてファイルを消した場合、コミット済みのファイルであれば、ここまでの編集内容を破棄し、コミット時まで戻すことでファイルを復元することもできる。

indexを元に戻す

indexにファイルを誤って追加した場合などにHEADの状態まで戻します。ワーキングツリーはそのまま。

git reset HEAD

ワーキングツリーを元に戻す

addしていないファイルの変更内容を破棄する場合。

git checkout -- <filename>

–なしで、git checkout <filename>としてもよいが、filenameと同一のブランチ名が存在すると、意図せずブランチが切り替わってしまうので注意する。<filename>を.とすると、全て戻す。

コミット後の変更を全て破棄する

ワーキングツリーとインデックスをHEADの位置に戻す。

git reset --hard HEAD

このあたりの細かい違いについては、次の記事が詳しい。

http://qiita.com/shuntaro_tamura/items/db1aef9cf9d78db50ffe

ローカルへの記録

コミット

コミットメッセージは3行で書く。慣習上、1行目には変更箇所、3行目には変更理由を書く。

-m オプションを2つ使うと、一つ目が一行目、二つ目が三行目に入る。

git commit -m "<変更箇所>" -m "<変更理由>"

コミットの取り消し

git reset --soft HEAD^

ブランチ

既存のブランチを確認

git branch

ブランチを作成

git branch <新規ブランチ名>

ローカルでブランチを作成した場合も、プッシュしなければリモートには作成されません。

新規ブランチをリモートへプッシュする

git push origin <新規ブランチ名>

ブランチを削除

git branch -d <ブランチ名>

ブランチの移動

git checkout <ブランチ名>

ブランチを作成して移動

git branch <新規ブランチ名> + git checkout<新規ブランチ名>を一気に行う場合

git checkout -b <新規ブランチ名>

リモートとのやり取り

リモートへ反映させる(プッシュ)

ローカルでのコミット内容をリモートへ反映させる。

git push origin <ブランチ名>

ブランチ名にはmasterなどを入れる。masterに反映させる場合は省略して、

git push

とすることもできる。

origin というのは、リモートレポジトリのurlのエイリアス。

git config

でoriginの設定内容を確認できる。git cloneした場合は、自動で設定されている。

自分でoriginを設定したい場合は、

git remote add origin <url>

プッシュできない

プッシュできるのは、リモートの当該ブランチがpushするコミットまで fast-forwardできる場合のみ。

リモートブランチが変更されている場合は、マージしてから、pushし直す。

リモートの内容をローカルへ反映させる(プル)

git pull

git pull は、git fetch + git merge をしたのと同じ効果を持ちます。

競合しており、自動でマージ出来ない場合は、手動で競合を解決します。

  1. 競合しているファイルを編集します。
  2. git add <filename>で競合が解決したファイルをindexします。
  3. 変更内容をcommitします。

すると、競合が解決されたコミットが作成され、pushできるようになります。

 

 

 

テスト駆動開発における誤解が解けた。ケント・ベックの原典の要点と感想。

ケント・ベックの「テスト駆動開発入門」(Test-Driven Development. By Example. Kent Beck)を読みました。

原典を読んでみると、グーグル検索をしてヒットするテスト駆動開発(TDD)の記事で得られる印象と異なる部分が多々あったので、感想と共にメモしておきます。

テスト駆動開発は、リズムよくコーディングをするために書くテストである。

頭のなかではっきりしていない設計をはっきりさせるための手段となるもの。

今これからすべきコーディングの内容を指し示すもの。

テスト駆動開発は、品質を保証するテストとは異なる。

三角形の種類を返すプログラムで品質を保証するためのソフトウェアテストとして、Bob Binder は65個のテストを書いたが、テスト駆動開発のためにケント・ベックは6個のテストを書いた。

I wrote 6 tests (kind of like Name That Tune, “I can code that problem in four tests.” “Code that problem.”) Bob Binder, in his comprehensive book Testing Object-Oriented Software, wrote 65 for the same problem.

テスト駆動開発の導入に失敗したという日本の記事では、テスト駆動開発のことをxUnitによるソフトウェアテストの自動化と誤解している場合がある。

米国ではソフトウェアテストは専門のテスト屋が行うことが多い。テスト駆動開発のテストコードは、日本でプログラマーが行っているソフトウェアテストを代替するものにはならない。

開発サイクルのステップサイズは変えてもよい

開発サイクルの4つのステップは次の通り。

  1. 次に実装する機能についてのテストコードを書く。
  2. コンパイルが通る最小限の開発コードを書く。
  3. テストが通るように最小限、開発コードを修正する。(仮実装)
  4. 開発コードの重複を取り除き、開発コードの抽象性を上げる。(リファクタリング)

テスト駆動開発ではなるべく小さいステップで、この開発サイクルを何度も回して開発してゆく。

しかし、実装コードが明白で、もしステップが小さすぎると感じる場合には、仮実装を適宜省略してもよい。「大胆に」ステップを大きくしてもよい。

テスト駆動開発は、個々人で明日からすぐに導入できるもの。

チームで導入するかどうかに左右されない。それくらい範囲の限られたところから着想を得たコーディング手法である。

ただ、それをチームまで拡張して大規模な開発を行うことは不可能ではないことも示されている。

 

とは言え、テスト駆動開発は、他のあらゆる開発手法と同様、どんな案件に対してもうまくいくというような万能な手法ではない。

適用が困難な箇所もある。テストの自動化が困難な箇所はやはりテスト駆動開発もしにくいのでは。

適材適所である。銀行のシステム開発をアジャイルでやろうという人はいない。

テストのコード量は、開発コード量と同等になる。

そのため、テスト駆動開発を導入すると開発コードを書ける量が半分になる。開発コード量を維持するなら倍の量働かなければならない。

また、そうなることを同僚に説明する時間も考慮に入れる必要もあるとのこと。

コーディングのコストが2倍かかることになるため、導入には理解を得られにくい。小規模の導入から始めて、手戻りが少ないことが成果として現れ、全体としてのコストに優れることがわかってきたときに、テスト駆動開発が広がるだろう。

既にたくさんのコードがあるものに、後からテスト駆動開発を適用するのは困難

そもそも、テスト駆動開発のテストは、新しく開発コードを書くときの指針として書くテストなので、すでにあるコードを「保守」するために書くテストは、テスト駆動「開発」のテストではないが、本にはこう書いてあった。

ただ既存のコードが疎結合であれば、追加機能をテスト駆動開発の手法で開発することは可能ではないかと思う。

まとめ

現在の日本のソフトウェア業界においては、テスト駆動開発の流行りが落ち着いて、その利点と欠点の議論が出終わったという状況かと思います。

しかし、テスト駆動開発の提唱者であるケント・ベックは、2002年に出版された本で既に、テスト駆動開発の欠点も良く理解していたということが分かります。

原典を読んでわかったことは、日本でのテスト駆動開発に関する批判の一部は、テスト駆動開発の誤解や不理解から生じた不幸であるということです。

原典の日本語訳が非常に読みづらいのがその不幸の原因の一つかと思います。

 

しかしそれでも、テスト駆動開発を理解するために、他の実践本よりも先に読む意義は大きいと思います。

 

以上、テスト駆動開発における誤解が解けた。ケント・ベックの原典の要点と感想。でした。