git clone --branch で一気にブランチに移行2015年08月01日 11時34分32秒

git clone はレポジトリを複写する方法。分散型の git に取っては、取得するチェックアウトにも相当する。git clone には -b または --branch のオプションもあり、任意のブランチに直接移行することも出来る。

試してみたら、存在しないブランチを指定すると、何も複製されない。

git clone; git branch で取得とブランチへの移行をすると、ブランチが無いときにそのまま master になってしまう。ブランチが存在しない場合に、異常終了したい場合には clone で一気にブランチを指定すると、失敗してもに何も残らない。

Eclipse ADT で git を使う2013年12月01日 13時13分15秒

Eclipse ADT をインストールしたら既に git が使えるようになっていた。特に不慣れな環境でコードを変更するのに履歴管理は手放せない。git 自体はあまり好みではないが、わざわざ他を入れる程好むものもない。そこで、そのまま git を使用。インストール済みというのは本当に大きな差だ。

プロジェクト単位で行うのが単純な操作だ。

  1. プロジェクトを右クリックし、「Team」の中の「Share Project...」を選択。「Configure Git Repository」のウインドウが出てくる。
  2. 「Use or create repository in parent folder of project」を選択すると「Create Repository」が有効化され、クリックできる。
  3. これをクリックすると、git initが実行されて、「Finished」ボタンで終わらせる。
この方法だと、各々別のレポジトリになってしまうので、コードをライブラリなどで分離して、あれこれ頻繁に移動させると履歴が正しく追えなくなる。workspace 自体をレポジトリにする等で対応できる。

git add/commit/diff の動作2009年02月12日 17時58分37秒

以前にも git のインターフェースは他と同じ名前なのに動作が違うのは指摘した。似て非なる物の為、更にとっつきが悪い。git heckout もその一例だ。

git の add と commit の動作も他とは全く異なる。

非 git での add は、新しいディレクトリやファイルを追加するのに使われる。非 git での commit は引数に指定されたファイルをコミットするのに使われる。そして、diff はこの手元での変更を表示する。様々なオプションを指定すればタグなどとの比較も可能だが、ここで言いたいのは何もオプションを与えないときの動作のことだ。

git では、全てのコミットを事前に add する必要がある。git の add はディレクトリやファイルを追加するのではなく、変更をコミットする為の予約をするコマンドだ。そして、commit であらかじめ登録しておいた変更のうち、引数で渡されたファイルのみの差分をコミットする。commit には add が必須だ。そして、diff コマンドは、手元の変更で add されていない物のみを表示する。そのため、git add が終わった変更は、git diff にて表示されない。

hg で例をあげる。


% hg init
% echo A > file.txt
% hg add file.txt 
% hg commit -m 'Create file.txt.'
% echo B >> file.txt 
% hg diff
diff -r d3e5d96de93f file.txt
--- a/file.txt  Fri Feb 11 23:10:27 2009 -0500
+++ b/file.txt  Fri Feb 11 23:11:42 2009 -0500
@@ -1,1 +1,2 @@
 A
+B
% hg add file.txt 
file.txt already tracked!

二度目の file.txt の add は出来ないと言われる。

今度は git で試す。


% git init
Initialized empty Git repository in /tmp/git/.git/
% echo A > file.txt
% git add file.txt 
% git commit -m 'Create file.txt'
Created initial commit 58d0fcc: Create file.txt
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 file.txt
% echo >> B file.txt 
% git diff
diff --git a/file.txt b/file.txt
index f70f10e..35d242b 100644
--- a/file.txt
+++ b/file.txt
@@ -1 +1,2 @@
 A
+B

ここでは、diff が表示される。

% git commit -m 'Added B.'
# On branch master
# Changed but not updated:
#   (use "git add ..." to update what will be committed)
#
#       modified:   file.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

しかし、これはコミットできない。

% git add file.txt 
% git diff
% git commit -m 'Added B.'
Created commit 9f0a6ac: Added B.
 1 files changed, 1 insertions(+), 0 deletions(-)

add を使い登録することで、コミットが受け付けられた。そして、diff では変更を見られなくなっている。

バージョン管理 short tours2009年02月09日 12時34分12秒

一人で各種の履歴管理システム/プログラムを使い初める為の簡単な例。以下の作業を各々のプログラムにて実行する。
  1. work ディレクトリに a.txt と 1.txt を作成。
    
    % cd /tmp
    % mkdir work
    % cd work
    % echo "A B C" > a.txt
    % echo "1 2 3" > 1.txt
    
    
  2. import/checkout の作業を行なう。
  3. 1.txt を編集し、status と diff を見る。
    
    % echo "10 11 12" >> 1.txt
    
    
  4. 1.txt の変更をコミット。
  5. a.txt を A.txt に変更し、コミット。
  6. ログを見る。

