プロキシサーバー下でのGitの設定

プロキシサーバー内でGitの設定を行う場合、http.proxyを設定します。

git config --global http.proxy proxy.host:8080

認証がある場合は、ユーザーID:パスワードを先頭に追加し、@で区切る

git config --global user:password@http.proxy proxy.host:8080


ん？パスワードに@があってうまくいかん！という場合は@をURLエンコードした値(%40)を使用する。
例えば、ユーザーID = user パスワード=p@sswordである場合、以下のように設定する。

git config --global user:p%40ssword@http.proxy proxy.host:8080

設定値は git config --global --list で確認可能。

GitHub リポジトリ内のソースコードの検索を行う

GitHubのリポジトリであのメソッドの定義を確認したい、ということが少なからずあるが、標準の検索で引っかからず仕方なくfork/cloneする・・・めんどくさい！と思ったことはないだろうか。

そんなときに仕えるのがAdvanced Searchのオプション。リポジトリ内のソースは以下のように検索できる。

repo:lift/framework  AddUserMenusAfter
例：Liftフレームワーク内のAddIserMenusAfterの定義を検索

repo:ユーザー名/リポジトリ名 検索キーワード で検索ができる。上記の例をそのまま検索窓に入れるときちんと検索されるはず(なぜか何個も引っかかるが・・・)。

これ以外にもいくつか使えるオプションがあり、それは こちら 参照（使えんオプションが多いのは気のせい？）。

これでわざわざローカルに落とす手間が省けます。

＜参考＞
Search code inside a Github project

作業の流れで覚える Git コマンド

Gitのコマンドについて、大体の作業の流れに沿ってまとめました。GitHub想定。

○初期設定編

*ユーザー名/メールアドレスの設定

git config --global user.name "Suzuki Taro"

git config --global user.email taro@example.com

*エディタの変更

git config --global core.editor notepad

*改行コードの扱い

大体GitHub上にあがっているのは改行コードLFなので、Windowsの場合以下の設定をしておくとチェックアウト時LF - >CRLF、コミット時CRLF->LFの変換を自動で行ってくれる。

git config --global core.autocrlf true

Mac/Linuxの場合はCRLFが混じっていると困るので、チェックアウト時CRLFをLFに換えてくれる設定をしておくとよい。

git config --global core.autocrlf input

*プロキシ環境の場合
ユーザ認証なし
$git config --global http.proxy http://proxy.server.com:port

ユーザ認証あり
$git config --global http.proxy http://user:pass@proxy.server.com:port

設定結果の確認
$git config --get http.proxy


参考サイト：ssh over proxyでgithubをアクセスする（Windows）

○通常時編

1.ソースをとってくる(forkした後の自分のリポジトリから～というイメージ)

git clone git@xxxxxxxx.git

2.ソースの編集後、リポジトリに追加

git add . 

3.コミット

git commit -m "メッセージ"

4.リモートにアップロードするため、リモートを追加

git remote add リモート名(originなど) master

5.リモートに送信

git push リモート名 master

○初めてのpull Request編

1.通常時編と同様。リポジトリをフォーク＋クローン

2.ブランチを作成　※決してmasterで作業しない。

git checkout -b (ブランチ名)

ブランチ名はxxSpikeなどSpikeをつけたりdevelopとしたり・・・といろいろあるようだが、見たところ修正点がわかれば何でもいい感じだ

3.fork元のリポジトリを変更追尾用のupstreamとして登録しておく

git remote add upstream git://ｘｘｘｘｘｘ.git

4.ブランチで作業(git add / git commit)

5.fork元を更新し、元リポジトリで更新が行われていないか確認

git checkout master

git pull upstream master

マスターブランチに移動して、pullで更新するそのあと自分のブランチに戻り、差分確認。

git checkout myBranch

git diff master

横着する場合は、リモートのブランチと直接比較する方法もある。元リポジトリのmasterブランチと現在のブランチの差分を比較している。

git diff upstream/master

万が一変更が行われていた場合、rebaseなどを使用し対応。ここは細かい話になるため、その他の詳細記事を参照。

6.pull Request

元リポジトリの差分を取り込んでおり、自分の変更点はbranchにまとまっている！となれば、githubにpushし、その後pullRequestを行う(これは画面から行う)。

git push origin ブランチ名

※originはGitHubのリモート

事前にコミットまとめなさいよ、という話があるかもしれない。実際そうしたほうがいいが、マージをする際に取り込むブランチ上のコミットはまとめることができるので、そこまでするかなという気もする（タイプミスとかは確かにアレだが・・・）。

まとめる場合、rebaseを使用する。こちら を参考。

なにより、小さく速くやる、ということがpull Requestでは重要と思う。

○あるある編

*gitignoreを追加するのを忘れたので、直前の git add . を全部取り消したい

git rm -r --cached .

*git addでの変更内容を事前に確認したい

git status もしくは

git diff  --cached

※ファイルの一覧でいいんだよ！という場合は 

git diff --cached --name-only

--cachedってなんなの？という場合こちらを参考。

git diff の使い方がほんの少し理解できた

*コミットメッセージに誤字脱字。修正したい

