プログラムの開発環境についてあれこれまとめておく備忘録
GITを使ってプロジェクト管理をするためのメモ。レポジトリはローカルではなくサーバ上に置いて管理することを想定している。
クライアントとしては、Eclipseを考えているが、サーバ上や、ローカルのプロジェクトをGITに投入する際には git のコマンド(CUI)を使うことを想定している。
サーバ上には、ユーザ git1)が存在し、リポジトリは ~git/repos の下に作られるモノとする。リポジトリへのアクセスは git-daemon経由にするか、sshなどにするのかは、ユーザの判断に任せたい。どちらでもいいが、sshの場合には、リポジトリのアクセス権限を適切に設定する必要がある。具体的には、利用者はグループ git に所属させて、リポジトリは g+w で作成する2)とするなどである。
GITの概念上は、リポジトリは、プロジェクトにつき一つとなり、同じサーバ上にあってもプロジェクトが違えば、別々のリポジトリとして扱う。
このあたりは、リポジトリはサーバ単位で管理される CVSや SVNとは少々異なっている。
ここでは、プロジェクト foo を管理するリポジトリを作成するものとして話を進める。 まずは、リポジトリとなるディレクトリを ~git/repos/foo.git として作成する。リポジトリは慣例として、<プロジェクト名>.git とするようである。別にこうしなかったら動かないというわけではないと思うが、慣例には従った方が、トラブルがあったときなど、ググったりしやすいだろうから特に逆らわないこととする。
$ mkdir ~git/repos/foo.git $ cd ~git/repos/foo.git $ git init --bare
ディレクトリを作ったら、そこをリポジトリとして有効化する。具体的には、作ったディレクトリの下で、git init –bareとするだけだ。この最後の –bare は中身はないが場所として確保するためのオプションである。
あとは、必要に応じてディレクトリやファイルのパーミッションを直す。
$ chgrp -R git ~git/repos/foo.git $ chmod -R g+w ~git/repos/foo.git
などであろう。git-daemon経由の場合はdaemonがgitで走るようにしてあれば、このあたりは気にしなくてもいいはずである。
既に、ローカルには、チェックインを待つ何らかのプロジェクトが存在しているモノとする。場所は C:\Users\bar\workspace\foo であると仮定する。別に Windows である必要はない。Linux でも FreeBSDでも MacOS Xでも大丈夫だ。とにかくプロジェクトのあるディレクトリへ移動し、そこで GIT 化の作業をする。
C:\Users\bar> cd workspace\foo C:\Users\bar\workspace\foo> git init Initialized empty Git repository in C:/Users/bar/workspace/foo/.git/ C:\Users\bar\workspace\foo> git add <追加するファイルやディレクトリを列記> C:\Users\bar\workspace\foo> git commit [master (root-commit) XXXXXXX] import project into GIT world! 34 files changed, 4192 intersections(+), 0 deletions(-) create mode 100755 doc/readme.txt ... C:\Users\bar\workspace\foo>
これだけでGIT化は完了だ。git init3)して、git addで追加するファイルを指定して4)、git commit して完了だ。git commit はエディタが開いてコメントを入力するように要求されるだろう。要求されたら、適当にコメントしておけばいい。the first branchとか何とか、まあ最初は適当でいいと思う。
変更をコミットするときはもちろん修正点をきちんとコメントしておくべきだが。
さて、この状態でも、実は、GITによるバージョン管理を、この作業ディレクトリ内で行うことができる。ローカルで完結する場合はGITは作業ディレクトリの他にリポジトリを別途持ったりはしないのだ。
が、ここでは、これをリモートへ送り、そこのリポジトリ上で管理することを目的としているので、リモートリポジトリへの送信作業が発生する。
引き続きローカル側の作業ディレクトリ内での作業となる。サーバは git という名前であると仮定する。
行うのは、リポジトリのロケーションを登録し、そこへプッシュする、という二つの作業だ。
C:\Users\bar\workspace\foo> git remote add origin git://git/foo.git C:\Users\bar\workspace\foo> git push origin master Counting objects: 53, done. Delta compression using up to 4 threads. Compressing objects: 100% (48/48), done. Writing objects: 100% (53/53), 53.76 KiB, done. Total 53 (delta 23), resued 0 (delta 0) To git://git/foo.git * [new branch] master -> master C:\Users\bar\workspace\foo>
これで完了である。5)
もし、万が一、作業をしくじったりして、誤ったロケーションをリモートとして登録してしまったら、ローカルの作業ディレクトリ内にある .git/config というファイルを開き、[remote “origin”]というセクションをまるっと削除して add しなおすか、あるいはそこを改変してしまえばいい。
ファイルの内容は
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
ignorecase = true
[remote "origin"]
url = git://git/foo.git
fetch = +refs/heads/*:refs/remotes/origin/*
こんな感じである。
Cygwinでコードを実行していると、頻繁にヒープ不足に陥る。 これは、デフォルトで384MBまでしかヒープを使わないようになっているため。
新しい Cygwin は、バイナリごとに、ヒープサイズを変えることが出来るようになった。 ヒープサイズは peflags コマンドで取得・設定出来る。
ヒープに関するオプションはいくつかあるが、Cygwinで意味を持つのは -z (–cygwin-heap)のみである。
araki@mango[65]% peflags -z f.exe f.exe: initial Cygwin heap size: 0 (0x0) MB araki@mango[66]% peflags -z2048 f.exe f.exe: initial Cygwin heap size: 2048 (0x800) MB araki@mango[67]% peflags -z f.exe f.exe: initial Cygwin heap size: 2048 (0x800) MB araki@mango[68]%