git/Tips の履歴(No.23)

&tag(git);

目次†[edit]

目次
関連情報
使い始め
戻したい
履歴を確認したい
- diffを確認したい
コンフリクトの解消
- git pullでコンフリクトしたときの対処法
  - 参考情報
  - 前回git pullした状態に戻す
- git rebaseでコンフリクトしたときの対処法
ブランチ
その他Tips

↑

使い始め†[edit]

↑

ローカルリポジトリの作成†[edit]

プロジェクトディレクトリでローカルリポジトリを作成してコミットする
```
$ cd <PROJECT_HOME>
$ git init
$ git add .
$ git commit -a -m "first commit"
```

↑

リモートリポジトリの作成†[edit]

/home/repository/sample.gitディレクトリに空のリポジトリを作成する。

$ mkdir -p /home/repository/sample.git
$ cd /home/repository/sample.git
$ git --bare init

オリジナルワークツリーの内容をpush

$ cd <PROJECT_HOME>
$ git remote add origin /pub/repository/sample.git master
$ git push origin master

二カ所目でclone

$ git clone firstmac:/pub/repository/sample.git

↑

編集→コミットまでの流れ†[edit]

ファイル編集
新規ファイルがある場合はgit add .
git commit -a

↑

戻したい†[edit]

gitでアレを元に戻す108の方法 - TIM Labs
基本的にgit resetを使う。resetの引数はsoft、mixed(デフォルト)、hardがありそれぞれ異なる。
- soft: ワークツリー、インデックスそのまま。
- mixed: ワークツリーそのまま、インデックスは取り消す。
- hard: ワークツリー、インデックスを変更。
すなわちcommit直後にresetを実行する場合、"git reset HEAD^"が基本形で、インデックスやワークツリーをどうするかで引数を使い分ければ良い。例えばaddを取り消したい時はインデックスも取り消したいのでmixed(引数なし)にするとか。

↑

最後にcommitした状態にもどしたい†[edit]

checkoutした状態に戻したい場合など
```
git reset --hard HEAD
```
ゴミがある場合(gitで管理していないファイルが追加されてた場合)。
```
git clean -df
```

↑

commitしたときに余計なファイルやフォルダを追加したことに気がついたので戻したい†[edit]

ワークスペースの状態だけ保ちインデックスやコミットを戻す。
```
git reset HEAD^
```

↑

過去のcommitに戻したい†[edit]

以前のcommitに戻したい場合、git logなどでハッシュ値を確認して。
```
git reset --hard xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
```
これだけだと新規追加したファイルが残るのでuntracked filesを削除する場合、以下のコマンドも実行。Git clean | アトラシアン Git チュートリアル
```
git clean -df
```

↑

途中のcommitをなかったことにしたい†[edit]

git revertを使うとよい？ http://labs.timedia.co.jp/2011/02/git-various-undo.html

↑

履歴を確認したい†[edit]

↑

diffを確認したい†[edit]

"-p"オプションを使う
```
git log -p README.md
```

↑

コンフリクトの解消†[edit]

↑

git pullでコンフリクトしたときの対処法†[edit]

↑

参考情報†[edit]

Force git to overwrite local files on pull. - Stack Overflow

↑

前回git pullした状態に戻す†[edit]

一回もローカルリポジトリにcommitしてない場合
```
git reset HEAD
```
ローカルファイルに変更があってそれもなくす場合
```
git reset --hard HEAD
```
一回コミットしていた場合は、HEADの場合にHEAD^を使えばよい。

git logなどして確認する。

↑

git rebaseでコンフリクトしたときの対処法†[edit]

なぜ git rebase master はコンフリクトしたとき master 側を常に適用させたいときは --ours ですか？ - @kyanny's blog
developブランチでmasterをrebaseしようとしたときにコンフリクトした場合
```
git checkout develop
git rebase master
```

テキストファイルの場合衝突したファイルを修正。バイナリファイルの場合、

git checkout --ours  demo.txt(この場合master側を使う)
git checkout --theirs demo.txt(この場合develop側を使う)

その後
```
git add demo.txt
git rebase --continue
```

※rebaseの場合、masterをチェックアウトし(masterがoursになる)、developをcherry-pickするような動作なので、ours,theirsがこうなるらしい。

↑

ブランチ†[edit]

↑

全部ランチをpush†[edit]

通常masterブランチをpushするが場合によってはfeatureブランチなど全部をpushしたい場合もある。
```
git push -u origin --all
```

↑

ブランチを同期する†[edit]

gitのリモートブランチを使って作業を行う流れのメモ - 那由多屋開発日誌
Git - リモートブランチ
作業中のブランチはトピックブランチのこともある。そのブランチを同期する方法。
リモートブランチにトピックブランチをpush。
```
git push origin issue-99
```
別のマシンでリモートブランチをチェックアウト
```
git checkout -b issue-99 origin/issue-99
```
同じくpushする。
```
git push
```
push元では--set-upstream-toを指定しないといけないかも
```
git branch --set-upstream-to=origin/issue-99 issue-99
```

作業完了後はブランチを削除

 git branch -d working
 git branch -r -d origin/working
 git push origin :working

今さら聞けないgit pushコマンド - shoma2da's diary

↑

ベンダーブランチの管理†[edit]

↑

Gitで管理されていない上流ソースの管理†[edit]

Vendor branches in git | Jabbering Giraffe //例としてWordPressが取り上げられている。テーマを管理しようとするときにも役に立つかもしれない(→WordPress/テーマ - src's wiki)
How do I import a third party lib into git? - Stack Overflow
そのソース用に専用gitリポジトリを作って毎回インポートしなおす戦略。使用する側はそのgitリポジトリをサブモジュールとして参照。

↑