Git

〜 分散型バージョン管理システム 〜

Git

〜 Distributed version control system 〜

概要 Abstract
Git は分散型のバージョン管理システムである. 分散型とは,どのクライアントでもサーバになれることを意味し,SVNなどの集中型のバージョン管理システムとくらべてプロジェクトのポータビリティが高い.
Git is a distributed version control system. The distributed type means that every client can become a server, which improves the portability of the project compared to centralized revision control systems, such as SVN.
目次 Table of contents

Reference

参考記事:

用語 Vocabulary

  • リビジョン: バージョンは機能の追加など,比較的大きな変更に対して使う.マイナーチェンジに対しては,リビジョンと言うのが普通.ただし,日本語では混在して使われることも...
  • リポジトリ: ファイル管理用のディレクトリ.Git の場合,それぞれのリポジトリに,過去のすべてのバージョンのファイルが保管されている.
    • ベアリポジトリ: サーバ用のリポジトリ.リポジトリのみがディレクトリに存在し,生のソースは置かれない.
  • ワークツリー: 作業中のディレクトリ.
  • インデックス: Git によって管理されているファイル名のリスト.
  • コミット: リポジトリにファイルを書き込むこと.
  • リビジョン管理番号: 各リビジョンに対して,一意の管理番号が割り当てられる.Gitの場合 9c82553891...98d8a0 のような番号が使われる(多くの場合,最初の数桁の指定だけで特定できる).
  • タグ: リビジョン管理番号とは別に,重要なバージョンにつける識別コード.人間にとってわかりやすい名前をつける.
  • チェックアウト: リポジトリからファイルを取り出すこと.ブランチを切り替えたり,過去のリビジョンのファイルを取り出したりする.
  • ブランチ: リポジトリを分岐させたもの.
  • masterブランチ: デフォルトで作成されるブランチ.
  • リモートリポジトリ: 別の場所(別のPC・サーバ・ディレクトリ)に置いてあるリポジトリ.単にリモートと呼ぶことも.
  • ローカルリポジトリ: リモートに対して,今作業中のリポジトリをローカルリポジトリ(あるいは単にローカル)と呼ぶ.
  • フェッチ: リモートリポジトリからファイルをダウンロードすること.

Refer to WikiPedia.en:Revision_control for the detail.

研究開発における利点

  • バージョン管理ができる.過去のバージョンをチェックアウトして,実験の検証が行える.
  • ポータビリティ(可搬性)が高い.
    • 学内限定のサーバにリポジトリを置いていても,例えばノートPCにリポジトリを複製して学外に持っていく,といったことが容易にできる.
  • プロジェクトの共有がしやすくなる.
    • 例えばAさんが開発しているプロジェクトをBさんが利用する場合,初めてプログラムを譲渡する場合はZIPでアーカイブして渡してもトラブルがない.しかし,Aさんがバージョンアップしたファイルをコピーする場合,Gitを使うと更新されたファイルのみ漏れ無くコピーされるが,個別にファイルを手渡しすると漏れる可能性がある.
  • 環境の移植・複数の環境での作業がしやすくなる.
    • デスクトップで開発したプロジェクトを,ノートPCにコピーして実験するような場合,Gitを使っていると便利.
    • ノートPCでプログラムをコピーした場合,もとのデスクトップに更新することも容易.

ガイドライン

Git を研究で使う場合,経験上,以下のガイドラインに従うとスムーズに作業が行える.

リポジトリの構成

  • サーバ: 各クライアントから push できるベアリポジトリを用意しておくとよい.
  • クライアント: 各PC.

ブランチの構成

  • ビギナー向け: 基本的には master ブランチのみで開発する.
    • 自分で開発を始めたプロジェクトで,自分のみが使う場合は,master のみで利用するのがわかりやすい.
    • Git 初心者がブランチをたくさん作ると,混乱する可能性がある.
  • 自分が始めたプロジェクトを他の人に使ってもらう場合,master に加えて dev リポジトリを作る.
    • 開発は dev リポジトリで行い,安定版のみを master リポジトリにマージする.
    • 利用者は,基本的には master ブランチを使うことを想定.
  • 他の人が始めたプロジェクトを引き継いで使う場合:
    • 現状では経験不足のため,ガイドラインはない.別ブランチを作るのがいいか?

