はじめに
最近、Gitをよく使うようになってきた気がします（まだ初心者は脱却できてないと思います）。
そうなると、GithubなりGitLabなりBitbucketなりでの管理も重要になってきて、そうなると当然
git push
このコマンドを使う必要があるわけですよ。
しかし、このコマンドを打つと失敗することがあります。
エラーメッセージを読めばそれで済む話ですが、読むの面倒だしとりあえずpushしたいんだよ！！
ってなることはないこともないと思います。
そんな時のための対処法（？）です。
あ、今回はsshとかhttpsといった話はしません。それは出来ているという前提で進めます（そっち方面の内容も今度話したいですね。）。
ステップ1
いきなりステップとか言っちゃいましたけど、ステップ1から順番にやってみ？ という話です。
一応言っておきますが、どんどん強引な手段になっていきますので、本来はちゃんとエラーメッセージを読むべきだと思います。これちゃんと言ったからな！
というわけでステップ1です。
git push origin dev
devブランチじゃないならdevのところを今のブランチ名にしてください。
masterにいるならdevのところをmasterに変更ですね。
originは簡単に言うとリモートリポジトリにって意味です。
案外これでいけちゃうパターンが多いのではないかと思います。
ちなみにこれでいけましたって人は
git push -u origin dev
というように、最初のpushで-uをつけていないパターンが多い気がしなくもないです。
ステップ2
git pull
git push
pushする前にちゃんとpullできてんのか？ という話です。
ちょっと趣旨と違う気もしますが、意外と忘れている人いたりするんで。
pullのところはfetch+mergeでもいいと思いますが、その辺はどちらでも。
ステップ3
git push origin :dev
git push -u origin dev
はい。めっちゃ強引な手です。
最初にリモートのdevブランチを消し飛ばし、そのあとで新たにdevブランチをpushしています。あんまオススメはしません
ステップ4
push -f origin dev
はい、こっちも強引ですね。
-fすることで強制的にpushをします。リモートのdevがどこにいようともお構いなしです。
仮にリモートのdevが別のよくわかんないところにいたとしても、そいつは消し飛んでpushされます。
同じくあまりオススメはしません。
権限とか公開鍵秘密鍵の設定によってはエラーがでますし（その場合は鍵を作りなおせばいい話ですが）。
オススメはしませんが、私が一度も使ったことがないといったら完全に嘘になります。
困ったらこれっしょ！ ってやつです。
まとめ
ステップ1、2については強引じゃないですが、3、4についてはかなり強引ですので自己責任でどうぞ。
まぁ強引っちゃ強引ですが、こういうコマンドがある以上使えはするってことですから、使ってもいいんじゃないですかね。
push -f は、マジ安定感パネェっす。
以上です。