2012年01月

GitHubの使い方

GitHubの使い方を全く知らない人に説明するための手順書です。

※社内向けに書いた記事の再掲です。

まず、githubのアカウントをとろう

githubにアクセス可能にする(社外)

github に SSH 公開鍵を登録する。リンク先参照。

GitHubにSSH公開鍵登録

Cygwinにgitを入れる(ついでに、wget と vi と gcc も入れておくと良し)

Git初期設定

githubにアクセス可能にする(社内)

プロキシ経由でアクセスできるようにする。「githubにアクセス可能にする(社外)」をやってあるものとする。

wgetを使いたいので、http プロキシを利用するように、HTTP_PROXY 環境変数を設定する。.bash_profile に以下を追加する。

export http_proxy=http://[プロキシユーザ名]:[パスワード]@プロキシサーバ名
export HTTP_PROXY=$http_proxy
export HTTPS_PROXY=$HTTP_PROXY 
export https_proxy=$HTTPS_PROXY

反映

source ~/.bash_profile

connect (SOCKSプロキシ中継ツール)をインストールする。

wget http://www.meadowy.org/~gotoh/ssh/connect.c
gcc connect.c -o connect.exe
mv connect.exe /usr/bin

設定1)

※ git clone git@github.com:yourname/repositoryname.git のように SSH プロトコルでプロキシを介してアクセスするための設定

~/.ssh/config をいじる(なければ新規作成)。以下を追加 

Host github.com
Hostname github.com
ProxyCommand /usr/bin/connect -S [SOCKSサーバユーザ名]@[SOCKSサーバ名]:1080 %h %p
User git
IdentityFile ~/.ssh/id_rsa

~/.bash_profile にSOCKSプロキシパスワードなどを登録しておく。以下を追加。

export SOCKS5_USER=[あなたのSOCKSサーバユーザ名]
export SOCKS5_PASSWD=[あなたのSOCKSサーバパスワード]

反映

source ~/.bash_profile

ssh接続できるか試す

ssh -v git@github.com

以下のように表示されれば成功

....ずらずら
PTY allocation request failed on channel 0
Hi [あなたの名前]! You've successfully authenticated, but GitHub does not provide shell access.
Connection to github.com closed.

成功しない場合は、鍵の場所が違うとか、.ssh/config が読み込まれていないとか、疑ってみよう。頑張れ。

設定2)

※ git clone git://github.com/yoruname/repositoryname.git のように GIT プロトコルでプロキシを介してアクセスするための設定

/usr/bin/git-proxy ファイルを以下の内容で作成する。

#!/bin/sh
/usr/bin/connect -S [SOCKSサーバユーザ名]@[SOCKSサーバ名]:1080 $1 $2

実行許可をだしておく。

chmod a+x /usr/bin/git-proxy

~/.bash_profile にGIT_PROXY_COMMAND環境変数を設定し、上のシェルスクリプトを利用するように登録しておく。

export GIT_PROXY_COMMAND=/usr/bin/git-proxy

反映

source ~/.bash_profile

接続できるか試す

git clone git://github.com/yourname/repositoryname.git

※パスワードなどは、上で設定した SOCKS5_USER, SOCK5_PASSWD 環境変数から読み込まれます。

リポジトリ追加(管理者)

から「New Repository」で。

初回 init する(管理者)

リポジトリ作成時にやり方が出てくるが、例えば yourname に repositoryname リポジトリを作成した場合は、以下のようにしろと言われる。

mkdir repositoryname
cd repositoryname
git init # ローカルリポジトリを初期化
touch README
git add README # ローカルリポジトリにファイルを追加
git commit -m 'first commit' # ローカルリポジトリにコミット
git remote add origin git@github.com:yourname/repositoryname.git # リモートリポジトリをoriginという名前で登録
git push origin master # ローカルリポジトリのmasterブランチをリモートリポジトリ(origin)に反映(push)

developブランチも切ってみる。

git branch develop
git push origin develop

初回 cloneする(個別開発者)

yournameのrepositorynameリポジトリをローカル作業用にダウンロードする。

