忍者ブログ
プログラマ、ララ・ベル子さんのゆるふわ奮闘記。

[PR]

×

[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。

Git pullしたらGitから怒られた場合の対処法

どうも!いつも妖気なベル子です☆

「ようき」って打ったら一番最初に「妖気」って出るのおかしいと思うの。
そんなに日常的に「妖気」って使わないよねー。
それともあれか、お前はこっちだろ的なG○○gleからの圧力かな?

ということで、最近ベル子も大人の女性になってきたので、
「プルリクしたんでチェックおなしゃーす!」と言われることがあります。

プルリクって何かな?という人のために解説すると
「あなたの作ってるコードをこういうふうに修正してみたんだけど、これをマージして欲しいの!見てみて!」
というリクエストを投げることです。

詳しいことは私のブログなんかより、詳しい記事を参照してくれたまえ。
http://www.backlog.jp/git-guide/pull-request/pull-request1_1.html

そして、そのコードがよさ気だったらマージできるし、
「ダサくて汚いからムリ!」だったら却下できるという画期的なシステムです。


というわけで、プルリクが来たのでひととおりチェックし、コメントします。

べ「もうーちょっと男子ー。そこマジックナンバーじゃーん。変数に入れてよー。」
男子「・・・修正しました。」

よしよし、それでまたgit pullして、、、、と思ったらgitに怒られる。


You asked me to pull without telling me which branch you want to merge with, 
and 'branch.new_branch.merge' in your configuration file does not tell me, either.
 Please specify which branch you want to use on the command line and try again
 (e.g. 'git pull  '). See git-pull(1) for details.


べ「ふが!また、やっちまったぜ」

そうです。
私がよくやってしまうミスとして
リモートブランチに出来た新しいブランチのコードを以下のように持ってきてしまいgit pull時に怒られるというミスがあります。

$ git fetch
$ git checkout -b new_branch
$ git pull origin new_branch

何度もやっているのに、ついついやってしまうので、
戒めのためにブログに記しておきます。

git pullのみ(引数なし)でリモートのブランチをpullするには
上流ブランチが設定されていないとなりません。

そして、
リモートブランチを上流ブランチに設定する方法は以下の3つだ!!


設定方法 1.

怒られたから上流ブランチを後からちゃんと設定してやりたいとき

Git 1.7.0
$ git branch --set-upstream new_branch origin/new_branch

Git 1.8.0
カレントブランチを紐付ける場合:
$ git branch -u origin/new_branch
or
$ git branch --set-upstream-to=origin/new_branch

カレントブランチじゃないブランチを紐付ける場合:
$ git branch -u origin/new_branch new_branch
or
$ git branch --set-upstream-to=origin/new_branch new_branch

設定方法 2.

自分で作ったブランチのとき

$ git push -u origin new_branch

※-uで上流ブランチの設定をするのは初回の1回でよい。その後はgit pushで引数いらない。


設定方法 3.

プルリクされたときや、人が作ったブランチをリモートからもってくるとき←これが正解!!!!

$ git checkout -b new_branch origin/new_branch


教訓

ブランチ作成後の初回pushの際は-uオプションをつけよう
リモートのブランチを持ってくる際にpullしてくるのはやめよう

これで怒られなくなり一安心です。

ついでに、チェックしてマージしてリモートブランチを削除したあと
自分のローカルをキレイにする手順を紹介します。

これをやらないと、プルリクをたくさんもらうようになるとローカル環境がわけ分からなくなります。
プルリクのトピックブランチをマージ&削除したら必ずローカルもリモートと同じようにブランチを削除しておきましょう。


1.どんなブランチがローカルにあるのか確認
$ git branch -a
* pull_req_no_branch
 develop
 master
 remotes/origin/pull_req_no_branch
 remotes/origin/develop
 remotes/origin/master

2.リモートで削除されたブランチをローカルのリモートブランチからも削除する
$ git fetch -p
〜省略〜
   123456..78910  develop    -> origin/develop
 x [deleted]         (none)     -> origin/pull_req_no_branch

3.どうなったか確認する
$ git branch -a
* pull_req_no_branch
 develop
 master
 remotes/origin/develop
 remotes/origin/master
リモートのpull_req_no_branchが消えた!!

4.develop(開発本流)に切り替える
$ git checkout develop


5.マージされたリモートのコードを落としてくる
$ git pull

※ここでマージされたコードをgit pullしておかないと次のブランチ削除コマンドで以下のように怒られる

error: The branch 'pull_req_no_branch' is not fully merged.


6.プルリクに使ったトピックブランチをローカルから削除
$ git branch -d pull_req_no_branch
Deleted branch pull_req_no_branch (was 1234567).


7.どうなったか気になる
$ git branch -a
* develop
 master
 remotes/origin/develop
 remotes/origin/master


なーーーーーーーーーーーーい!!!!!!!!!全部きれいさっぱりなくなったよ!!


ということで、この手順で昔のことはキレイさっぱり忘れてしまいましょう。
そうです。
昔の彼のことなんて思い出してもいいことなんて何もない。
あのとき別れなければと思って、また付き合ったとしてもどうせ別れることになるんです。
花はミツバチを追いかけますか?
NO!!!!否!!!!!!
飛んでったミツバチのことなんて、追いかけない。
そう、35億。Yes、35億。

ということで皆さんも、
gitに怒られないハッピーライフを送ってくださいねーー♪

拍手[1回]

PR

gitのlogを美しくtree表示するエイリアスを設定する

公式Twitterの中の人業務をやっている関係で、
ツイートするネタを探していたら
gitのlogがtree表示できることを知ったのでエイリアスを設定してやりました。
だので手順をまとめます。

ちなみに、自分はエイリアス使わない派です。
理由は「タイピングを無駄にいっぱいして打鍵音を響かせることにより、テレビで見たことあるハッカー感を出す」ためと
「コマンドを思い出すことで脳活も兼ねる」ためと
「端末ごとにいちいち設定してやらないといけないのが面倒」なためと
「いっぱい打たないといけないから誤爆なさそう」というビビリ体質のためです。

ただ、このコマンドーを覚えて打つには、ピアニストバリの指の鍛錬と記憶力が必要そうなので、
今回はエイリアスを設定してやります。

まずはコマンド打ってどんなもんか表示してみます。

git log --graph --date=short --decorate=short --pretty=format:'%Cgreen%h %Creset%cd %Cblue%cn %Cred%d %Creset%s'


美しすぎるーーー!
とても気に入りました。

では、エイリアスに登録いたします。

git config --global alias.tr 'log --graph --date=short --decorate=short --pretty=format:"%Cgreen%h %Creset%cd %Cblue%cn %Cred%d %Creset%s"'


そして、いよいよ、エイリアスを打ち込みます。
git tr


わーい!ゴイスーだよー♪

これでいつでもlogを美しく確認することができます。

ヤフーー ジャパニーズ ワビサビーー♪

参考にさせていただいたのは、こちらの記事です。
【凄腕Webエンジニア7人に聞いてみた】どんな開発環境や便利ツール使って仕事してるの?
ありがとうございます!
記事を書いてる人のギャグセンがめっちゃよくて大好きです。

拍手[0回]

git diffから除外したいファイルの指定方法

こんにちは。
自分のメモ代わりだから、さらっと書きますよー。

gulpでcssやらjsをコンパイルするとgit diffで余計なものがたくさん引っかかるのが嫌だ。
修正した箇所だけ見たい。
diff見ないでコミットとかしたくない。
そんなときに使えるコマンドが
git diff --diff-filter=M

修正があったファイルだけdiffするコマンドーだそうな。
他にもdiff-filterのオプションにはA (追加)、C (コピー)、D (削除)、R (リネーム)とかもあるらしいです。つ、使えるNE★
詳細はこちらの偉大なページをごらんください。

やったーこれで解決だぜ!と思ったのに、
all.css.map
みたいなmapファイルがまだひっかかる。

こんな大量の意味なし修正コードなんて見たくない(´・ω・`)
矢印押す指も疲れちゃうし。

そんなときは
プロジェクトのrootディレクトリに.gitattributesというのを作成し、
*.map -diff
みたいに追記してやればいいそうな。

ドキュメントのここを読むと
*.map binary
でもいいっぽいです。

この辺の記事に詳しく説明があった。
Git でバイナリファイルを扱うときの私的設定

こんなページもあった。
Laravelでプロジェクトを作成したらまずやることメモ

↑この人は/public/js/配下とかにはコンパイル前のファイルは絶対入れないことにしてるっぽいけど、私はbrowserifyコンパイルしたのを、さらにマージさせてるからgitignoreとかできない。
cssもコンパイル後にマージしてる。

コンパイル後のマージ用ファイルをresources/assets/配下の別ディレクトリに入れればいんじゃね?
という声が聞こえてきそうだ。
でも、なんとなくそれをやると、「やっぱマージ前のやつ読み込んで作業したい。」とか、ベンダーファイルをマージしないで単体で読み込ませたいとか、そんな融通がきかなくなりそうな気がする。

ということで、私は/public/js/配下はgitignoreせず、手動でつけたりはずしたりできるコンパイル後のファイル群を入れることにする。

*.map binary
/public/build/**/* binary
を設定しちゃえば
git diff --diff-filter=M
する必要もあまりなくなる気がする。

あー今日も超寒い。会社におこたスペース作ってくれないかなぁ。
おこたでぬくぬくしながらコーディングしたいベル子でした。

拍手[0回]