プログラムの開発環境についてあれこれまとめておく備忘録

GITを使ってプロジェクト管理をするためのメモ。レポジトリはローカルではなくサーバ上に置いて管理することを想定している。

クライアントとしては、Eclipseを考えているが、サーバ上や、ローカルのプロジェクトをGITに投入する際には git のコマンド(CUI)を使うことを想定している。

サーバ上には、ユーザ git¹⁾が存在し、リポジトリは ~git/repos の下に作られるモノとする。リポジトリへのアクセスは git-daemon経由にするか、sshなどにするのかは、ユーザの判断に任せたい。どちらでもいいが、sshの場合には、リポジトリのアクセス権限を適切に設定する必要がある。具体的には、利用者はグループ git に所属させて、リポジトリは g+w で作成する²⁾とするなどである。

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 init³⁾して、git addで追加するファイルを指定して⁴⁾、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>

これで完了である。⁵⁾

もし、万が一、作業をしくじったりして、誤ったロケーションをリモートとして登録してしまったら、ローカルの作業ディレクトリ内にある .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]%

• zのあとに数字がなければ、値を取得する。デフォルトでは特に割り当てはないが、数字を指定すればそのサイズ(MB)が割り当てられる。-z のあとに空白はあけてはいけない。–cygwin-heapの場合には–cygwin-heap=2048のように指定する。

これを拡大するには、レジストリを変更して、Cygwinを再起動する必要がある。 ⁶⁾

レジストリは、HKCUの中のCygwinの関連項目にキーを追加、あるいはその値を変更するこことになる。 Windows Vista以降の場合であっても、HKCUなので自分の権限だけで操作できるので、企業ユーザでも管理者に依頼せずに自分でできるところはポイントが高い。⁷⁾

変更するレジストリは、

HKLM/Software/Cygwin/heap_chunk_in_mb

REG_DWORD か何かにして、10進数で、MB単位でヒープサイズを指定する。1024 とすれば1GBのヒープになる。

startへ戻る