git commit --amend -m "(新しいコミットメッセージ)"

git commit --amend で、単純にコミットの取り消しになる。

*コミット先を間違えた。取り消したい

git reset HEAD^

上記に引き続きとても分かりやすい記事があるのでこちらを参考。みんなHEADとかインデックスとか何言ってんの？という場合にもとても良いです。

git reset についてもまとめてみる

*削除したファイルがgit addで追加されない
git add -u
を実行

ソースコードのバージョン管理の考え方

ソースコードのバージョン管理については、GitやSubversionなどの様々なツールがある。最近導入の検討を行ったが、「そもそもどういう風にバージョン管理をしたいのか」という明確な戦略がないと、ツールの操作と手間に振り回されてしまうと感じた（振り回されたのだが・・・）。

なので、まずはバージョン管理の目的とその戦略についてまとめてみた。


＜バージョン管理の目的＞
バージョン管理の目的は２つあると思われる。

１．マイルストンの設置
　ある時点の安定した状態を記録しておき、いざというときにそこに戻れるようにする。また、そこからどのような作業が行われたのか、差分を確認できるようにする。リリース管理ともいえる。

２．分業の実施
　分業を実施するため、個々人（あるいはチーム）の作業エリアを別々のバージョンとし、最終的にマージを行う。

サウンドノベルのゲーム（かまいたちの夜etc）などをやったことがある人は、ゲームオーバーになった時どの章から再開するのか選べて便利だな、と思ったことはないだろうか(下図参照)。

これは立派なバージョン管理ではないか。①のマイルストンの管理ができていることで、ここまではうまくいっていたのにな～というところから再スタートできる。

ゲームでは分業することはあんまりないと思うが、仮に上記のようなゲームの攻略本を作るとしたら、「オマエはAルートで俺はBルート」のような形で担当を分け、最後にお互いのセーブデータをマージする・・・ということができたらいいだろう。

この時の「お互いのセーブデータ」がつまるところバージョンに当たり、②の目的で使っていることになる。

＜バージョン管理の戦略＞

では、どのような形でバージョン管理を行えばよいだろう。バージョン管理の手法としては、以下２つが考えられ、これはなにもソースコードの管理だけでなく企業の予算立案などでも使われている考え方である。

１．スナップショット型

ある時点での作業内容を保管しておくことで、バージョン管理を行うタイプである。これは、先ほどのサウンドノベル型に近い。

登場するバージョンは基本的に　作業バージョン・リリースバージョンの２種類である。作業バージョンでの作業がひと段落したら、その時の状態をリリースバージョンとして保管するという形式である。

○メリット

作業する場所が一つなので、作業はしやすい。複数機能を開発している場合、いい意味でも悪い意味でも、既存への影響を早めに知ることができる（同じ場で作業しているので）。

×デメリット

性質上ある機能の分だけ切り出すということは難しい。そのため、複数の機能が同時並行的に開発されていて、できた機能は一刻も早くリリースしたい・・・というような環境では不向き。

上記の例だと、機能Bの開発終了段階ではまだ機能Aの開発が終わっていないため、単純に作業バージョンをコピーするのでなく、安定板であるVer1に対し機能Bの変更のみ反映させるといった作業が必要になる。

→大きい機能でも、リリース可能な状態をキープする戦略があるとよいか。

上記点を考えると、開発する機能・納期が明確に決まっているような案件の場合、または特定機能を全員で開発していくような場合に向いていると思われる。

２．ローリング型

作業を始める前に、その作業を行うための箱を作る方式。

○メリット

他の開発の影響を気にすることなく作業できる。それと、万が一やっぱりこの機能やめた、という場合でも作業用のバージョンを消すだけで済む。

×デメリット

他機能がリリースされた際、そのリリース内容を取り込みながら開発を行っていく必要がある。そのため、長期にわたる機能開発の場合取り込み作業が大変。また、他機能の開発で自分の機能に大きく影響を与える変更があった場合、その検知が遅れることになる。

→機能開発のサイクルを一定にする工夫があると運用しやすいか（長短入り乱れると長の開発が割を食う）

上記点を考えると、不特定多数で作業する場合やリリースする機能は作りながら決めるぜ、というような場合に向いている。

以上が、バージョン管理の目的とその戦略についてである。ツールを選ぶ前にこの辺りをよく考えておくと、どんなツールでどういう風に管理するのがいいのか見通しが立てやすくなると思う。

AppHarbor と GitHub の連動設定(ServiceHook)

GitHubにpushしたらAppharborにも自動的にpushしたい！という場合ServiceHookの機能を使用する。その設定方法について解説します。

まず、GitHub側のリポジトリのAdminからServiceHookを選択

Appharborの設定は以下のようになっている。

ここで、Application SlugとTokenは、Appharbor上の以下の設定を入れる。

・Application Slug

 Appharbor上のアプリケーション名

 (カンマ区切りと言うことなので他のものでもいいのかもしれない)

・Token

BUILD URLの、authorizationの値を設定する。BUILD URLをクリックするとクリップボードに値がコピーされるので、それをテキストエディタなどに貼り付けてauthorizationの値をTokenに設定する

あとはActiveにチェック。

