GitのHEADとmaster…
Gitにもう少し慣れる
本題
そもそもEC Cube3の内部を弄ってみたくてついでにGitで管理しようかなって思い、この作戦を遂行する。
$ git init $ git config --global user.email "メールアドレス" $ git config --global user.name "ユーザー名"
だけやっておきました。
$ git add .
ステージング作業。
- 「.」 変更・新規作成分を登録
- 「-A」フォルダの中身を一括登録
- 「-u」変更したファイルのみ登録
- 「-p」変更した部分を指定して登録
らしいです。
ちなみにWindowsではadd実行時に 「The file will have its original line endings in your working directory.」 「warning: LF will be replaced by CRLF in (パス).」 みたいなwarningが出ると思います。
git config --global core.autoCRLF false
で改行コードの変換を無効にできますが個人的には特に気にならないのでそのままにしてあります。 ステージングができたら現在どのような状態になっているのかチェック。
$ git status
なんかnew fileたちがバーッと出ます。この画面かっこいいですね。 ってことはステージングできてるぜーって事みたいなので早速ローカルリポジトリにコミットしてみますか。 ひとまずこのコマンドだけ覚えておく。
$ git commit -m "コメントを書けます"
間違ってコミットした場合は、git resetで取り消せる。
コメント付きでコミット だーっと文字が流れてこの状態。 これでコミットできたかな。 ちょっとチェックしてみます。
$ git log
- git log –oneline
- git log -p(変更した場所を見たい場合)
- git log –stat(より詳しく変更した場所を見たい場合)
これでローカルリポジトリは完成。
後はリモートリポジトリの方にバックアップを取りたいので 予めBitBucketの方でリモートリポジトリを作成しておきます。 作成の仕方についてはグーグル先生に聞けば無限に情報があります。
git remote add origin https://あなたのアカウント@bitbucket.org/あなたのアカウント/eccube3.git
みたいな感じで登録できるはず・・・ 登録できたみたいなので
$ git push origin masterおやっなんか動き始めた。 BitBucketにログインしてくれやってことでしょうか。
ログインしてみたら 出来たっぽいです(?) BitBucketのサイトで確認(30秒くらい反映されないです)
出来てる!
ブランチを作ります。 複数の作業履歴を並行して保存していく場合のための手法。
$ git branch first
こんな感じで"first"って名前のブランチを作ります。
$ git checkout first
これで"first"ブランチに切り替え。
masterに戻りたいときはこんな感じ
$ git branch -a
これで今現在カレントブランチがどこなのか、今存在するブランチはどれだけあるのかが確認できます。 切り替えて遊んでみました。
ほんでブランチってのは何なのか。 “ブランチとは、履歴の流れを分岐して記録していくためのものです。分岐したブランチは他のブランチの影響を受けないため、同じリポジトリ中で複数の変更を同時に進めていくことができます。" という分かりやすい説明があった。
masterというブランチに基本的にメインのバージョンを置いていくことになりますねはい。
firstのブランチを更新してcommitした時点でHEADがfirstにいる状態になる。 現時点で最新版であるfirstブランチでの更新をmasterにmergeしてみる
$ git checkout master Switched to branch 'master' $ git merge first Updating なんとか Fast-forward 更新内容~みたいな
これでマージ完了。 あとは更新されているかどうかファイルをチェックする。
masterブランチの指すコミットがfirstと同じ位置に移動しました。 firstブランチは更新用として用意したのでこちらはもう要らない、という判断になったとします。
ブランチを削除したい場合
$ git branch -d first Deleted branch issue1 (wasなんとか)
masterに最終的に統合する目的でバグフィックスや追加機能などをトピックブランチとして用意して使う、という目的が自分には向いているようです。 追加機能等うまくいかなかったら一旦masterに戻って考え直す・・・みたいな感じです。
後はpullコマンドだけ覚えようと思う。
- second
- third
- master(もともと存在する)
とbranchを作って secondを更新してaddしてcommit。 そしてthirdも更新してaddしてcommit。 これでsecondとthirdは違う内容になってそれぞれの道を歩んでいく・・・。
masterにsecondで追加した機能をmergeする。
$ git checkout master $ git merge second
さらにmasterにthirdで追加した機能をmergeする。
$ git checkout master $ git merge third Auto-merging myfile.txt CONFLICT (content): Merge conflict in それぞれのbranchで更新したファイル Automatic merge failed; fix conflicts and then commit the result.
するとコンフリクトエラーが起きる。 同じファイルの同じ行に違う内容が更新されているから、 と言う事になる。
secondとthirdで更新していた内容 <<<<<<< HEAD secondのみで更新していた内容 ======= thirdのみで更新していた内容 >>>>>>> third
このようにファイルの内容が変更されるので、 「ああ、なるほどsecondに他の誰かが機能追加したんだな。手動でマージしておこう」と呟きながら
secondとthirdで更新していた内容 secondのみで更新していた内容 thirdのみで更新していた内容
と変更する。 これでsecondとthirdで更新していた内容が両方masterに追加された。 ここまで出来たらmasterをaddしてcommit -mする。 現時点で
second
secondとthirdで更新していた内容 secondのみで更新していた内容
third
secondとthirdで更新していた内容 thirdのみで更新していた内容
master
secondとthirdで更新していた内容 secondのみで更新していた内容 thirdのみで更新していた内容
こんな状態になる。
secondブランチをマージするとき、thirdブランチをあらかじめrebaseしていれば履歴を一本にすることもできた・・と言う事なのでやってみる。
$ git reset --hard HEAD~
これで先ほどのコミットをキャンセル。 この時点で
second
secondとthirdで更新していた内容 secondのみで更新していた内容
third
secondとthirdで更新していた内容 thirdのみで更新していた内容
master
secondとthirdで更新していた内容 secondのみで更新していた内容
となってmasterとsecondが同じという状態、thirdだけがまだマージされていない状態となる。
thirdをマージしたいのでまずはthirdに移動する。
$ git checkout third
thirdをrebaseする。
$ git rebase master
これで何やかんや「現在のmasterと競合があるよ」というエラーが出る。 同時にthirdの競合があるファイルに自動的にどこが競合しているか追加される。
third
secondとthirdで更新していた内容 <<<<<<< 6c7f072099714a5f91823df22f691e857df4bfd2 secondのみで更新していた内容 ======= thirdのみで更新していた内容 >>>>>>> その時のコメント
みたいな表現になっています。 ので、修正します。
third
secondとthirdで更新していた内容 secondのみで更新していた内容 thirdのみで更新していた内容
はい、これをmasterの最新版としてmergeしたいわけです。 addしてcommit・・・ではなく、rebase –continueします。
(third) $ git rebase --continue Applying: その時のコメント
これでmasterにマージ出来る状態です。
$ git checkout master Switched to branch 'master' $ git merge third Updating 8f7aa27..96a0ff0 Fast-forward 更新したファイル | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
これで
second
secondとthirdで更新していた内容 secondのみで更新していた内容
third
secondとthirdで更新していた内容 thirdのみで更新していた内容
master
secondとthirdで更新していた内容 secondのみで更新していた内容 thirdのみで更新していた内容
となる。
リモートにpush
$ git push [リモートリポジトリ] [ローカルのブランチ名]:[リモートのブランチ名]
ってな感じでリポジトリにpushするらしいです。
git remote add origin https://ユーザー名@bitbucket.org/ユーザー名/リポジトリ名.git git push origin master
こんな感じ。なんかごちゃごちゃとやらかしていてfatal: remote origin already exists. エラーが出る場合は
$ git remote rm origin $ git remote add origin git@github.com:ユーザ名/リポジトリ名.git $ git push -u origin master
ディスカッション
コメント一覧
まだ、コメントがありません