Gitでベアリポジトリにforce pushが出来ない場合 - Qiita現象 間違えたcommitをリモートリポジトリのmasterにpushしてしまい、戻そうと思ったがなぜかforce pushでエラーになってしまった。 $ git reset --hard HEAD^ $ git push -f origin master 略 ! [rejected] master -> master (non-fast-forward) error: failed to push some refs to '/hoge/foo/bar' 略
--bareじゃないレポジトリにpushする - Qiita
デフォルトでは--bareじゃないレポジトリにpushしようとすると怒られる。自分一人の開発だとがんがんpushしても問題ないケースがある。 non-bareへのpushを許すには、リモートのレポジトリ上で
git push コマンドの使い方と、主要オプションまとめ | WWWクリエイターズ
Git を使った開発で最もよく利用するコマンドの一つ「git push」。基本動作のおさらいと、よく利用するオプションをまとめました。 git push コマンドの概要 git push はリモートレポジトリのブランチ履歴を更新するための Git コマンドです。 ローカル環境にあるブランチ上で作成されたコミット履歴と関連連する参照（e.g ブランチ名、タグ）を任意のリモートレポジトリに送信することで、そのリモート上でのコミット履歴を更新できます。 下記は git push origin master を実行した際のイメージです。origin レポジトリに、ローカルのmaster ブランチを送信します。origin 上の、同名のブランチ（ここでは master ブランチ）が更新されます。 それでは、git push コマンドの具体的な使い方を見ていきます。git push は引数の特別な指定
Gitコマンドについて調べる【git push】 - Blog @kimromi
git push git pushは、ローカルリポジトリにcommitした履歴をリモートリポジトリにアップロードするものです。ここでやっと自分のコードの修正がローカルからリモートにいくので、他の開発者から自分の変更が見えるようになります。 $ git push [リモートリポジトリ] [ローカルのブランチ名]:[リモートのブランチ名] 例） $ git push ssh://git@github.com/kimromi/example.git master:master 上のコマンドは、ssh://git@github.com/kimromi/example.gitに接続し、ローカルのmasterブランチをリモートのmasterブランチにpushするというものです。ただ通常はgit cloneした時に「origin」という名前でリモートリポジトリが設定されているので、「origin」を指定
【Git】リモートからの取得とリモートへの反映で行っていること(fetch,pull,push) - Qiita
fetchはリモートの「情報」を取ってくるだけ、 pullは情報を取ってきて、さらに実データをローカルに反映する。 という理解でした。 でも、fetchで何やら情報を取得している様子なのに、その後行ったpullでは何も情報が取得されない。 ということが有ったので、fetchって一体何をしているの？ということで調べてみた。 まずはブランチについて ブランチの種類 ローカルブランチ ローカルで開発するときにcheckoutで開いてコミットしていくお馴染みのもの。 ローカルで作成したブランチは、pushすることでリモート追跡ブランチにも反映される。 リモート追跡ブランチ ローカルに保持している、クローン元リポジトリのブランチを取り込んだもの。 反映はfetchやpullコマンドを実行したタイミングであり自動取得はしないので、 いつの間にかリモートリポジトリ側と不一致になっていたということも有る。
Githubで間違えてgit push -f origin masterしてしまった時の対応 - Qiita
originがhttps://github.com/[username]/[reponame]というgithub上で管理しているリモートリポジトリだとする。 ここで誰かが間違えて、必要な変更を失ってしまうようなgit push -f origin masterをやってしまった場合の話。 8cec0cではなく1e6753の状態に戻したいが、1e6753は誰のローカルにも存在しなく、github上でもタグや名前が付けられてないのでfetchしてくることが出来ないとする。 https://github.com/[username]/[reponame]/commit/1e6753 にアクセスすれば、1e6753がどんなコミットであったか分かる。 ここでは、1e6753が255番目のMerge Pull Requestだと分かったとする。 直接、masterにpushするというような運用をしていな
続・"git push --force でなく git push --force-with-lease を使う" - valid,invalid
先日 git push --force でなく git push --force-with-lease を使う - valid,invalid ことに関して記事を書いたら思いのほかバズり、アクセス解析の棒グラフの縦軸が意味を失った。 これが「みな同じように git push --force を不安に思っていたんですね〜 いや〜よかったよかった :innocent: 」というよい話なら良かったのだが rebase の是非という第n次ソフトウェア大戦の地雷原をそれと知らずに踏み抜いた結末と後から気づいた。 改めて個人的な是非 それと自覚したうえで rebase および -f について改めて考えてみたが、やはり自分にとっては是だ。 履歴を綺麗にしたいことはよくあるし、branch の統合手段として本当に優れていると思う。ぽちぽちと merge で解消していくことはストレスだ。*1 これまでに g
Githubにpushした時に他の人がpushしたと通知される - (wat-aro)
転職して配属されたプロジェクトのリポジトリーで，僕がpushしてるのに他の人がpushしてると通知される不具合がありました． Githubの設定や.gitconfigを見てもおかしいところはなく，どうしようかと思っていたらStackOverFlowにちょうど同じ症状の質問がありました． stackoverflow.com Command + Space で spotlight を開く keychain と入力しEnterを押して Keychain Access.appを起動 左のカラムからログインとパスワードの2つの項目を選択 github.comを削除する remoteがsshからhttpsに変更されているので git remote set-url ... で登録しなおす． これで解決できました．
【Git基礎】git push origin masterのmasterはローカル/リモートどっちのこと？ - Qiita
【Git基礎】git push origin masterのmasterはローカル/リモートどっちのこと？Git git push origin master のコマンドにてmasterブランチはローカル側のやつかリモート側のやつかどっちことだかわからなかったので調査した。 はじめに結論 git push/fetch origin masterのmasterはソース元を意味している。 なので git push origin masterのmasterは ローカル側のmasterブランチを指していて、 git fetch origin masterのmasterは リモート側のmasterブランチを指している。 理屈 そもそも git pushとかgit fetchのヘルプを見ると git push/fetch [<repository> [<refspec>...]] とある つまりori
git push --force でなく git push --force-with-lease を使う - valid,invalid
前に社内チャットで流れてて初めて知った。 他人の変更を上書きするおそれのある git push --force でなく、最後に fetch したタイミング以降に他人が push していたら失敗する git push --force-with-lease を使う方が良い。 --force considered harmful; understanding git's --force-with-lease - Atlassian Developers Quipper では GitHub flow のような開発フローを採用している。 各開発者が feature branch を作成し、master / develop branch へ pull request を作る流れだ。 他人と修正箇所が重なってコンフリクトした際には rebase が必要で、 rebase 後の内容を push する際には
gitでpushと同時にデプロイする場合の注意 - Qiita
はまったのでメモ。 gitでpushと同時にデプロイする場合、以下参照。 http://qiita.com/zaburo/items/8886be1a733aaf581045#%E3%83%AA%E3%83%A2%E3%83%BC%E3%83%88%E3%83%AA%E3%83%9D%E3%82%B8%E3%83%88%E3%83%AA%E3%81%AEpost-receive%E3%82%92%E8%A8%AD%E5%AE%9A%E3%81%99%E3%82%8B 実行したいスクリプトをhoge.git/hooks/post-receiveに、実行権限付きで置けばよい。 ただ上記URLのpost-receiveスクリプトでは問題ないが、以下はうまくいかず。「fatal: Not a git repository」が出る。
【俺用メモ】gitでたまに使う程度なので忘れるコマンド - Qiita
なんでコロンで削除になるのか？ 今さら聞けないgit pushコマンド - Shoichi Matsuda's diary 「何もないものをリモートのhogeにpushする ＝ hogeの存在を何もないものにする ＝ hogeを削除」です。 すごく参考になる…。 merge済みリモートブランチをまとめて削除 コマンドをパイプで組み合わせてやります。 hogeにmerge済みのリモートブランチを表示 origin/の状態になっているのでorigin/をトリミング ブランチ名が取り出せたのでxargsに渡して削除していく 上記のコマンド群をつないで実行 1. git branch -r --merged hoge 2. sed -e 's% *origin/%%' 3. xargs -I{} git push --delete origin {} -- ↓これが4 $ git branch -
コンフリクト解消中のGitブランチを、作業途中でプッシュしたい - Qiita
「upstreamのmasterブランチをマージしようとしたら大量のコンフリクトが発生した」こと、ありませんか？ 私はよくあります 「せっせっとコンフリクトを解消してるけど、そろそろ時間切れ。このブランチ、いったんプッシュしたいなぁ」ということ、ありませんか？ 私はよくあります ですが、未処理のコンフリクトを残したままコミットしようとしても、 $ git commit error: 'commit' is not possible because you have unmerged files. hint: Fix them up in the work tree, hint: and then use 'git add/rm <file>' as hint: appropriate to mark resolution and make a commit, hint: or use 'g
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
How to push only one commit with Git | Dennis Robinson
Git push up to a certain commit (Example)
How can I push a specific commit to a remote, and not previous commits?
GitHub - t-cool/t-cool.github.io: t-cool のレポジトリ一覧です。
Learn Branching with Bitbucket Cloud | Atlassian Git Tutorial
git push -f したブランチに同期する方法 (git pull -f は存在しない) - Qiita
git pushes with wrong user from terminal