2
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

gitのpush周りで問題が起きた時の対処

Last updated at Posted at 2019-01-24

pullできない

古いシステムの乗っている本番サーバーには本番の環境に合わせてファイルが弄られているものがあったりして、コードの更新などをする際にすんなりpullできないことがある。
具体的にはこんなエラー表記が出る。

Your local changes to the following files would be overwritten by merge

この時に使ったコマンドは基本的な開発をする上でのaddやcommitとは違うので、今まで触ることがなかったので、覚書として書くことにしました。

#どうやったか
本番のサーバーで変更のあったファイルをstashを使って一時退避。変更した部分が消えたところで、リモートリポジトリから更新したソースコードをpullしてくる。
今度はstash popを使って退避したファイルを元に戻す。
stash popを使えば、退避させたファイルが自動的にマージされる。
でソースコードの本番反映は完了。

対処に使うgitコマンド

ファイル退避コマンド

変更ファイルを一時的に記憶領域へと退避させる。今回は、本番サーバーで変更のあったファイル群をこれを使って逃すことにした。このコマンドはファイルが変更されていない限り使用できないという使用条件がある。

$ git stash save ファイル名

退避ファイル復活コマンド

stashで退避させたファイルを再度ワークスペースへと引き戻す。この際に自動的にマージが行われる。

$ git stash pop

新規ファイル退避コマンド

先ほどファイル変更されていないとstashは使えないと書いたが、中には新規で作られたものもあるかもしれない。そんな時は、-uオプション(多分untrackの意味だと思います)を使えば新規作成されたファイルも退避可能です。

$ git stash -u 

#コミットを見るコマンド
コミットIDや、コミットメッセージ、コミッター、コミットした日付などが見られる。オプションを使って見たいコミットを絞り込むことができる。
個人的によく使うオプションは、

  • --all
  • -n 表示数
  • --author='ユーザー名'
$ git log

特定のコミットの日付やユーザーの他にコードの差分も確認できる。

$ git show コミットID

#指定コミットまでバックするコマンド
本番いじっているファイルで問題が生じたりした時にカムバックしたい時は
コミットのログを見れるコマンドを使って、コミットIDを調べた後に、このコマンドを使用することで、そのコミットIDの場所までバックすることができる。
pushする前の対抗手段としてのresetコマンドは以前の記事で詳しく書いたので、ここでは、pushした後の対処方法としてcheckoutを使います。

resetコマンドに関してはこちらです。
機能だけで覚える基本的なGitコマンド 〜ほぼほぼ作業順〜 

checkoutコマンドはブランチ切り替えに使ったコマンドですが、バックする際にも利用可能です。
指定したコミットIDにまで状態を戻します。その際に、指定したコミットID以降のコミットはpushされていな限り、破棄されますので戻せなくなります。
ただ、git logには以前のコミットIDが残っているので、どこにでも切り戻しが可能。切り戻した段階では、コミットID指定した場所が、ステージングに上がった状態まで戻っています。
ただし、切り戻されるのはあくまでローカルリポジトリでの話なので、pushしない限り、切り戻した状態はリモートには反映されません。

$ git checkout コミットID -- ファイル名

[加筆:パニクった経験]rejectされたからstashしたら・・・

stashを行い、git pullを行なった後に、pushを行なったら、自分のいじっていないファイルがごっそりpushされていて焦った。

コミットメッセージは以下の通り。

Merge branch 'master' of github.com:gaiax/hogehogeapp

弄ってもいないファイルしかpushされていなかったので、これはやらかしたかと思ったんですが、pullを行なった際に、さっきrejectされていたpushが裏側で自動的にpushされ、再度pushを行なった時に裏側で行われたpushでgitにあったファイルの進んでいた分を上書きしてしまっているので、再プッシュによって、その差分を埋めてくれたことになっているようです。
順番が前後していますが、mergeはうまく最新のものになっているようです。

が、pushがリジェクトされたら、その時点でpushをgit resetで取り下げてから、stash=>pull=>stash pop=>pushの手順が心臓には良さそうです。

2
2
2

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?