よく使う!Gitの20コマンド

リポジトリの作成およびメンテナンスに利用するコマンド

■1:git init リポジトリを作成する

 Gitを利用するには、まずリポジトリの作成が必要だ。リポジトリ作成を行うコマンドは「git init」である。リポジトリを作成したいディレクトリでこのコマンドを実行すると.gitディレクトリが作成され、Gitリポジトリの管理ファイル等がここに作成される。

$ cd <リポジトリを作成するディレクトリ>
$ git init

■2:git clone 既存のリポジトリの複製を作る

リポジトリの複製を行うには「Git clone」コマンドを利用する。このコマンドは既存のリポジトリからローカルにファイルをコピーして作業用のリポジトリを作成する、といった場合などに利用する。

$ cd <リポジトリを作成するディレクトリ>
$ git clone <複製したいリポジトリのURL>

■3:git fsck リポジトリの正当性チェックを行う

リポジトリがもし破損した可能性がある場合、「git fsck」で破損している個所を検出できる。

$ git fsck

また、完全なチェックを行うには「–full」オプションを付けてgit fsckを実行する。

$ git fsck --full

 

■4:git gc リポジトリ内の不要なオブジェクトを削除し、最適化を行う

 「git gc」コマンドは、リポジトリ内のオブジェクトの圧縮(pack)や不要なオブジェクトの破棄などを行うものだ。これによってリポジトリが使用するストレージ容量を減らせるだけでなく、パフォーマンスの向上も期待できる。頻繁に実行する必要はないが、大量のコミットやマージを行った場合などには実行するとよいだろう。

$ git gc

 

■5:git status 変更が加えられたファイルを表示する

どのファイルが追加/変更されたのかは、「git status」で確認できる。git statusを実行すると、次の例のように追加/変更されたファイルの情報が表示される。

$ git status
# On branch master
# Changed but not updated:
# (use “git add <file>…” to update what will be committed)
#
# modified: HBPreferencesTransFormer.h
# modified: HBPreferencesTransFormer.m
#
no changes added to commit (use “git add” and/or “git commit -a”)

 

■6:git diff ファイルに加えられた変更点をdiff形式で表示する

特定のファイルにどのような変更が加えられたかは「git diff」コマンドで確認できる。

$ git diff <変更を確認したいファイル>

■7:git add コミットするファイルを指定する

変更点を保存するには、git addコマンド

$ git add <追加/変更したファイル1> <追加/変更したファイル2>

 

■8:git commit 変更点をコミットする

git addコマンドで対象とするファイルを指定したのちに「git commit」コマンドを実行する。

$ git commit
また、git commitを「-a」オプションを付けて実行すると変更が加えられたファイルを自動検出してコミットできる。ただし、この場合新規に作成されたファイルはコミット対象にはならない。

 

■9:git log コミットログを閲覧する

「git log」でリポジトリのコミットログを閲覧できる。コミットログは新しいものから順に表示され、次の実行例のようにそれぞれのコミットについてそのコミットを表すハッシュ値とコミット者、タイムスタンプ、コメントが表示される。

$ git log

 

■10:git reset 直前のコミットを取り消す

 コミット後に小さなミスなどに気付いた場合などに便利なのが「git reset」だ。たとえばコミット後に「git reset –soft HEAD^」と実行すると、直前に行ったコミットを取り消すことができる。

$ git reset –soft HEAD^

この場合、作業ツリーの内容はコミット時のままで「コミットした」ということだけが取り消される。もし作業ツリーに加えた変更点までも取り消したい場合は、「–soft」の代わりに「–hard」を指定すればよい、

また、コミットされていた内容は「ORIG_HEAD」という名前で参照できる。これを利用して、次のように実行することで現在の状態とコミットされていた状態の差分を表示できる。

$ git diff ORIG_HEAD
修正後に再度コミットを行うには、下記のようにする。これを実行すると、先に入力したコミットメッセージを再編集してコミットが行える。

$ git commit -a -c ORIG_HEAD
なお、git commitに「–amend」オプションを付けて実行することで、直前に行っていたコミットを訂正することができる。

$ git commit
(コミット後にミスに気付き、ミスを修正)
$ git commit –amend (先に行ったコミットが、ミスを修正したものに置き換えられる)
上記の操作は、次のような操作とほぼ同一の働きをする。

$ git commit
$ git reset –soft HEAD^ (コミット後にミスに気付き、コミットを取り消し)
(ミスを修正)
$ git commit -c ORIG_HEAD

 