こうすることで、GitHubにpushするとAppharborにも反映されるようになる(ブランチがmaster以外の場合どうなるの？という点はちょっと未確認)。

ASP.NET サイト/アプリを 無償クラウド AppHarbor にて公開する

.NETで作ったアプリを公開したい！という場合、公式クラウドAzureに無償枠はないため、作ったアプリはいつかお金を払わなければ捨て去る以外にありません。
もっと自由にアプリを作りたいが金はない、という場合.NETのPaaSであるAppHarborの使用をお勧めします。

AppHarborは.NETアプリケーション用のクラウド環境で、無料から使用できSQLServerなどのDBもつかえます。また、Azureのように「Azure専用」にアプリケーションを作成する必要がなく、いつもどおり作ったアプリケーションを配置することが出来ます(Azureをｘｘしているわけでは、ない)。

＜AppHarborの使用手順＞
１．Windows用Gitのインストール
以下サイトを参考にインストールを行います。
Set Up Git

途中で”コマンドプロンプト(cmd)からも使えるようにするか”と聞いてきますので、これはYesにしておいたほうが便利です。

２．Webサイト／Webアプリケーションを作る
いつもどおりWebサイトやWebアプリケーションを作ります。
※Webアプリケーションでないと駄目だという情報が幾つかありましたが、少なくともASP.NETの通常のWebサイト(MVCでない)はデプロイ可能でした。

３．ローカルリポジトリを作成する
コマンドプロンプトでWebサイト／Webアプリケーションのフォルダに移動し、
git init
を実行します。

～いろいろファイルを編集～

４．変更内容をローカルにコミットする
以下コマンドで、変更をローカルにコミットします。
git add .
git commit -m "my first commit"

※このあたりの詳細は、Gitの使い方を参照してください。

５．ローカルのコミットをAppHarborに反映する
AppHarborでは、事前にアカウントをつくりアプリケーションを作っておきます。
アカウントを作った後のトップ画面で、Create new application　の箇所にアプリケーション名を入れてCreateボタンを押せばＯＫです。名前は２で作成したものと同名にしておいたほうが懸命と思われます。

AppHarborでアプリケーションが作られると、以下のようなメニューが表示されると思います。
一番下にある「REPOSITORY URL」をクリックすると作成したアプリケーションのリポジトリがクリップボードにコピーされます。その内容を、

 git remote add appharbor ｘｘｘｘ

のｘｘｘｘの部分と置き換えてコマンドを実行してください。

現時点でのイメージは以下のようになっています。
AppHarbor上にリポジトリをつくり、そのremote宛先をaddで登録したところです。

 宛先の登録が終わったら、以下コマンドで発行を行います。

git push appharbor master

このコマンド後コンパイルが走り、しばらくするとWebサイトが発行されます。先ほどのメニューのHostnamesというところから、作成されたWebサイトのアドレスが参照できます。

発行後ファイルに変更を加えた場合は、手順４からの作業(登録除く)の繰り返しになります。
Gitのコマンド的には以下の通りです。
～ファイル変更～

git add .
git commit -m "my second commit"
git push appharbor master

※commit時のメッセージ内容は自由です。


※その他※
・PreCompileについて
AppHarbor上でプリコンパイルがデフォルトオンになっているせいか、App_Codeのフォルダがサイトに含まれているとエラーになります。
これを回避する場合、SettingsにあるBuildの箇所で、プリコンパイルをオフにしてください。

・SqlServer/EntityDataFrameworkの使用について
アドオンを追加することで可能になります(20MまでフリーのDBあり)。
接続文字列はConfiguration Variableを使用するか、SqlServerの詳細画面から確認可能です。

Entity Frameworkを使用する場合は、Entity Framework metadata:のところにEntityDataFrameworkを使用するとweb.configに勝手に挿入されるconnectionStringの"res:～.msl"の部分を設定するとEntityFramework用の接続文字列を作成してくれるので、それをweb.configに設定すればきちんと動きます(自動で変換してくれるといううわさも聞いたが、そんなことはなかった)。

動作は.NetFramework4.0/EntityDataFramework4.0で確認しました。


・Git Hubについて
せっかくGitを使っているので、Git Hubに登録するのはアリだと思います。Git Hubはソースコードを共有するためのサービスで、Rubyなどのプロジェクトではかなり良く使われています。
Git HubからAppHarborにつなぐことも出来るようなので、これを機会に試してみても良いと思います。

githubでかっこいいREADMEを書く

githubにアップしたプロジェクトでは、READMEがトップに表示されるようになっており、これがきちんと書かれていると結構目を引く。
ただ、書き方がよくわからない！という場合は他の人をまねすればいい。

適当な、READMEがきちんとしているプロジェクトにアクセスしREADMEをクリックして参照する。ここで「RAW」と書かれているボタンをクリックすると生のファイルが閲覧できるので、どういうふうに書けばどう表示されるのかだいたい分かる。

あとは、このファイルを元に編集していけば良い。すばらしい方がオンライン上でプレビューできるツールを作ってくださっているので、そこにRAWで取得した内容をコピペして編集すればより精度は高まる。

githubプレビューツール