GitHubに登録してみた

来週の勉強会発表用にソースを公開しようと思っていたので,GitHubに登録してみることに.
メモとして残してみます.

主に参考にしたのはこちら.
githubの使い方: Railsアプリの作成からgithubへのはじめてのpushまで – memo.yomukaku.net http://memo.yomukaku.net/entries/194

1.GitHubの準備
ローカルでGitを使える環境は整えてあったので,ここから.
まずは登録する.
https://github.com/plans
公開予定のもので試してみるので,無料プランを選択.
必要事項を埋めると登録完了.

次に,認証の設定をします.
GitHubではSSH公開鍵認証を使うので,鍵の準備.
herokuに登録したときとかも全部別の鍵を作ってるんだけど,これって一緒でも良かったんだろうか..
ここでは新しく鍵を作ることにして話を進めます,
ssh-keygen -t ssh
ファイル名は
/Users/(user_name)/.ssh/github
に.

2.ローカルでRailsプロジェクトの作成
さくっと作ります.Railsのプロジェクト用のディレクトリにcdしてから,
必要ならrvmで適当なgemsetを作ってrvm use してから,
# 新規Railsプロジェクトの作成
rails new pdf_bills
# 作ったRailsのディレクトリに移動
cd pdf_bills
# git管理対象外のファイルを設定
vi .gitignore
>>
.bundle
db/*.sqlite3*
log/*.log
*.log
tmp/**/*
tmp/*
*.swp
*~
.DS_Store
<<

# gitの新規リポジトリの作成
git init
# gitに全ての更新ファイルをindexしてcommit
git add .
git commit -m “Initial Commit”

3.GitHubにPush
GitHubで新規リポジトリを作成します.
https://github.com/new
ここではpdf_billsというpublicのリポジトリを作成して公開しました.

sshの秘密鍵のファイル名がデフォルトではないので,次の設定が必要
参考:
github に登録する公開鍵ファイルを id_rsa.pub じゃない名前で使いたい→ ~/.ssh/config で解決 – 刺身☆ブーメランのはてなダイアリー http://d.hatena.ne.jp/a666666/20081219/1229696368
Help.GitHub – SSH issues http://help.github.com/ssh-issues/
vi ~/.ssh/config
>>
Host github.com
User git
Hostname github.com
PreferredAuthentications publickey
IdentityFile /Users/(user_name)/.ssh/github
<< IdentityFileはフルパスで指定した方が良さそうです. GitHubにリモートリポジトリを追加してPushします. git remote add origin git@github.com:tokyoster/pdf_bills.git git push origin master GitHub上で自分のプロジェクトを見てみると追加されたのが確認できました.

膨らみすぎて手が付けられないコードの管理方針を考えてみた

皆様,こんにちは.

もう今年の残りが一年の24分の1程度しかないことに先ほど気づいたところであります.

年末と言えば,大掃除.

私は片付けが苦手すぎて服とか本とか捨てられずに困っているのですが,パソコンの中も同じです.

3年近く同じ環境で引き継ぎもなくコードを書き溜めていたので,収拾がつかなくなってきました.

これはまずい.

いろいろ苦労しながら書いたコードも,どこにあるか探せなくなってしまっては宝の持ち腐れです.

というわけでこれからコードをまともに管理できるようにするために,

現状分析と指針を箇条書きでまとめてみました.

「もっといい方法があるのに」とか「こういう管理方法があるよ」とか,

「それはないわーww」でもいいので突っ込みお待ちしております.

======

何の為にコード管理をするのか?

  • 効率の良い開発のため
    • 新規の処理の追加
    • バグ取り
  • 効率の良い引き継ぎのため
    • 機能単位の把握
    • 必要なファイルだけ着目できる(不要な/非本質的なコードの除外/不可視化)
  • 効率の良いバックアップのため
    • 変更履歴の追跡
    • 漏れのないバックアップ

現状はどうしているのか?

  • スクリプトはnote(yymmdd)_(script_name).m
  • 関数はfnote(yymmdd)_(function_name).m
  • matlab/code ディレクトリにまとめて配置
  • 最近Gitを導入した

どのような問題があるのか?

  • 古いコードが多すぎて,どれが使えるのかよくわからない
  • Gitの管理単位が大きすぎて(Codeディレクトリすべて)変更を追いにくい
  • ファイル名は確実にユニークだが機能ベースでの検索に向いていない

解決方策

  1. プロジェクト単位でディレクトリを分ける
    • プロジェクトの中だけパスを通せばいいようにする
      • 逆に他のプロジェクトと相互依存しないようにする
      • 関係のないプロジェクトはパスから外す
      • 違うプロジェクトと同じ名前の関数があってもぶつからなくなる
      • 同じ機能の改良版なども比較的容易に作れるし扱える
    • 何をしているのかわかりやすい
      • ドキュメントもプロジェクト単位で作成すればよい
  2. Gitをもっと使いこなす
    • 卒論サーバーにでもリポジトリを作る
      • 本体が壊れても大丈夫
    • プロジェクト単位でGitのリポジトリを作成
      • 同名ファイルの重複が避けられる
  3. ファイル名のルールを変更する
    • 機能だけちゃんとあらわしている名前を付ける
      • ファイル名の一意性が必要ない
    • プリフィクスなどもつけない(関数に”f”など)
      • 基本的に関数ベースにする
  4. 開発方針の変更
    • 機能単位の分割(カプセル化)
      • 本文の長いコードは読みにくい
      • できるだけこまめに分割し,コメントだけでなく名前で機能を語らせる
      • 基本的に関数ベースにする,テスト以外はスクリプトを使わない

Git Immersion (Git漬け)を訳しながら使い方を覚えてみる.その6

久々にGitをいじってみています,

何やってたか忘れるなー(汗)

LAB 11 エイリアス(別名)

目標:gitコマンドのエイリアス(別名)とショートカットの設定法を学ぶ

git status, git add, git commit, あとgit checkout は略語があったら便利なコマンド.

ホームディレクトリにある.gitconfig というファイルの中に次の内容を書き加えよう.

[alias]

co = checkout

ci = commit

st = status

br = branch

hist = log –pretty=format:\”%h %ad | %s%d [%an]\” –graph –date=short

type = cat-file -t

dump = cat-file -p

これでcheckout,commit,statusはカバーできた.

あと前回のlogもカバーしよう.

これでgit checkout と打ちたくなったところでどこでもgit co と打てるようになる.

同様にgit statusの代わりにgit stを,git commitの代わりにgit ciを使える.

何より良いのはgit histを使うことで,長いlogコマンドを打たなくても良くなることだ.

Git Immersion (Git漬け)を訳しながら使い方を覚えてみる.その5

ぼちぼちと進めます.

LAB 9 変更であって,ファイルではない

http://gitimmersion.com/lab_09.html

目標:gitはファイルではなく変更について機能することを学ぶ

ほとんどのソースコントロールシステムはファイル単位で機能する.ソースコントロールにファイルを追加するとシステムはその時点からファイルの変更を追跡する.

Gitはファイル自体というよりファイルに加えられた変更に着目する.git add file というのはリポジトリにそのファイルを追加させる命令ではない,むしろ後々コミットされる前に現在のファイルの状態を記録させておくということだ.

このLabではこの違いについて掘り下げてみよう.

1.最初の変更:デフォルトの名前も許可する

Hello Worldプログラムを変更して引数がない場合の既定値をもたせる.

vi hello.rb

name = ARGB.first || “World”

puts “Hello, #{name}!”

2.変更を追加する

git add hello.rb

3.二回目の変更:コメントの追加

ここでコメントも追加する.

vi hello.rb

# Default is “World”

name = ARGV.first || “World”

puts “Hello, #{name}!”

4.現在の状態を確認する

git status

このように出力されるはず.

# On branch master

# Changes to be committed:

# (use “git reset HEAD <file>…” to unstage)

#

# modified: hello.rb

#

# Changed but not updated:

# (use “git add <file>…” to update what will be committed)

# (use “git checkout — <file>…” to discard changes in working directory)

#

# modified: hello.rb

#

この状態でhello.rbがどのように二回挙げられているかに注目してほしい.最初の変更(デフォルトの名前の設定)はステージングされていてコミットの準備ができている.二回目の変更(コメントの追加)はステージングされていない.このままコミットすれば,コメントはリポジトリに保存されないだろう.

やってみよう.

5.コミットする

ステージングされた変更(初期値設定)をコミットしてから,もう一度状態を見てみよう.

git commit -m ” Added a default value”

git status

$ git commit -m ” Added a default value”[master 03ea0e0] Added a default value

1 files changed, 2 insertions(+), 1 deletions(-)

$ git status

# On branch master

# Changed but not updated:

# (use “git add <file>…” to update what will be committed)

# (use “git checkout — <file>…” to discard changes in working directory)

#

# modified: hello.rb

#

no changes added to commit (use “git add” and/or “git commit -a”)

ここでstatusコマンドはhello.rbの変更は保存されていないが,ステージングエリアにはもうないことを示している.

6.二回目の変更を追加する

二回目の変更もステージングエリアに追加してからgit statusを実行してみよう.

git add .

git status

注:ここでファイルを追加するのにカレントディレクトリ(‘.’)を使った.これはカレントディレクトリ以下の変更された全てのファイルを追加できる便利なショートカットだ.しかし全部追加するにしても,コミットするつもりのないファイルを追加することのないように,addする前にstatusをチェックしたほうがいい.

“add .”といううまいやり方があるのも知ってほしいのだが,このチュートリアルでは今後も安全のためにファイルを明示してaddすることにする.

出力はこうなる.

# On branch master

# Changes to be committed:

# (use “git reset HEAD <file>…” to unstage)

#

# modified: hello.rb

#

7.二回目のコミット

git commit -m “Added a comment”

LAB 10 履歴

http://gitimmersion.com/lab_10.html

目標:プロジェクトの履歴の見方を学ぶ

これまでの変更履歴のリストを見るには,git log コマンドを用いればよい.

git log

すると,こう出力されているはず.

commit b2a48e09bc05afbacbd3b1f53fae63eb86e19dd0

Author: Yoshiteru Toki <~~~~~@gmail.com>

Date: Tue Aug 16 21:07:45 2011 +0900

Added a comment

commit 03ea0e092b1a63e7215afb4500d255c0dbf6cf3f

Author: Yoshiteru Toki <~~~~~@gmail.com>

Date: Mon Aug 15 17:08:18 2011 +0900

Added a default value

commit 8888ecf86f8eb5853ad1b22d751d7190fcb5d6c6

Author: Yoshiteru Toki <~~~~~@gmail.com>

Date: Mon Aug 15 16:19:01 2011 +0900

Using ARGV

commit 718f5be1d67298f201db8cca8211d0c8ee313444

Author: Yoshiteru Toki <~~~~~@gmail.com>

Date: Mon Aug 15 14:06:23 2011 +0900

First Commit

これはここまでリポジトリに追加した,全部で4つのコミットのリストだ.

1.一行での履歴

logコマンドで表示される履歴は実際の必要以上に多い.一行形式で表示してもいい.

git log –pretty=oneline

出力は,

b2a48e09bc05afbacbd3b1f53fae63eb86e19dd0 Added a comment

03ea0e092b1a63e7215afb4500d255c0dbf6cf3f Added a default value

8888ecf86f8eb5853ad1b22d751d7190fcb5d6c6 Using ARGV

718f5be1d67298f201db8cca8211d0c8ee313444 First Commit

2.表示するエントリを指定する

表示する履歴を選択するオプションはいくつもある.以下のオプションを試してみよう.

git log –pretty=oneline –max-count=2

git log –pretty=oneline –since=’5 minutes ago’

git log –pretty=oneline –until=’5 minutes ago’

git log –pretty=oneline –author=’Yoshiteru Toki’

git log –pretty=oneline –all

3.ちょっと複雑な指定

先週の変更部分を見直すためにはこうする.

自分の変更だけ見たかったら,”–auther=Toki”とか付け足せばいい.

git log –all –pretty=format:”%h %cd %s (%an)” –since=’7 days ago’

4.究極のログの形式

やがて,自分にとって一番やりやすいこんな形式を使うようになった.

git log –pretty=format:”%h %ad | %s%d [%an]” –graph –date=short

出力すると,見た目はこうなる.

* b2a48e0 2011-08-16 | Added a comment (HEAD, master) [Yoshiteru Toki]
* 03ea0e0 2011-08-15 |  Added a default value [Yoshiteru Toki]
* 8888ecf 2011-08-15 | Using ARGV [Yoshiteru Toki]
* 718f5be 2011-08-15 | First Commit [Yoshiteru Toki]

詳しく見てみよう.

・–pretty=”…” というのは出力形式の定義.

・%h というのはそのコミットのハッシュ値.

・%d はコミットの付属情報.(たとえばブランチの頭とかタグとか)

・%ad は変更された日付

・%s はコメント

・%an は変更者名

・–graph はコミットツリーをアスキーグラフレイアウトで表示することを示す.

・–date=short は日付形式を短くする

いろんな形式でログを見たいときがある.幸い,次のLabでgit aliasesについて学ぶことができる.

5.その他のツール

ログの履歴を見るとき,Macならgitx,ほかのプラットフォームでもgitkというのが便利だ.

Git Immersion (Git漬け)を訳しながら使い方を覚えてみる.その4

なかなか進められないけど地道にアップします。

LAB 7 ステージに乗せてコミットする

Gitにおいて分離されたステージに乗せる操作は,これまで自分でソースの管理をする必要があった状況から抜け出すための哲学にのっとっている.

自分の作業用ディレクトリに変更を加え続けることができ,またソース管理に関わりたいときには,gitによって細かいコミットの実際の作業記録における変更を残しておける.

たとえば,a.rb, b.rb, c.rbという3つのファイルを変更した時について考えよう.全ての変更をコミットしたいが,a.rb とb.rb は一つのコミットで,c.rb は最初の二つのファイルと論理的につながらないので別のコミットにすべきである.

こうすればよい.

git add a.rb

git add b.rb

git commit -m “Changes for a and b”

git add c.rb

git commit -m “UNrelated change to c”

ステージに上げる操作とコミットの操作を分けることで,コミットに加える変更を調整することができるようになる.

LAB 8 変更をコミットする

目標:リポジトリに変更をコミットする方法を学ぶ

1.変更をコミットする

OK.ステージングについてはもう十分だろう.ステージングした変更をリポジトリにコミットしてみよう.

以前最初のバージョンのhello.rbファイルをリポジトリにコミットするためにgit commitを使った時,-mフラグを含めてコマンドラインからコメントを追加した,そのcommitコマンドによってコミットに対話的にコメントを編集することができる.それじゃあやってみよう.

コマンドラインで-mフラグを省くと,gitはエディタを選択するように求めてくる.エディタは以下のリストから選ばれる.(優先度順)

・環境変数のGIT_EDITOR

・core.editorの設定

・環境変数のVISUAL

・環境変数のEDITOR

// 自分の環境では環境変数で設定するのがうまくいかなかったので

// git config –global core.editor “vi”

エディタの設定をしたらcommitで状態を見てみよう.

git commit

設定したエディタが出てくるので,最初の行にUsing ARGVと書き加える.

Using ARGV

# Please enter the commit message for your changes. Lines starting

# with ‘#’ will be ignored, and an empty message aborts the commit.

# On branch master

# Changes to be committed:

# (use “git reset HEAD <file>…” to unstage)

#

# modified: hello.rb

#

[master 8888ecf] Using ARGV

1 files changed, 1 insertions(+), 1 deletions(-)

2.状態チェックする

最後にもう一度状態をチェックしてみよう.

git status

すると,出力はこうなるはず.

# On branch master

nothing to commit (working directory clean)

作業用ディレクトリはクリーンで,続行できる状態だ.

Git Immersion (Git漬け)を訳しながら使い方を覚えてみる.その3

1日2項目じゃ遅いかな?と思いはじめた今日この頃です。

ついでに、英語力も足りない怪しい直訳がダサすぎて死にそうなんて言えない←

LAB 5 変更を加える(作業用ディレクトリ)

http://gitimmersion.com/lab_05.html

目標:作業用ディレクトリの状態の追跡の仕方を学ぶ

1.”Hello, world”プログラムを変更する

HelloWorlsdプログラムを変更してコマンドラインから引数を一つとれるようにする.

変更後のファイルは次のようになる.

vi hello.rb

puts “Hello, #{ARGB.first}!”

2.状態を調べる

作業用ディレクトリの状態を調べてみよう.

git status

出力はこうなる.

# On branch master

# Changed but not updated:

# (use “git add <file>…” to update what will be committed)

# (use “git checkout — <file>…” to discard changes in working directory)

#

# modified: hello.rb

#

no changes added to commit (use “git add” and/or “git commit -a”)

最初に注意しないといけないのはgitはhello.rbが変更されたことを検知していることだ.でもgitはこれらを通知されてはいない.

もう一つ注意すべきは,この状態メッセージは次に何をする必要があるのか示唆してくれる.

もしこれらの変更をリポジトリに加えたいなら,git add コマンドを使えばいい.

そうでなければgit checkout コマンドで変更を破棄することができる.

3.次の段階へ

変更をステージに乗せてみよう.

// stage -> コミット前の緩衝地帯のことらしい.

LAB 6 変更をステージングする

http://gitimmersion.com/lab_06.html

目標:最新のコミットの変更をステージングする方法を学ぶ

1.変更を加える

ではgitに変更を反映させて状態を見てみよう.

git add hello.rb

git status

# On branch master

# Changes to be committed:

# (use “git reset HEAD <file>…” to unstage)

#

# modified: hello.rb

#

hello.rbファイルの変更が反映された.

これはgitはその変更内容を知っているが,この変更はまだリポジトリに記録されてはいない.

次のコミット操作がリポジトリに変更を加える.

結局変更をコミットしたくない場合には,git reset コマンドを使って変更をステージから削除することができることをstatusコマンドが思い出させてくれている.

Git Immersion (Git漬け)を訳しながら使い方を覚えてみる.その2

まったり追記していきますよ.

今回はLAB3と4.

リポジトリ(倉庫,貯蔵所,宝庫)ってそのままカタカナで呼ばれてるけど,あえて訳すならなんなんだろ?

なお,作業履歴もかねているのでシェルコマンド部分も書いてます.

エディタはviを使っているので,適宜読み替えてください.

LAB3 プロジェクトを作る

http://gitimmersion.com/lab_03.html

目標:スクラッチで(=ゼロから)Gitのリポジトリを作成する方法を学ぶ

1.”Hello world”プログラムを作成する

空の作業用ディレクトリ(さっき解凍したwork)から作業を始める.

cd work

helloという名前でディレクトリを作る

mkdir hello

cd hello

hello の中にhello.rbを作成する.中身は以下.

vi hello.rb

puts “Hello, World.”

2.リポジトリを作成する

ここまでで一つのファイルからなるディレクトリができている.

このディレクトリからリポジトリを作成し,gitのinitコマンドを実行する.

git init

Initialized empty Git repository in /home/toki/git_tutorial/work/hello/.git/

3.プログラムをリポジトリに追加する

Hello, worldプログラムをリポジトリに追加しよう.

git add hello.rb

git commit -m “First Commit”

出力はこうなる.

[master (root-commit) 718f5be] First Commit

1 files changed, 1 insertions(+), 0 deletions(-)

create mode 100644 hello.rb

LAB 4 状態を調べる

http://gitimmersion.com/lab_04.html

目標:リポジトリの状態の調べ方を学ぶ

1.リポジトリの状態を調べる

git status コマンドを使えばリポジトリの状態を調べることができる

git status

# On branch master

nothing to commit (working directory clean)

このstatusコマンドはコミットされたものがないことを示している.

これはリポジトリの中が全て作業用ディレクトリの最新の状態であることを表している.

未適用の記録の変更はない.

git statusコマンドは継続してリポジトリと作業用ディレクトリの状態の差を追跡する時に使う.

Git Immersion (Git漬け)を訳しながら使い方を覚えてみる.その1

Railsや研究用のMATLABでソースを書き散らしているうちに,修正個所と内容が把握できなくなってきた.

ほぼ同じ内容のバックアップが大量にあるような状態で,手が付けられない.

と,いうわけでバージョン管理システムのGitを導入してみる.

参考にしたのはこのチュートリアル.

Git Immersion

http://gitimmersion.com/index.html

Git漬け,って感じですかね.英語漬けみたいな.

とりあえずUbuntu環境に入れてみる.

$ sudo apt-get install git-core

(※いつの間にか入れてたらしい.)

バージョンを確認.

$ git –version

git version 1.7.0.4

LAB 1 Setup

http://gitimmersion.com/lab_01.html

目標:作業の準備のためにGitを設定する

1.名前とEmailの設定

$ git config –global user.name “Your Name”

$ git config –global user.email “your_email@whatever.com”

2.行末の設定

//Ubuntuに入れたのでUnix/Mac用の設定にする

$ git config –global core.autocrlf input

$ git config –global core.safecrlf true

LAB 2 More Setup

http://gitimmersion.com/lab_02.html

目標:チュートリアル用の素材を取得して実行する準備をする

1.Gitのチュートリアルパッケージを取得する

$ wget http://onestepback.org/download/git_tutorial.zip

2.チュートリアルパッケージを解凍する

// の,前にunzipが入ってなかったのでインストール

// $ sudo apt-get install unzip

$ unzip git_tutorial.zip

git_tutorialの中身は,

html:このチュートリアルのHTMLファイル一式

work:空の作業用ディレクトリ.この中にリポジトリを作る.

repos:予めパッケージ化されたリポジトリ.workにコピーすれば任意の場所からチュートリアルを始められる.

2~3章ずつ訳してアップしていけばいいかな.