■11:git revert 作業ツリーを指定したコミット時点の状態にまで戻す

「git revert」は作業ツリーを指定したコミット時点の状態にまで戻し、コミットを行うコマンドである。引数にはコミットを指定するハッシュ文字列もしくはタグ名などを指定する。

$ git revert <コミット名>
git revertはgit resetと似ているが、作業ツリーを差し戻したという情報が作業履歴に残るのが異なる点だ。

 

■12:git branch ブランチ情報の表示およびブランチの作成

現在のソースツリーを元に新たなブランチを作成するには、「git branch」を使用する。

■13:git checkout ブランチの切り替え

また、操作対象とするブランチを切り替えるには、「git checkout」を使用する。

なお、git checkoutに「-b」オプションを付けて実行すると、新たにブランチを作成してそのブランチに切り替える、という作業が一発で行える。たとえば、「git checkout -b temp01」は、次の2つのコマンドを順に実行した場合と同じ結果になる。

 

git chekckoutは編集されたファイルがある場合は失敗します

そんなときでも強制的にチェックアウトする方法があります
git checkout –force <ブランチ名>
このときの変更は全て破棄されます。

■14:git show-branch ブランチの作成/変更/マージ履歴を表示

どのブランチがどのブランチを元に作られたか、という情報は「git show-branch」で確認できる。git show-branchでは次の例のような出力を行うが、前半の「—」までがブランチ履歴、「—」から後半が最近のコミット履歴を表している。

■15:git merge ローカルブランチのマージを行う

「git merge」は、現在の作業ブランチに別のブランチで行われた変更点を取り込むコマンドだ。

$ git merge <変更点の取り込み元ブランチ>
マージが成功した場合はそのままコミットも行われる。いっぽう、競合が発生したファイルには下記のような形式で競合している個所にマーカーが埋め込まれる。

<<<<<<< <ブランチ名>:<ファイル名>
<作業中ブランチの内容>
=======
<変更点の取り込み元(マージ元)ブランチの内容>
>>>>>>> <ブランチ名>:<ファイル名>

なお競合が発生した場合、このマーカーを取り除いて競合を解消するか、もしくはマージを取り消すまでコミットが行えないので注意してほしい。

■16:git tag コミットにタグを付ける

 Gitではコミットをハッシュ文字列で管理しているため、ユーザー側から見るとどの文字列がどのコミットを表しているのか分かりにくい。「git tag」は、直前のコミットに対して分かりやすい別名(タグ)を付けるコマンドだ。

$ git tag <タグ名>
タグ名を指定せずにgit tagを実行すると、現在のリポジトリ内にあるタグを確認できる。

$ git tag rev1 (「rev1」というタグを付ける)
$ git tag (タグを確認する)
rev1

 

■17:git stash 現在の作業ツリーの状態を一時的に保管する

 現在の作業中の状態をコミットせずに、一時的にほかのブランチに対して作業を行いたい、という場合に役立つのが、「git stash」コマンドだ。このコマンドでは、現在の作業ツリーの状態を一時的に保存しておくことができる。

$ git stash <保存名もしくはコメントなど>
git stashの実行後は、git checkoutなどで作業したいブランチをチェックアウトすればよい。作業の完了後作業中だった作業ツリーを再度呼び出すには、元のブランチをチェックアウトしてから「git stash pop」コマンドを実行する。また、「git stash list」を実行すると、一時保存されている作業ツリーが一覧表示される。

$ git stash list
$ git stash pop

 

■18:git rebase ブランチの派生元(上流)を変更する

 「git rebase」は、「ブランチの派生元を変更する」という、CVSやSubversionにはなかったユニークな機能である。git rebaseがどのような処理を行うかは次の図1を参照してほしいが、簡単に言えばあるブランチに対して行った変更点を、派生元のより新しいリビジョンのものに適用するものだ。

git rebaseを利用するには、作業を行いたいブランチで次のように実行すればよい。

$ git rebase <派生元ブランチ>
このとき、もし競合が発生すればgit mergeの場合と同様に競合点がマーカーとともにファイルに記載される。また、「git rebase –abort」でrebaseを取り消すこともできる。

 

■19:git pull ほかのリポジトリの変更点をローカルリポジトリにマージする

ほかのリポジトリで加えられた変更点を現在のブランチにマージするには、「git pull」コマンドを利用する。

$ git pull <変更点の取り込み元リポジトリ>

