gitでremoteのコミットをなかったことにしたい
今日会社で困ったのでメモ 目的 remoteのコミットをなかったことにしたい 参考にしたのはこちら Gitでリモートリポジトリを巻き戻す - @tmtms のメモ 基本的に内容は同じ。 シチュエーション 大幅修正 commit commit push やっぱ大幅修正前に戻したい コミットもなかったことにしたい シナリオ ローカルでreset --hard remoteのbranch消す ローカルの状態をpush 方法 取りあえずremoteはoriginでbranchはmasterということで。 branchのバックアップを取る % git push origin master:master_bak ローカルのcommitをなかったことにする % git reset --hard xxxxxxxxxxxx gitのremote branchを削除 % git push origin :ma
gitで外部moduleを扱う方法(subtree) - Qiita
概要 例えば、webページを作っている「project A」「project B」があるとします。 全く別のプロジェクトですがCSSだけは同じものを使いたい。 どんどんアップデートしてCSSを充実させたい。 そして新しく「project C」を作るときもこのCSSを使いたい。 これを叶える仕組みがgitには標準で備わっています。 「subtree」という仕組みです。 上記の図の様にgitで管理している「project A」の中でまた別のgitリポジトリ「CSS」も管理しています。 「CSS」に機能を追加してCSSリポジトリにPUSHしたら「project B」でも機能追加したCSSを使うことができます。 もちろん逆も可能です。 参考サイト git subtreeの練習 - Weblog - Hail2u.net git subtree使ってみた - Qiita 上記のサイトにも書いてあるん
MacでSSH公開鍵・秘密鍵ファイルをコピーして使ったら警告がでた - アインシュタインの電話番号
Mac OS Xの再インストール後、元々使っていたSSH公開鍵・秘密鍵ファイルの入った.sshフォルダを、ホームディレクトリにコピペして、git pushしようとしたら警告が出て実行できなかった。コピペしただけでは、秘密鍵の方のファイルパーミッションがオープンすぎるからダメみたい。 こんな警告が出た git pushしようとしたら、こんな警告が出た。 $ git push origin master @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Permissions 0644 for '/Users/ruedap
リモートのgitブランチをローカルにチェックアウトする - setoya-blog
まずは、リモートにどんなブランチがあるかを確かめる。-aオプションでリモートブランチも一覧できる。 > git branch -a * master remotes/origin/master remotes/origin/other_branch チェックアウトしたいブランチが表示されていない時は、git fetchとかすると情報をリポジトリから取得できる。 > git fetch 次に、ローカルブランチ名を指定して、リモートブランチをチェックアウトする > git checkout -b other_branch origin/other_branch 最初の引数がローカルブランチ名 -bオプションを指定しておくと、自動的にそのブランチに切り替わる。 -bオプションを指定しないと、以下を再度する必要がある。 git checkout -b other_branch
UNIXコマンドメモ：ファイル内容をクリップボードに - Qiita
参考：http://macwiki.sourceforge.jp/wiki/index.php/OSX%E3%81%AE%E5%9B%BA%E6%9C%89%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89#pbcopy.2C_pbpaste_.E2.80.A6_.E3.82.B3.E3.83.94.E3.83.BC.E3.81.A8.E3.83.9A.E3.83.BC.E3.82.B9.E3.83.88.E3.82.92.E3.82.B3.E3.83.9E.E3.83.B3.E3.83.89.E3.81.8B.E3.82.89 自分はQiitaに投稿する際プロジェクトのファイルの中身をそのままごっそり記事に貼付けることが結構あるのですが、その度に cat [filename]で中身を表示。 出力された内容をマウスで範囲選択してから"Cmd+C"でコピー。 投稿用のテ
Vagrant環境で作ってるものをBitbucketにgit pushするまで - Qiita
git remote add origin git@bitbucket.org:[your-account]/[your-project].git ここで以下のような警告（？）が出る。 The authenticity of host 'bitbucket.org (123.456.78.901)' can't be established. RSA key fingerprint is *********************************** Are you sure you want to continue connecting (yes/no)? で、これにyesと答えても以下のような感じで結局失敗する。 Warning: Permanently added 'bitbucket.org,123.456.78.901' (RSA) to the list of know
SSH認証キーをBitbucket/GitHubに設定しよう！ [Mac簡単手順]
BitbucketやGitHubのGitリポジトリにアクセスではSSH認証キーを使うことができます。このSSH認証キーを使ったアクセスのメリットは次のとおりです。 * Pushするときにいちいちパスワードを打つ必要がなくなる * セキュリティが向上する 今回はMacでSSH認証のための公開鍵と秘密鍵を生成して、GitHubやBitbucketに公開鍵を登録して、SSHでアクセスできるようにするまでの設定手順をできるだけわかりやすく書いていきます。もし、詰まった点とかあればコメントお願いします！ (04/11 22:30) 前回の修正でミスってた部分を修正 🐯 流れSSH認証キーの設定の流れは次のとおりです。 (1) SSH認証の公開鍵と秘密鍵を作成 (2) Mac側(クライアント側)へのSSHキーの設定 (3) Bitbucketへの公開鍵の登録 (4) GitHubへの公開鍵の登録
![SSH認証キーをBitbucket/GitHubに設定しよう！ [Mac簡単手順]](https://cdn-ak-scissors.b.st-hatena.com/image/square/c2ea7e72d0d7f3ba6c237909f321e67ffbdaa24e/height=288;version=1;width=512/https%3A%2F%2Fmorizyun.github.io%2Fimg%2Fog_image.png)
黒い画面とかよくわからない人のための、ゆるふわgit入門
リポジトリとは？ 更新履歴をためておく場所です。 gitでは、リポジトリには2種類あります。 「自分の作業用リポジトリ」と 「公開用リポジトリ」です。 今日は、 hetemlサーバ＝自分の作業用リポジトリ github＝公開用リポジトリ として話をします。 githubとは？ gitで管理した更新履歴を置いておく場所。 完成したものを見せるんじゃなく、 開発途中の履歴を見せる。 普段見えない裏側のソースコードも見える。 履歴をちょこちょこ送れるので、開発してる！感が出せるのでエンジニアに人気。 人のソースコードに手を入れて送ったりもできるらしい。 別にプログラムじゃなくてもいろんな更新履歴を管理してよい。 でも交換日記とかを管理するのはやめましょう。 流れ 必要なものを用意 hetemlでSSHを設定し、Poderosaでhetemlに接続し、鍵をつくる 鍵をgithubに登録しよう 登録
俺のオレオレgit-flow | おそらくはそれさえも平凡な日々
背景 一昨年末くらいにgit-flowを採用していた 良いんだけど、結構めんどくさいなーと思うところがあった 去年頭の新規開発からはgithub-flowを採用(と言うかごく普通のGit運用) masterのテスト通ったらjenkinsさんが開発サーバー反映してくれて捗る ただ本番をそれで運用するわけにもいかない リリースタイミングとかある masterはデザイナーやME(=gitに不慣れな人たち)がカジュアルに画像やテンプレをpushできる(それで構わない) git-flowとgithub-flowの中間くらいのフローで運用することに git-flowの気に入ってる点とそうじゃない点 気に入っている点 並列ブランチを走らせるというのは良い(git-flowの場合、masterとdevelop) hotfixが便利 めんどくさい所 releaseブランチ毎回作る必要性をあまり感じない バー
Git のリモートリポジトリを Dropbox 上に作成して共有する
まずは、Dropbox上にリポジトリ置き場を作ります。今回は git-repos という名前のディレクトリ内にまとめておくことに。 cd ~/Dropbox mkdir git-repos git-repos ディレクトリ内で myproject という名前のベアリポジトリを作ります。 cd git-repos git init --bare myproject.git ローカルの作業ディレクトリに移動し、さきほど作ったリポジトリを dropbox という名前でリモートリポジトリとして追加設定します。この名前は短めに db でも、origin でもなんでもOK。 git remote add dropbox ~/Dropbox/git-repos/myproject.git リモートリポジトリがちゃんと追加されたかどうかは以下のコマンドで確認！ git remote -v dropbox
いい感じの.gitignoreファイルをらくらく作成する - ppworks.jp
.gitignore、プロジェクトごとにいい感じのものテンプレートあると便利ですよね。 そういうテンプレートがまさに、github/gitignore にあるのですが、そのテンプレートをコマンドラインから持ってくるgemがgemignoreである、とのこと。 install gem install gemignore # もしくは # rbenv exec gem install gemignore # とか 使い方 .gitignoreがなければ作ります touch .gitignore 対応しているプロジェクトを見てみる gemignore list 検索してみる gemignore search obj 試しに、Objective-Cを入れましょう gemignore a Objective-C cat .gitignore # Added by gemignore. Snippet
gitで一括削除コミットを行う方法 - h7kayamaの日記
2013-01-14 gitで一括削除コミットを行う方法 git gitは、リポジトリのファイルを削除するためには削除用のコミットをする必要がある。 このおかけで、Herokuへデプロイして動かしたときに消したはずのファイルが残っていたせいでかなりハマった。 SVNだと削除したファイルを検知して、新規・変更・削除を意識せずコミットができていたが、gitでは削除したファイルを指定してコミットする必要があり、ちょいとめんどくさい。 しかも、gitには削除したファイルを一括でコミットするコマンドが用意されていない。そこで、一括で複数のファイルを削除コミットするコマンド。 $ git status | grep deleted: | awk {print $3} | xargs git rm 【2013/1/17 追記】 削除したファイルを一括でコミットするコマンドはありました。 以下のとおりです
git rebaseとgit mergeはともだち こわくないよ - Pixel Pedals of Tomakomai
例えば、以下のようなコミット履歴があるとします。 A---B---C---D masterここで git rebase -i HEAD~3 をして、 コミットB を E に書き換えたくなったとします。このとき、rebase -i によって履歴を書き換えてしまうと、以下のようにリポジトリからB〜Dのコミットは消滅してしまうと思っている人も居るのではないでしょうか。 A---E---C'---D' master確かに、Gitがこのような動作をするのであれば、rebase後に元の状態へ戻すことは到底困難であるように見えます。しかし、正確に書けば、実際のレポジトリの状態は以下のようになります。 E---C'---D' master / A---B---C---D実はコミットA〜Dの一連のコミットは手つかずで残っており、「master」というラベル*1が新たな枝に付け替えられただけなのです。よって、
git-mergeで--ff(デフォルト)と--no-ffと--squashの違い - u1tnkの日記
きっかけ A successful Git branching model » nvie.com ここらあたりを見て、--no-ffつけときゃいいんだなーと深く考えずに使ってたら、--squashつけると安全とかなんとかチラ聞きして混乱しまくったので調べてみた。 とりあえずman。 man git-merge ... --ff, --no-ff Do not generate a merge commit if the merge resolved as a fast-forward, only update the branch pointer. This is the default behavior of git-merge. With --no-ff Generate a merge commit even if the merge resolved as a fast-forwa
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
cannot push into git repository
bayashi.net
GithubのWeb開発用エディタ「Atom」が、いつの間にか進化し過ぎている件！ | シェアしたくなる最新のWebサービス・ITニュース情報をチェック！ APPGIGA!!（アプギガ）
Welcome to Firebase Hosting
はじめてのgitレビューを読んでinstallしたけど使っていないgitの使い方を学ぶ - [51] I’d checked it.-はてダ
git rmでまとめてファイルを削除する方法 | 代打、俺