1人でも使うgit・github・bitbucket・mercurial

Category: tool Date: 07 Jun 2015

なるべく具体的な例として／実際使いながら随時調べたことメモ

Git個人使いでの設定

OSに依存しないように設定を行っていく／設定の確認は

 git config --global --list

使用するエディタの設定／Windowsがほとんどなので自前のGvimを設定する場合の例，パスはドライブレターをキチンと入れる他シングルクォートを含めて設定しないと駄目

git config --global core.editor "'t:/path/to/gvim'"

大抵ローカルなディレクトリにて既にある程度作成を行ってしまっている場合が多い，この場合はWebから手動で Create new repository

ここで一端最初のコミットを実施git commit

更にGitHubにpush

git push -u origin master

何が起こっているか／前提として，Gitは分散リポジトリであるのでどのリポジトリのどのブランチを触っているのかを意識する必要が有ること

-uオプション：ローカルのmasterブランチがoriginリモートリポジトリのmasterブランチと関連付けられ，以後のpushにおいて設定する事を意味する
ここでのupstreamは，ローカルのブランチがあるリモートのブランチに関連付けられている時に手元から見て関連づけられたリモートブランチを指す言葉／関連付けを行った手元のローカルブランチをトラッキングブランチと呼ぶ，手元は大きな流れを追いかけている人／先に見える大きな流れをupstreamと呼んでいるイメージ？
masterはGitが最初にコミットを行った際に自動で作成するブランチの名前／ホントに名前で有り，機能的意味があるものでは無く慣例的なもの，この名称の使われどころはリモートであろうがローカルである事とは関係無い

originはレポジトリの所在（URL）を示す別称となる，本名の確認は

  $ git config --list
  remote.origin.url=https://github.com/sousu/aaa.git
  remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*

ここまででGitHub側にも反映が行われた

同時期に何も考えずに更新をしているといつの間にかあのPCとこのPCでは内容が一致しなくなっている，ってパターンが良く出てくる／具体的には別のPCで更新したcommit内容を取り込む前に，自前のcommitを更新してしまったみたいなパターン

fetchコマンドを使っていく

自動的にローカル側の作業ツリーに更新状態を取り込みマージするpullとは違い
ローカルリポジトリに取り込みを行うが，作業ツリーにまで反映を行わず取り込みは操作者の責任で行われる
fetchで取り込んだリポジトリは，現在Fetchされているリモートブランチの最新リビジョンを示す FTECH_HEADキーワードとして指定できる／これを指定してlogやdiffの確認，mergeを行う作業となる

更にFetch内容のマージを行うと思った際に，手元側の軽微な変更状態があって出来ない場合は stashを使っていく

参考

単にダッシュボードが見やすいだけが理由だが，dotfileの管理についてはMercurialを利用しているので使い勝手をメモ

push時の衝突発生時の処理:

dotfileを更新していて良くあるのが他方で更新しているのを気づかないまま手元のPCで更新→コミットから反映を行おうとするパターン
まずはhg headsで他方の頭の状態を確認／changesetの番号を確認
マージする hg merge <番号>
hgの文字コードの扱いに問題が有るのかWindowsを挟んでやると失敗する事が多いので適切にhg merge -Pプレビューオプションと共に作業するのが良い

参考