プログラムのデザインと思想によって、始め方は千差万別だ。各々、特徴的な初期化のやり方をする。しかし、そう何回も繰り返す作業ではない。

一度、使い始めると大切な作業は三つ。

  1. 変更を確認する。
  2. 変更を記録する。
  3. 履歴を見る。
これらの作業が中心となる。コマンド的には、checkout(co)、diff、commit(ci)、update、log、status 等が並ぶ。これらのコマンドがある程度使えると、不自由はしない。

そして集団で使うとなると、更に二つの作業が必要になる。

  1. 他人の変更を引っ張ってくる。
  2. 衝突を解消する。
個人的に使っていても、二つ以上の作業場を用意して、疑似体験することは出来る。大きいプロジェクトや既に安定運用している成果物だと変更箇所も分散される事が多い。また、正しく管理されている仕事であれば衝突を避けるように計画するべきなので、衝突の解消を行なう事自体は少ない。こちらについては、今回は扱っていない。

集中管理型や分散型による違い。各思想の違いもコマンドに現れていて面白い。RCS は単体ファイルのみ。CVS 以降はディレクトリ構成も含めて、ファイルを集合として扱える。新しいい物も RCS/CVS に準拠したコマンド名も多い。使い手としては、コマンドと動作がある程度似ていた方が、試しやすく抵抗感も少ない。欠点としては、RCS/CVS の動作に寄せる形になるので、設計に RCS/CVS の影響が多かれ少なかれ出てくる事だ。

旅程cvsMercurial/hggitSubversion/svnrcssvk

git short tour2009年02月08日 14時14分11秒


% cd /tmp
% mkdir gitwork
% cd gitwork
% ehco "A B C" > a.txt
% echo "1 2 3" > 1.txt
% git init
Initialized empty Git repository in /tmp/gitwork/.git/
% git add
Nothing specified, nothing added.
Maybe you wanted to say 'git add .'?
% git add .
% git ci -m '/tmp/gitwork is under git.'
git: 'ci' is not a git-command. See 'git --help'.
% git commit -m '/tmp/gitwork is under git.'
Created initial commit 997d2a4: /tmp/gitwork is under git.
 2 files changed, 2 insertions(+), 0 deletions(-)
 create mode 100644 1.txt
 create mode 100644 a.txt
% git stat a.txt
git: 'stat' is not a git-command. See 'git --help'.
% git status a.txt
# On branch master
nothing to commit (working directory clean)
% echo "10 11 12" >> 1.txt
% git diff 1.txt
diff --git a/1.txt b/1.txt
index b85905e..bb4abbd 100644
--- a/1.txt
+++ b/1.txt
@@ -1 +1,2 @@
 1 2 3
+10 11 12
% git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#
#       modified:   1.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
% git add 1.txt
% git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       modified:   1.txt
#
% git commit -m 'Added 2 digits numbers.'
Created commit 46147f6: Added 2 digits numbers.
 1 files changed, 1 insertions(+), 0 deletions(-)
% git rename a.txt A.txt
git: 'rename' is not a git-command. See 'git --help'.
% git mv a.txt A.txt
% git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       renamed:    a.txt -> A.txt
#
% git commit -m 'Uppercase.'
Created commit 3fbdfcb: Uppercase.
 1 files changed, 0 insertions(+), 0 deletions(-)
 rename a.txt => A.txt (100%)
% ls -a
.       ..      .git    1.txt   A.txt
% git log
commit 3fbdfcb2eab1accbb9d697c877b5b480e4fc964d
Author: <uyota@localhost>
Date:   Sun Feb 8 01:52:49 2009 -0500

    Uppercase.

commit 46147f6198b3f32cb04fefabc5ae98c30ec5e9b7
Author: <uyota@localhost>
Date:   Sun Feb 8 01:51:57 2009 -0500

    Added 2 digits numbers.

commit 997d2a49b3e2d891a85e22daacf594e6b4750c05
Author: <uyota@localhost>
Date:   Sun Feb 8 01:46:44 2009 -0500

    /tmp/gitwork is under git.

旅程cvsMercurial/hggitSubversion/svnrcssvk

git config2008年11月20日 16時21分06秒

git を使い始める前に、git config で初期設定を行う。

% git config --global user.email "you@example.com"
% git config --global user.name "Your Name"

これで、.gitconfig ファイルが以下のように作成される。


% cat ~/.gitconfig 
[user]
        email = you@example.com
        name = Your Name