変更点の取り込み元リポジトリは、git cloneの場合と同様にURLで指定する。また、git cloneコマンドで作成したリポジトリの場合、.git/config内の「remote」項目などに複製元リポジトリのURLが自動的に記録されるため、複製元リポジトリからpullを行う場合は下記のように取り込み元リポジトリを指定しなくとも実行できる。

$ git pull

 

■20:git push 公開リポジトリに自分のリポジトリの内容を送信する

git pullはほかのリポジトリの内容を自分のリポジトリに取り込むものだったが、逆に自分のリポジトリの内容をほかのリポジトリ(一般的には公開リポジトリ)に送信して取り込ませるコマンドが「git push」である。

git pushの引数には、送信先のリポジトリURLと送信するブランチ、送信先ブランチを指定する。

$ git push <送信先リポジトリ> <送信するブランチ>:<送信先ブランチ>
送信先ブランチを指定しなかった場合は、送信するブランチと同じブランチを指定したものとみなされる。また、送信先ブランチが送信先リポジトリに存在しない場合はそのブランチが作成される。

pull requestでCan’t automatically merge発生の場合の対応

※用語の定義
hogehogeブランチ => 自身が開発するブランチ
developブランチ => チームの各人が開発したブランチをmergeするブランチ

《発生した問題》
git push でリモートにあげたhogehogeブランチをdevelopブランチへpull requestしたところCan’t automatically mergeのエラーがでてmergeが出来ない。

引用:http://qiita.com/hibriiiiidge/items/7fee5035a48dbb73aa51

昔のコミット内容にちょっとしたバグを見つけた

そのコミットをまだpushしていない場合限定
新しく行なった変更を以前のコミットに含めたい.
直前のコミットに含めたい

上記のcommit –amendを使うとよい.
それ以上古いコミットに含めたい

変更をcommitしたあと,git rebaseを使う.

引用:http://qiita.com/yaotti/items/0d5364eae36ad1bb8e01

git commitをやり直しする&取り消しする(「git commit –amend」と「git reset」)

git commitを実行あとでコミットをやり直したり、コミット自体を取り消す方法です。

直前にしたコミットをやり直す(git commit –amend)

直前にしたコミットをやり直す場合、「git commit –amend」を使用します。

例えば、直前のコミットログが以下のような状態だったとします。

実は直前のコミットに含めるべきであった「hoge.txt」が含まれていませんでした。

コミットログ(git commit –amend 実行前)

引用:http://d.hatena.ne.jp/mrgoofy33/20100910/1284069468

Flash Builder を使用した Apple iOS の開発プロセス

 

 

手順の番号 手順 場所 前提条件
1. Apple Developer Program に参加します。 Apple Developer サイト なし
2. iOS デバイスの Unique Device Identifier(UDID)を登録します。 iOS Provisioning Portal Apple Developer ID(手順 1)
3. 証明書署名要求(CSR)ファイル(*.certSigningRequest)を生成します。
  • Mac OS の場合、キーチェーンアクセスプログラムを使用します。
  • Windows の場合、OpenSSL を使用します。
なし
4. iOS 開発用証明書または配布用証明書(*.cer)を生成します。 iOS Provisioning Portal
  • Apple Developer ID(手順 1)
  • CSR ファイル(手順 3)
5. iOS 開発用証明書または配布用証明書を P12 形式に変換します。
  • Mac OS の場合、キーチェーンアクセスプログラムを使用します。
  • Windows の場合、OpenSSL を使用します。
  • Apple Developer ID(手順 1)
  • iOS 開発用証明書または配布用証明書(手順 4)
6. アプリケーション ID を生成します。 iOS Provisioning Portal Apple Developer ID(手順 1)
7. プロビジョニングプロファイル(*.mobileprovision)を生成します。 iOS Provisioning Portal
  • Apple Developer ID(手順 1)
  • iOS デバイスの UDID(手順 2)
  • アプリケーション ID(手順 6)
8. アプリケーションを作成します。 Flash Builder
  • Apple Developer ID(手順 1)
  • P12 の開発用証明書または配布用証明書(手順 5)
  • アプリケーション ID(手順 6)
9. アプリケーションをデプロイします。 iTunes
  • プロビジョニングプロファイル(手順 7)
  • アプリケーションパッケージ(手順 8)

http://help.adobe.com/ja_JP/flex/mobileapps/WS064a3073e805330f6c6abf312e7545f65e-8000.html