プロトコル

  • 経験上,SSH がセットアップしやすく,使いやすく,安全.
  • HTTP, Git プロトコルは,認証なしでダウンロードできてしまわないように注意してセットアップする必要がある.

その他のガイドライン

  • 他の環境でも動作させることを念頭に置き,汎用的な構成にする
    • 例えば,環境依存の設定ファイルなど (e.g. config.h) をリポジトリに追加すると,環境ごとに内容が異なるため,更新のたびに書きなおす必要が出てきて面倒.
    • そこで,ファイル名.sample などのテンプレートをリポジトリに加えておき (e.g. config.h.sample),環境依存のファイルは,コピー&編集して使うようにする.かつ,リポジトリには加えない.
    • CMakeを利用すると,汎用性が高いプロジェクトが作れる.
  • 自分が管理していないプロジェクトの変更は,最低限に留める.
    • リポジトリを更新する際に,マージに手間が掛かる.
    • 必要だと思われる変更は,管理者(開発者)に連絡する.
  • ルートディレクトリに README ファイルを作成し,ビルド方法,使い方を書く.ウィキや他の場所にドキュメントがある場合は,場所を指定する.
  • ビルドは CMake で行えることが望ましい.
  • 自分が管理しているプロジェクト以外ではコミットしない.
  • ビギナーはpull を使わない#REMOTE_PULLのNoteを参照).
  • マージ (merge) は注意深く行う.少なくとも競合の解決を知っておく.
  • ブランチ間のマージは non fast forward (--no-ff) を使う
  • コミットログは英語推奨(どうしても日本語を使う場合はUTF-8推奨).誰が見てもわかるログを書く
  • タグは注釈付き (annotated) のタグを用いる.
  • rebase は使わない.

インストール

  • git, git-core: 最低限必要なパッケージ.
  • tig: CUI (ncurses) ベースのリポジトリブラウザ.特にリモートで作業する場合に必須.
  • qgit: QGitはGUI (Qt) ベースのリポジトリブラウザ.

設定

ホームディレクトリに .gitconfig という設定ファイルを作る(オプション). 以下は設定ファイルの例.[alias] はコマンドのエイリアス(ショートカット).

[user]
	name = USER-NAME
	email = USER@EXAMPLE.COM
[color]
	ui = auto
[alias]
	s = show
	st = status
[core]
	editor = EDITOR-COMMAND
  • USER-NAME: ユーザ名.
  • USER@EXAMPLE.COM: メールアドレス.
  • EDITOR-COMMAND: エディタのコマンド.nano や kwrite など,好きなエディタに設定する(GUIエディタも可).

直接設定ファイルを書かずに,git コマンドから設定する方法もある.

基本操作

Gitでは,以下が基本的な作業の流れ:

  1. リポジトリの新規作成 (git init).
  2. ワークツリーにファイルを追加(非Gitの通常の操作).
  3. 追加したファイルをインデックスに登録(git add ...; ファイルをGitの管理対象にする).
  4. ファイルの変更(非Gitの通常の操作).
  5. コミット(git commit ...; ワークツリーの更新を,リポジトリに保存) → リポジトリに保存したリビジョンに,いつでも復帰できるようになる.

以降,2,3,4,5を繰り返す.

Note
ファイルをインデックスに登録するタイミングは,いつでも構わない.登録しなかったら,Gitで管理されないだけ(ワークツリーには残ったまま). 例えば,環境依存の設定ファイル (e.g. config.dat) は,config.dat をGitで管理せずに,サンプルの config.dat.sample をGitに登録しておく.すると,各環境の config.dat は Git の管理から外され,サンプルだけリポジトリ間で共有できる.

リポジトリの新規作成

Git で管理するディレクトリ(既にファイルが置いてあってもよい)で,以下を実行:

git init

インデックスにファイルを追加

ファイルをGitの管理対象にする(i.e. インデックスにファイルを追加する)には:

git add FILE-NAME(s)

.gitignoreで無視しているファイルを追加するには,--force オプションを付ける.

コミット

コミットとは,ワークツリーに対して加えた変更を,リポジトリに保存する(書き加える)こと.よって,自分が管理しているプロジェクトにしかコミットするべきでない.変更を加えてしまった場合は,リセットを参照.

コミットの方法:

git commit -a -m "LOG-MESSAGE"

LOG-MESSAGE は,保存したリビジョンに対して付けるログメッセージ.

  • そのコミットで何が変更されたかを簡潔にまとめて書く
  • ほかの人が見てもわかりやすいように書く

すでにあるプロジェクトにコミットする場合は,そのプロジェクトのスタイルにしたがってコミットログを残す.スタイルが明文化されていない場合は,そのプロジェクトのコミットログを読んで (git log) それに合わせる.

ログメッセージを入力せずにコミットすると,エディタが起動される.

git commit -a

エディタでログメッセージを編集(改行を含めてもよい)し,保存し,終了すると,コミットされる.

リポジトリの複製(クローン; clone)

リポジトリを複製する.同じPCにリポジトリを複製してもいいし(master ブランチと dev ブランチを別々のディレクトリで開発する場合など),ほかのサーバにあるリポジトリから複製してもよい.

git clone REMOTE-ADDRESS
  • REMOTE-ADDRESS : 複製元(オリジナル)のアドレスを書く.

詳細はリモートリポジトリを参照.

REMOTE-ADDRESS の指定は,以下を参照.

リモートリポジトリのアドレス指定

  • /home/hoge/git/test : 同じPCの別のディレクトリ(絶対アドレス)にあるリポジトリ.
  • ../test : 同じPCの別のディレクトリ(相対アドレス)にあるリポジトリ.
  • ssh://USER@EXAMPLE.COM/home/USER/Program/test : 別サーバ (EXAMPLE.COM) にあるリポジトリ.サーバにも Git がインストールされている必要がある.SSHで接続.
  • USER@EXAMPLE.COM:/home/USER/Program/test : 別サーバ (EXAMPLE.COM) にあるリポジトリ.サーバにも Git がインストールされている必要がある.SSHで接続.
  • USER@EXAMPLE.COM:Program/test : 同上(/home/USER は省略できる).

ファイル名の変更

以下でファイル名を変更.

git mv FROM-FILE-NAME TO-FILE-NAME

この変更は,コミットするまで,リポジトリには反映されない.

ファイルを削除

インデックスからファイルを除外する(ファイルをGitの管理から外すだけ.ワークツリーのファイルは削除されない):

git rm --cached FILE-NAME

ワークツリーからもインデックスからもファイルを削除する:

git rm FILE-NAME

変更の取り消し

基本的に,推奨しない使い方(ログが残らないし,場合によっては時間を無駄にするため).間違ってワークツリーを変更してしまった場合に復帰する場合など.

変更を取り消し,前回コミットした状態まで戻す:

git reset --hard HEAD

変更を取り消し,特定のリビジョンまで戻す:

git reset --hard ID

間違ってワークツリーを変更してしまった場合の対処法

ワークツリーを変更してしまうと,マージの際に「先にコミットせよ」などのメッセージが表示されて,マージできなくなることがある.このような場合には,もちろんリセットしてもいいが,自分が加えた変更を別の場所にバックアップしてからにしたい場合がある.

まず,変更したファイルを調査する.

git status

変更したファイルの一覧が表示される.変更したファイルを別の(Gitで管理していない)ディレクトリに移す.次に,

git reset --hard HEAD

で,前回のコミット状態まで復帰させる.もしくは,変更したファイルが少ない場合は,個別にリポジトリからチェックアウトしてもよい:

git checkout FILE-NAME
  • FILE-NAME : 変更した(チェックアウトしたい)ファイル名.