この後に、最初の git init でレポジトリを作成する。

cvs diff -u<n> = git diff -U<n>2008年10月01日 10時03分13秒

diff を行なう機能を持つソフトウェアは -u で unified diff を行なう物が多い。unified diff はいわゆる + と - を使って差分を表し、一番読みやすい形の書式だ。cvs なども、cvs diff の時に -u を付けると unified diff になり、更に前後の行数も指定できる。

これが git では -U の大文字でのオプションとなる。以下はマニュアルからの抜粋だ。


-U<n>
Shorthand for "--unified=<n>". 

--unified=<n>
Generate diffs with <n> lines of context instead of the usual three. Implies "-p".

急いで行数を変える必要があったのだが、大文字なのを知らずに今回は結局間に合わなかった。

git links2008年08月22日 04時12分34秒

最近は git も使っている。git は他のリビジョンコントロールシステムとコマンド名や、同一のコマンド名であっても動作が異なる為、慣れるのに時間が掛かる。その中で、便利だと思ったサイトを取り上げる。

Git Cheat Sheet には png 形式の一覧が置いてある。最初に一人で使い始めるのに必要な基本的なコマンドは、大体ここで判るので随分と重宝した。

Git Magic は merge やタグ、ブランチを使い始めるのに役に経った。git で始めて使うコマンドはいつも不安が付きまとう。特に merge で失敗したのに気が付くのが遅れると、いろいろと厄介になるので不安だった。merge も成功した。

git 流ファイル復活2008年08月10日 10時32分14秒

cvs や Mercurial などでは、間違って削除したファイルは、cvs uphg up で復活した。しかし、git では update コマンドでは削除されたファイルは復活しない。revert コマンドを使うと、他のファイルも戻されたり、更にはコミットまでされてしまう。

git でのファイルの復活方法を探すこと数日。やっと見付けられた。


% git checkout <ブランチ名> ファイル名

で復活出来ることが判明した。

cvs などでは、checkout はそれこそ、最初に一度、作業コピーを取り出すのに使うに過ぎない。それ以降の変更やファイルの際取得などには update を使う。むしろ、checkout を使おうとすると、御小言を聞くことになる。

git はあまりに異色なので、使っていてもまだ全ての状況で正しく意図したファイルや変更を取り出せる自信が無い。慣れるのに時間が更にかかりそうだ。

インターフェースを合わせる重要性2008年07月30日 20時45分33秒

ソースコードマネージメント、Source Code Management を幾つか使っているが、git は使いづらい。GNU arch、tla も使った事があるが使いづらかった。使い込んだのは、RCS、CVS を筆頭に Subversion、Mercurial がある。使いづらいとは言っていても、git のみで管理しているコードもあるので、それなりに使い込んでいる。svk や商用の PVCS と言うものも使ったことはあるが、使い込んでるとは言えない。

VOS で動く SCM は CVS のみだし、それなりに古い環境で動かそうとすると、各ライブラリのバージョンや、コンパイル出来ないなどの都合で、SCM を選べない時がある。また、御粗末な理由で、特定の SCM を諦めなければいけないことがある。

何はともあれ、RCS に始まって、CVS と Subversion や Mercurial はコマンド名の互換が高いので使っていても、あまり困らない。SCM を使うときの基本的なコマンドは、diff、checkout、update、commit だ。これらのコマンドがほぼ同じ動作をする。新しいファイルを追加する時のコマンドの順番や、変更のコマンドもほぼ一緒だ。新規は cvs add file.txt; cvs ci file.txt とやり、更新は cvs ci file.txt で済む。Mercurial の clone など、各デザインによる固有のコマンドもあるが、そんなに頻繁に使うわけでは無いので、日常に困ることは無い。

ところが、git や arch/tla はコマンド名が違ったり、動作が違ったりする。例えば、git では、新しいファイルを追加するときでも、既に存在するファイルを更新する時も、git-add file.txt; git-commit file.txt とする。どうも、毎回 commit 時に登録する必要があるみたいだ。コマンド名も似ているものが多いが動作が、上であげたものと微妙に違っていたりすることも多く、やりたいことが出来ずに右往左往する事も多い。

git や arch/tla も機能面では優れたところも持つが、日常の作業に躓いていたら、優れた機能を使う局面まで、使い続けられないかもしれない。特に覚えなければいけないコマンドラインを中心としたソフトウェアは、他のと同じ動作をするようにした方が、今回の件で使いやすい、取り付きやすいと強く感じた。

上の一群の間では、乗用車を乗り換えている程度の操縦性の違いだが、下の物はトラックやバイクなどに乗り換えたのかと思うくらい操縦性が違う。