git clone git@github.com:yourname/repositoryname.git

リポジトリを切り替える(個別開発者)

clone した直後だと、リモートレポジトリに複数のブランチが存在したとしても、ローカルリポジトリには master ブランチしかない。

git branch -a
* master
  remotes/origin/master
  remotes/origin/develop

リモートリポジトリの develop ブランチをローカルレポジトリに持ってきて作業したい場合は、

git checkout -b develop origin/develop

とする。

git branch -a
  master
* develop
  remotes/origin/master
  remotes/origin/develop

ファイルを変更して push する(個別開発者)

カレントディレクトリ以下の新規ファイル全てをadd登録する(必要あれば)

git add . 

変更ファイルを自動検知(-a)してローカルリポジトリにcommit

git commit -a -m '追加した' 

ローカルリポジトリをリモートリポジトリ(origin)に反映。例えば現在のローカルリポジトリのブランチが develop の場合、以下のようにする。

git push origin develop

他人の変更を fetch する(個別開発者)

他人が github にアップロードした変更点をローカルリポジトリにダウンロード(fetch)してくる。

git fetch origin develop

ただし、これはローカルリポジトリの remotes/origin/develop ブランチにダウンロードしてきただけなので、

その変更をローカルリポジトリのカレントブランチ(今回はdevelop)に反映するには、以下のようにする。

git merge origin/develop

ちなみにこの2つの操作は以下のコマンド1つの操作で行うことも可能。

git pull origin develop

git 使い方詳細

以下参照。もしくはググること。

参考文献

git-flow

A successful Git branching model http://keijinsonyaban.blogspot.com/2010/10/successful-git-branching-model.html という Git のうまい運用方法を論じた記事がある。ので、読んでおくこと。

この運用方法に沿った形で git を運用するための補助ツールとして git-flow http://d.hatena.ne.jp/Voluntas/20101223/1293111549 というものがある。ということで、使おう。

git-flow インストール

ここみよう

インストール

wget --no-check-certificate -q -O - https://github.com/nvie/gitflow/raw/develop/contrib/gitflow-installer.sh | sh

確認

git flow
usage: git flow 
 Available subcommands are:
  init      Initialize a new git repo with support for the branching model.
  feature   Manage your feature branches.
  release   Manage your release branches.
  hotfix    Manage your hotfix branches.
  support   Manage your support branches.
  version   Shows version information.
Try 'git flow  help' for details.

git-flow 使い方

新しくローカルリポジトリを作る場合

git flow init
 Initialized empty Git repository in /home/nseo/.git/
 No branches exist yet. Base branches must be created now.
 Branch name for production releases: [master]
 Branch name for "next release" development: [develop]

 How to name your supporting branch prefixes?
 Feature branches? [feature/]
 Release branches? [release/]
 Hotfix branches? [hotfix/]
 Support branches? [support/]
 Version tag prefix? []

featureブランチ

新規機能開発用 feature ブランチを切る。

git flow feature start ticket_500
 Switched to a new branch 'feature/ticket_500'
 Summary of actions:
 - A new branch 'feature/ticket_500' was created, based on 'develop'
 - You are now on branch 'feature/ticket_500'
Now, start committing on your feature. When done, use:
     git flow feature finish ticket_500

ブランチを確認

git branch
   develop
 * feature/ticket_500
   master

ここでfeature/ticket_500ブランチで作業をする

こまめにコミット

git ci -a -m 'hogehoge finished'

最後にfinishするとdevelopブランチにマージされ、feature/ticket_500ブランチが消去される

git flow feature finish
 Switched to branch 'develop'
 Already up-to-date.
 Deleted branch feature/ticket_500 (was d4c5a02).
 Summary of actions:
 - The feature branch 'feature/ticket_500' was merged into 'develop'
 - Feature branch 'feature/ticket_500' has been removed
 - You are now on branch 'develop'

確認するとたしかに消えている

git branch
 * develop
   master

その他

あとは git-flow http://d.hatena.ne.jp/Voluntas/20101223/1293111549 を見ておくこと。

