git/Tips の履歴(No.16)

Tag: git

目次†

目次
関連情報
日々の運用
- ローカルリポジトリの作成
- リモートリポジトリの作成
編集→コミットまでの流れ
サブモジュールを使う
空フォルダを管理する
Subversionからの移行
戻したい
git pullでコンフリクトしたときの対処法
- 参考情報
- 前回git pullした状態に戻す
git rebaseでコンフリクトしたときの対処法
PC/デスクトップで作業を同期
- トピックブランチを同期する※
ベンダーブランチの管理
- Gitで管理されていない上流ソースの管理
- Gitで管理されているソースの管理

↑

日々の運用†

↑

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

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

↑

リモートリポジトリの作成†

/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

↑

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

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

↑

サブモジュールを使う†

↑

空フォルダを管理する†

フォルダに空の.gitignoreファイルを置く。

↑

Subversionからの移行†

Windows以外の環境は安定してるようなのでWindowsがからまないなら使っても良さそう。Windows用クライアントはいろいろとだめ。
GUIクライアントはなくてもまあ大丈夫か。
SubversionからGitへの移行をオススメする７つの理由 - akimatter

↑

戻したい†

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

↑

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

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

↑

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

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

↑

過去のcommitに戻したい†

以前のcommitに戻したい場合、git logなどで確認して
```
git reset --heard xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
```

↑

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

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

↑

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

↑

参考情報†

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

↑

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

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

git logなどして確認する。

↑

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

developブランチでmasterをrebaseしようとしたときにコンフリクトした場合
```
git checkout develop
git rebase master
```

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

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

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

↑

PC/デスクトップで作業を同期†

commit単位を記にしなくて良いなら、中央リポジトリを使ってpush/pullしあうのが簡単。
リモートのgitブランチをローカルにチェックアウトする - sessanの日記
remote に branch を push し、remote から clone したリポジトリの branch を変更して push する - basyura's blog

↑

トピックブランチを同期する※†

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

↑

ベンダーブランチの管理†

↑

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

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

↑

Gitで管理されているソースの管理†

submoduleで管理するのが簡単?[git 1.6.0.2] submoduleを使おう！その2 - satoko's blog - s21g。forkしてから組み込むことで上流の変更にも追随できる。

git/Tips の履歴(No.16)

目次†

関連情報†

日々の運用†

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

リモートリポジトリの作成†

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

サブモジュールを使う†

空フォルダを管理する†

Subversionからの移行†

戻したい†

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

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

過去のcommitに戻したい†

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

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

参考情報†

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

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

PC/デスクトップで作業を同期†

トピックブランチを同期する※†

ベンダーブランチの管理†

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

Gitで管理されているソースの管理†