リポジトリの設定

.git/config

リモートリポジトリなどの設定が書かれている.直接編集してもよい(が,間違えて書いた場合の挙動は不明).

.git/hooks/

各種操作(コミットなど)の前後に実行される,ユーザが設定可能なスクリプトが置かれている.デフォルトでは SCRIPT.sample というファイル名で置かれているので, SCRIPT という名前でコピーして編集し,用いる.

.gitignore

git status でステータスを表示したときに,Gitで管理していないファイル (Untracked files) にバックアップファイルなどが表示されるのを防ぐ設定ファイル.

初期状態では作成されていない. リポジトリのルートディレクトリ(.git ディレクトリが置かれているところ)に .gitignore を作成し,以下のように無視するファイルのパターンを書く.

*~
*.d
*.o
*.lo
*.a
*.so
*.so.*
*.out
core*

*.old
old-*
tmp*
backup*
trash

hoge/config.dat など,ファイル名を直接指定してもよい.

GitHub maintains an official list of recommended .gitignore files for many popular operating systems, environments, and languages in following public repository: https://github.com/github/gitignore

各種調査

ログ一覧 (log)

コミットログの一覧を見る:

git log

comit ... の後ろに書かれているのが,リビジョン管理番号.

コミットの履歴のツリーも表示する:

git log --graph

表示 (show)

最新のコミットの情報(コミットログと変更点)を見る:

git show

特定のリビジョン管理番号 (ID) の情報を見る:

git show ID

ステータス (status)

変更があったファイル,追加・リネーム・削除されたファイル,Gitで管理していないファイル (Untracked files) の一覧を見る:

git status

Gitで管理していないファイルは,コミットしてもリポジトリに含まれない.そこで,git addを使ってインデックスに追加する.

変更点の調査 (diff)

変更された箇所を見る:

git diff

特定のリビジョン間で,変更を調査する:

git diff ID1 ID2
  • ID1, ID2 : リビジョン管理番号(参考: #REVISION_ID
  • ID2 を指定しないと,現在のワークツリーと比較される.

リビジョン管理番号

リビジョン管理番号は, e9fd...f075 といった番号を指定してもよい(大概は最初の数桁(4~6程度)で指定できる)し,HEAD (最新のコミット),HEAD^ (1つ前のコミット),HEAD^^ (2つ前のコミット) などでも指定できる.タグ名を使うこともできる.

リモートリポジトリ

リポジトリを別の場所(ほかのサーバやディレクトリ)に置いたものをリモートリポジトリと呼ぶ.プロジェクトを共有したり,共同開発したりする場合には必須の知識.

リモートリポジトリの一覧 (remote)

一覧:

git remote

アドレスつき:

git remote -v

リモートリポジトリの登録 (remote add)

git remote add REMOTE-NAME REMOTE-ADDRESS
  • REMOTE-NAME : リモートリポジトリの名称.
  • REMOTE-ADDRESS : 複製元(オリジナル)のアドレスを書く(アドレス指定は#REMOTE_ADDRESS参照).
origin
リポジトリを clone で複製した場合,複製元(オリジナル)は origin という名称で,リモートリポジトリとして登録されている

ダウンロード (fetch)

git fetch REMOTE-NAME
  • REMOTE-NAME : リモートリポジトリの名称.origin など.

結果例:

* [new branch]      master     -> t11/master
Note
ダウンロードは,リモートからリポジトリの変更を取得するのみで,ワークツリーは更新されない.ワークツリーも更新するには, merge を使う.

マージ (merge)

fetch で取得した更新を,ローカルに反映させるには,マージを実行する. フェッチの結果:

* [new branch]      master     -> REMOTE-NAME/master

に対して,

git merge REMOTE-NAME/master

を実行すると,変更がマージされ,ワークツリーに反映される.

Note
ローカルの変更がコミットされていない場合,「先にコミットせよ」と指示されることがある.Gitのメッセージに従うこと.
注意
ブランチ名を確認すること(上の例では master).異なるブランチをマージしてしまうと,プロジェクトに大きな悪影響を及ぼす. ワークツリーのブランチを変更してマージする方法および新しいブランチにマージする方法は,#BRANCH_MERGEを参照. 失敗を取り消す方法は #RESET を参照.
注意
メッセージをよく確認すること.競合 (CONFLICT) が起きている場合,Git によってソースが変更されている(マークされている)ことがある.

競合の解決

マージの際には,競合 (CONFLICT) が起きることがある.ここでは,競合した場合の対処方法について述べるが,意図しないマージを実行してしまって,もとに戻したい場合は,#RESETを使う.

リモートの変更と,ローカルの変更が競合 (CONFLICT) していると(例:別々に書き換えてしまった),マージの際に以下のようなメッセージが表示される:

$ git merge t14/master
Auto-merging src1.cpp
CONFLICT (content): Merge conflict in src1.cpp
Automatic merge failed; fix conflicts and then commit the result.

リモート t14(の master ブランチ)をローカルにマージしようとしたが,src1.cpp で競合が起きていることがわかる.競合を解決して,結果をコミットせよ,と指示されている.

このとき,競合が起きているファイル src1.cpp を見てみると,以下のように競合部分がマーキングされていることがわかる:

...
<<<<<<< HEAD
int E;
=======
int D;
>>>>>>> t14/master
int main()
{
  ...

ローカル側(<<<<<<< HEAD と ======= の間)と,リモート(======= と >>>>>>> t14/master の間)で異なっている部分が示されている.この部分を修正して,例えば

...
int E;
int main()
{
  ...

のように変更する.

別の競合の例としては,一方でリポジトリから消したファイルを,他方では変更して使っているような場合がある.このような場合は,以下のようなメッセージが表示される:

$ git merge t14/master
CONFLICT (delete/modify): src1.cpp deleted in t14/master and modified in HEAD. Version HEAD of src1.cpp left in tree.
Automatic merge failed; fix conflicts and then commit the result.

この場合,ファイル src1.cpp をリモート(t14/master)からは消去し,ローカル(HEAD)では変更しているため競合し,Gitでは同処理すべきか判断できない. この競合を修正するには,src1.cpp を再度リポジトリに加える (git add src1.cpp を明示的に実行してもいいし,何もしなくてもいい) か,リポジトリから消す (git rm src1.cpp) ことで解決できる.

マージは手作業で行なってもよいが,mergetool を利用することもできる.

git mergetool

ファイルの削除などの競合については,ローカルのものを残すか・リモートの通りに消すかなどが質問され,内容の競合については,kdiff3 などが起動される.

注意
マージ作業は,注意深く行うこと.もとのコミットやマージ対象のコミットとの git diff を調べながら,意図どおりにマージされたかチェックすること.

すべての競合を解決した後,コミットする.

commit -a

ダウンロード&マージ (pull)

ビギナーは使わないことを推奨.

リモート REMOTE-NAME のブランチ BRANCH-NAME をダウンロードし,ワークツリーにマージする.

git pull REMOTE-NAME BRANCH-NAME
Note: pull の危険性
今 master ブランチで作業しているとして,リモートリポジトリ r1 の dev を以下のように pull してしまったとする:
git pull r1 dev
すると,r1 の dev がフェッチ(ダウンロード)され,さらに,ローカルの master ブランチにマージされてしまう.これは,多くの場合,望ましい振る舞いではないはず.このため,pull は(特に初心者のうちは)使わない方が安全.万一このような間違いをしてしまったら,
git reset --hard ID
で強制的に戻せる(IDはリビジョン管理番号; cf. #REVISION_ID).

ベアリポジトリ

ローカルからリモートにアップロードできるようにしたい場合は,リモートをベアリポジトリにする.ベアリポジトリを作成するには,クローン時に --bare オプションを付けるだけ.

git clone --bare REMOTE-ADDRESS
  • REMOTE-ADDRESS : 複製元(オリジナル)のアドレスを書く(アドレス指定は#REMOTE_ADDRESS参照).

アップロード (push)

ベアリポジトリにアップロードする方法.

すべてのブランチをアップロード:

git push REMOTE-NAME
  • REMOTE-NAME : リモートリポジトリの名前.

特定のブランチのみをアップロード:

git push REMOTE-NAME BRANCH-NAME

タグ情報をアップロードする場合は,--tags オプションを付ける.

タグ

タグとは,リビジョン管理番号とは別に,重要なバージョンにつける識別コード.人間にとってわかりやすい名前をつける.

タグの一覧 (tag)

一覧:

git tag

タグを作成していないと,何も表示されない.

パターンで表示するタグを指定する:

git tag -l '1.0.*'

タグの作成

タグには2種類ある:

  • 軽量 (lightweight) のタグ: 単に,バージョン管理番号のエイリアス(別名).
  • 注釈付き (annotated) のタグ: タグの作成者の情報,タグの作成日,メッセージなどを含められる.

基本的に,注釈付きのタグを用いるようにしたほうが,わかりやすくてよい.

軽量のタグ

軽量のタグを作成するには:

git tag TAG-NAME
  • TAG-NAME : タグ名(スペースなどは含められない)

現在のリビジョンに対してタグが付けられる.過去のリビジョンに対して軽量のタグを付けるには:

git tag TAG-NAME ID
  • TAG-NAME : タグ名(スペースなどは含められない)
  • ID : リビジョン管理番号(参考: #REVISION_ID

注釈付きのタグ

注釈付きのタグを作成するには:

git tag -a TAG-NAME -m "TAG-MESSAGE"
  • TAG-NAME : タグ名(スペースなどは含められない)
  • "TAG-MESSAGE" : メッセージ

メッセージ指定 -m "TAG-MESSAGE" を省略すると,エディタが起動される:

git tag -a TAG-NAME

いずれも,現在のリビジョンに対してタグが付けられる.過去のリビジョンに対して注釈付きのタグを付けるには:

git tag -a TAG-NAME ID -m "TAG-MESSAGE"

またはエディタを起動:

git tag -a TAG-NAME ID
  • TAG-NAME : タグ名(スペースなどは含められない)
  • ID : リビジョン管理番号(参考: #REVISION_ID
  • "TAG-MESSAGE" : メッセージ

タグ情報の表示

git show TAG-NAME
  • TAG-NAME : タグ名

タグ情報のダウンロード

フェッチ (fetch) で,タグ情報もダウンロードされる.タグ用のオプションはいらない.

タグ情報のアップロード (push --tags)

一方,プッシュ (push) だけではタグ情報はアップロードされない. push に --tags オプションをつけて実行する必要がある.

git push --tags REMOTE-NAME
  • REMOTE-NAME : リモートリポジトリの名前.
Note
プッシュに --tags をつけてアップロードすると,タグ情報と,タグが付けられたコミットとそれ以前のコミットがアップロードされる.逆に,タグ以降のコミットはアップロードされないので,--tags オプションなしの git push を実行する必要がある.

ブランチ

ブランチを使うと,リポジトリを分岐させられる.

メリット:

  • プログラムを大幅に変更するときに,安定版は残したまま開発できる.
  • 複数の人で共同開発するときに,独立したブランチで作業できる.

デメリット:

  • 理解せずに使うと,望ましくないブランチ間のマージを行なってしまい,プロジェクトを混乱させる.

ガイドライン:

  • ビギナーやひとりで開発する場合は,masterブランチのみで作業する.
  • pull はビギナーの間は使わない.
  • その他,#Guideline参照.

ブランチの新規作成と一覧

新規作成:

git branch BRANCH-NAME

ブランチの一覧:

git branch

ワークツリーのブランチには,アスタリスク * が付けられている.

リモートのブランチもすべて一覧:

git branch -a

ブランチの切り替え (checkout)

git checkout BRANCH-NAME

クローン (clone)

以下で,リポジトリを複製できる:

git clone REMOTE-ADDRESS
  • REMOTE-ADDRESS : 複製元(オリジナル)のアドレスを書く(アドレス指定は#REMOTE_ADDRESS参照).

複製元は origin としてリモートリポジトリのリストに登録される.

ワークツリーのブランチは,複製元と同じになるようだ(要確認).複製元に複数のブランチがあった場合 (e.g. master, dev),

git branch

だけではすべてのブランチを表示できないので,

git branch -a

とする.以下のように,複製元 (origin) のブランチが一覧できる(ただし,HEAD以外).

* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/dev
  remotes/origin/master

ブランチを切り替えるには,checkout を使う.例えば:

git checkout dev

これ以降,dev ブランチは git branch で表示できるようになる.

ダウンロード (fetch)

リモートリポジトリから更新をダウンロードする:

git fetch REMOTE-NAME
  • REMOTE-NAME : リモートリポジトリの名称.origin など.

結果:

* [new branch]      dev        -> REMOTE-NAME/dev
* [new branch]      master     -> REMOTE-NAME/master

更新されたリモートブランチのリストが表示される(ただし,ローカルのブランチ・ワークツリーは変更されない).

マージ (merge)

fetch で取得したリモートブランチの更新を,ローカルのブランチに反映させるには,対象のブランチをチェックアウトし,マージを実行する.

フェッチの結果:

* [new branch] BRANCH -> REMOTE-NAME/BRANCH

に対して,

git checkout BRANCH
git merge REMOTE-NAME/BRANCH

を実行すると,変更がマージされ,ワークツリーに反映される.既にワークツリーが BRANCH の場合,チェックアウトは必要ない.

BRANCH が新規に追加されたブランチの場合

git branch BRANCH REMOTE-NAME/BRANCH

を実行して,REMOTE-NAME/BRANCH をベースにして新しいブランチをローカルに作成する.

競合 (CONFLICT) が起きている場合のマージは #REMOTE_MERGE_CONFLICT を参照.

ブランチ間のマージ

今作業中のブランチに,別のブランチをマージする方法について.

この場合は,non fast-forward (--no-ff) を使う方がよい.何もマージオプションを付けないと,fast-forward という方式が使われる.これは,一方のコミットが他方の過去のコミットである場合に,単純に履歴を更新するだけのマージ方式だ.ただし fast-forward を使う場合でも,競合があるとマージコミットが新しく作られる.一方 non fast-forward を使った場合,必ずマージコミットが作られる.通常ブランチは何らかの作業目的のために作られるので,non fast-forward でマージコミットの記録を残しておいた方が,後で見たときにわかりやすい.

Non fast-forward でマージするには:

git merge --no-ff BRANCH-NAME
  • BRANCH-NAME: マージするブランチ.

競合 (CONFLICT) が起きることがあるので, #REMOTE_MERGE_CONFLICT を参考に修正する.

ダウンロード&マージ (pull)

ビギナーは使わないことを推奨.#REMOTE_PULLのNoteを参照.

リモート REMOTE-NAME のブランチ BRANCH-NAME をダウンロードし,ワークツリーにマージする.これに先立って,ワークツリーのブランチは BRANCH-NAME であることを確認する.

git checkout BRANCH-NAME
git pull REMOTE-NAME BRANCH-NAME

アップロード (push)

ベアリポジトリにアップロードする方法について.

すべてのブランチをアップロード:

git push REMOTE-NAME
  • REMOTE-NAME : リモートリポジトリの名前.

特定のブランチのみをアップロード:

git push REMOTE-NAME BRANCH-NAME

リモートに存在しないブランチをアップロードするには,明示的に BRANCH-NAME を指定してアップロードする必要がある:

git push REMOTE-NAME BRANCH-NAME

タグ情報も含めてアップロードする場合は,--tags オプションを付ける.

Git周辺ツール

コンソールUIのGitブラウザ (tig)

以下で実行:

tig

すべて見る:

tig --all

グラフィックUIのGitブラウザ (qgit)

以下で実行:

qgit

すべて見る:

qgit --all

トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2015-07-14 (火) 20:11:35 (1101d)