git flow release start タグ名
git flow release finish タグ名
git flow hotfix start タグ名
git flow hotfix finish タグ名

なんかもあるので。

GitHubをすすめる7つの理由

GitHub とは git のプロジェクトホスティングサービスです。git そのものにはない、GitHub ならではの機能が多くあります。ここで、その中から特に GitHub を薦める7つの理由を紹介したいと思います。

※社内向けに書いた記事の再掲です。

理由(1) - ネットワークグラフ

git のブランチ図を GitHub が可視化してくれます。現在、どのようなブランチが存在しており、どの時点から分岐し、マージしたのかが一目でわかります。

NetworkGraph

理由(2) - オンラインレビューコメント

コミットしたソースコードの差分に対して、GitHub のUI上からコメントを付けることが可能です。全員でコードレビューを実施する際には、レビューの最中に該当箇所に指摘を記述したり、回覧レビューを実施する際には、レビューワに指摘をコメントとして残してもらったりすることが可能です。

ReviewCommet

理由(3) - 多数のマークアップ文法に対応

GitHub の Wiki, およびテキストファイルは、AsciiDoc, Creole, Markdown, MediaWiki, Pod, Org-mode, RDoc, Textile, reStructuredText といったマークアップ文法に対応しています。

テキストファイル、特に README をこれらの文法で記述しておくと、GitHub からそのファイルを参照する際に、自動でレンダリングしてくれます。

この機能を利用して、GitHub のレポジトリのトップページを、そのままドキュメントサイトとしているライブラリも多いです。

Markup

Markdown文法で記載したREADMEの例

理由(4) - Stats & Graphs

Stats & Graphs の機能を用いると、誰がどぐらいの割合でプロジェクトに貢献しているのか統計を見ることができます。

Stats

理由(5) - フォーク / プルリクエスト

他の人のレポジトリを分岐させて自分専用のレポジトリを作る機能(フォーク)、また、自分の変更を取り込んでもらうようにリクエストを送る機能(プルリクエスト)があります。

オープンソースプロジェクトをフォークして、パッチを開発し、プルリクエストを送って、パッチを取り込んでもらう、といったオープンソースプロジェクトの開発形態を支援してくれます。

理由(6) - プライベートリポジトリ

有償版を利用すれば、無条件で公開されないプライベートなリポジトリを作成することが可能です。

筆者が現在出向しているリコーのクラウド開発室では有償版を利用しています。価格は例えば、20 レポジトリ、10ユーザの Medium サイズで $22/month です。

理由(7) - 流行り

最近のウェブ界隈では、GitHub が流行っており、採用プロセスにも利用されたりしています。例:https://github.com/esminc/jobs

流行りに乗っておくと、社外勉強会に参加したときなどにも会話になって面白いので、是非使ってみましょう!

Google Cloud Print のご紹介

前回の記事からの続きです。遊びで Google Cloud Print を使うことがあったので、メモがてら Google Cloud Print の紹介をしてみます。

Google Cloud Print の紹介

GoogleCloudPrint

Google Cloud Print (GCP) http://code.google.com/intl/ja/apis/cloudprint/docs/overview.html とは、どこからでも自宅のプリンタでドキュメントを印刷できるクラウド印刷サービスです。

ドライバ不要であらゆるデバイスから印刷機能を利用できるようになるため、ハードウェアやOSごとに対応するドライバーを開発したり、インストールする必要がなくなります。また、例えば通勤中にスマートフォンから書類を印刷しておくことなどが可能です。

利用要件

Google アカウントが必要です。自分の Google アカウントにプリンタを登録しておき、印刷時には登録しているプリンタのいずれかを選択して印刷する形になります。

Google Cloud Print (GCP) 対応のプリンタが必要です。(EPSONHPが出し始めています)

GCP対応のプリンタがない場合でも、Google Chrome を Windows/Mac にインストールし、接続されているプリンタを共有することで、Windows/Mac を踏み台にした Print が可能です。筆者の自宅ではこれを利用しています。

Chrome設定方法 http://support.google.com/cloudprint/bin/answer.py?hl=en&answer=1686197

Android や iOS といったモバイル向けサービスでは、現在、Google Docs, GMail から利用可能です。Google DocsやGmailのメニューの「Print」を選択すると、文書やメールを印刷することが可能です。メールに添付されたPDFファイルやDOCファイルなども印刷できます。

その他のファイルも印刷可能にするアプリも売っているようです。

Cloud Print - Android Market https://market.android.com/details?id=com.pauloslf.cloudprint&hl=ja

仕組み

特に、プリンタドライバを作っている方や、Android/iOSアプリを作っている方がたは、ちょっと気になると思うので、かんたんに仕組みを解説。

Chrome ブラウザを利用している場合

  • モバイル端末からファイルをクラウドにアップロード(http)
  • PC上の Chrome ブラウザがポーリングによって新しいファイルがアップロードされたことを検知(http)
  • Chrome ブラウザがクラウドからファイルをダウンロードし(http)、
  • ブラウザーのレンダラー、および、プリンタドライバを用いて、印刷ファイル形式に変換し、印刷。

GCP対応の(EPSON)プリンタを利用する場合

  • モバイル端末からファイルをクラウドにアップロード
  • クラウドから指定されたプリンタに対してファイルを送信する。その際、XMPPポートが使用されるため、ポートを空けておく必要がある。
  • 印刷
  • ※ 印刷可能なファイル形式にどこでレンダリングしているのが、把握していないのでご存知の方がいらっしゃったら補足おねがいします。GCP対応プリンタがレンダリングしているのか、クラウド側でレンダリングしているのか。

参考

開発リファレンス

Web API が公開されているので、アプリケーションを作成したり、Google Cloud Print 対応のプリンタを開発したりすることができます。開発サイトへのリファレンスも貼っておきます。

AirPrintのご紹介

遊び(といっても職業柄)で AirPrint を使うことがあったので、メモがてら AirPrint の紹介をしてみます。

AirPrint とは

AirPrint http://www.apple.com/jp/iphone/features/airprint.html とは、iPhone/iPad (iOS) からワイヤレスで印刷する仕組みです。Wi-Fi通信圏内にある対応機種を自動検出し、ユーザが機種を選択するだけで印刷を開始できます。iOS側でドライバを用意する必要のない、ドライバレス印刷の仕組みです。

AirPrint

使い方

AirPrint 対応のプリンタと iPhone/iPad を同じWi-Fiネットワークにつなぎ、Safariやメール、写真などの対応アプリで矢印ボタンをタッチし、現れたメニューで「プリント」を選択します。

詳しくはこちら http://news.mynavi.jp/articles/2010/11/25/ios42_3/index.html

AirPrint 対応のプリンタがない場合でも、AirPrint Activator と呼ばれるソフトウェアを Windows/Mac にインストールし、接続されているプリンタを共有することで、Windows/Mac を踏み台にした AirPrint が可能性です。筆者の自宅ではこれを利用しています。

http://www.apple.com/jp/iphone/features/airprint.html

仕組み

特に、プリンタドライバを作っている方や、iOSアプリを作っている方がたは、ちょっと気になると思うので、かんたんに仕組みを解説。

  • 対応しているファイル形式は、TXT、HTML、画像、PDF (いわゆるウェブ) です。
  • 画像、PDFの場合は、ファイルデータをプリンタに渡すと、プリンタが印刷可能なファイル形式にレンダリングしつつ、印刷してくれるようです。
  • TXT、HTML の場合は iOS 上でレンダリングしたものを、プリンタに渡して印刷してもらっているようです。
  • ※ あまり、詳細な仕様が公開されていないので間違っているかもしれません。

参考: http://ylb.jp/iOSDev/AirPrint/AirPrintPublic.pdf

まとめ

iPhone/iPad から直接印刷できる AirPrint はなかなか便利ですね。

A Ruby and Fluentd committer working at DeNA. 記事本文および記事中のコード片は引用および特記あるものを除いてすべて修正BSDライセンスとします。 #ruby #fluentd #growthforecast #haikanko #yohoushi #specinfra #serverspec #focuslight
はてぶ人気エントリー