目的 rebase実行してコンフリクトした時にrebaseをなかったことにする方法をまとめる 方法 下記コマンドを実行してrebaseをなかったことにする。 $ git rebase --abort

注意点 私自身,完全に理解していないため,大雑把に手順を説明します. また,誤った解釈やより良い提案等ありましたら指摘していただけると幸いです. またあまり関係ありませんが,英語弱者の戒めとして repositoryの発音は/rɪˈpɒzɪt(ə)ri/の発音であると述べておきます (ポにアクセント) (a place where or receptacle in which things are or may be stored (Google 検索より)). 目次 0. SSHを用いて他の環境にlogin 1.鍵生成 2.公開鍵登録 3.SSH内からのログイン設定 4.既存リポジトリの権限獲得 手順1. 鍵生成 $ cd .ssh/ $ pwd ~/.ssh $ ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/Users/***/.ssh/id_rsa): kagidayo [←名前を指定する.] Enter passphrase (empty for no passphrase): [何か入力するか空] Enter same passphrase again: [上と同じ] Your identification has been saved in kagidayo. Your public key has been saved in kagidayo.pub. The key fingerprint is: *** $ ls kagidayo[秘密鍵] kagidayo.pub[公開鍵] 手順2. 公開鍵の登録 githubのサイト(Settings>SSH and GPG keys)にて公開鍵を登録する. 公開鍵の取得方法は $ cat kagidayo.pub ssh-rsa *** username@place.local としてkagidayo.pubの内容を全てコピーする. 手順3. SSH内からのログインの設定 ログインが可能かの状況確認はこちらで取れるみたいです. $ cat config Host github github.com HostName github.com IdentityFile ~/.ssh/kagidayo User git $ ssh -T github Hi "Gitの名前"! You've successfully authenticated, but GitHub does not provide shell access. しかし,その後の作業にて"*** Please tell me who you are."と怒られてしまったので, $ git config --global user.email "gitのmail" $ git config --global user.name "gitのusername" で登録しておきます. 手順4. 既存リポジトリの権限獲得 $ cd $ mkdir place_to_save (既存のリポジトリを保存する場所を作ります) $ cd place_to_save $ git init (place_to_saveをgitに接続するための準備をします) $ git pull git@github.com:"gitの名前"/"既存のdirectoryの名前" (既存のディレクトリーの内容を持ってきます) $ git remote add origin "directory_URL" (既存のディレクトリーの権限を追加します) $ git add * -f (そして初回は -f が要求されたためforceしてaddします.) $ git commit -a -m "first-commit" $ git push -u origin master (-u origin master は初回だけで大丈夫な感覚です) Username for 'https://github.com': Password for 'https://"username"@github.com': ここから先はいつも通りにadd→commit→push のようにすれば, 自学自習には問題ないと思います(汗). 参照(もっと詳しく知りたい方へ) GitHubでssh接続する手順~公開鍵・秘密鍵の生成から~ https://qiita.com/shizuma/items/2b2f873a0034839e47ce 予期せずignoreされてしまい悲しみの淵にあるファイルに手をさしのべるにはhttps://qiita.com/marutanm/items/1401e15e249e8f48b645 いまさらだけどGitを基本から分かりやすくまとめてみた https://qiita.com/gold-kou/items/7f6a3b46e2781b0dd4a0 GitHubでユーザ名・パスワード省略（push, pull） https://qiita.com/azusanakano/items/8dc1d7e384b00239d4d9

これは何？ $ git clone [巨大なリポジトリ] の実行結果が fatal: the remote end hung up unexpectedly というエラーになってしまい、クローンに失敗する場合の対処法をまとめてみました。 対処法 Step1. postBuffer の拡張 http.postbuffer の設定値が小さすぎることが原因の場合があるので、拡張します。 $ git config --global http.postbuffer 4M 4M〜16M あたりまで試して無理なら、この対処法での解決は諦めて、次のStepに移ります。 Step2. リポジトリの最新断面だけを取得する Step1だけで解決しない「巨大なリポジトリ」は、経験的には5年以上継続して追加修正の開発が行われているような歴史のある（或いは歴史は長くないがコミットされているファイルのサイズが大きい）リポジトリであることが多いように思われます。 解決方法としては、まず最初に最新の断面だけを取得し、過去のコミットログが必要であれば、徐々に遡りながら何度かに分けて取得するアプローチをとります。 リポジトリの最新断面だけを取得する。 $ git clone --depth 1 [巨大なリポジトリ] main（旧: master）ブランチ以外のブランチに関する最新断面も取得しておきたい場合は、次のコマンドです。 $ git clone --depth 1 --no-single-branch [巨大なリポジトリ] 最新断面だけ取得すれば、今後の開発が続けられるとか、最新断面だけが欲しいという用途であれば、これで完了です。 過去のコミットログをすべて取得したい場合は、次のStepです。 Step3. データ取得範囲を限定して徐々に過去のコミットログを取得する 最新断面のみをcloneした対象のリポジトリの過去のコミットログを遡及して取得するには、やりかた色々ありますが、ここでは2パターン紹介しておきます。 まずは、clone したディレクトリに移動しておきます。 $ cd [Step2.で clone した巨大なリポジトリ] 残りのコミットログをすべて取得する 残りのコミットログが一気に取得できるサイズであれば、このコマンド一発で済みますが、そもそもリポジトリ全体を git clone できなかったような巨大リポジトリなので、これを先に実行しても同様のエラーになると思います。 $ git fetch --unshallow 次の手順を一定程度繰り返した上で、残りを一気に...みたいな使い方ができる、という参考までに載せておきます。 コミット数を指定して徐々に取得する 例えば、1000コミット分ならエラーにならずに取得できるサイズだとして「更に1000コミット分の履歴を遡及して取得する」というコマンドが以下のコマンドです。 $ git fetch --deepen 1000 これをループ処理で実行するなどして、小刻みにコミットログを過去に遡及して取得していく、というアプローチです。 loop-sampl.sh while true do git fetch --deepen 1000 done 最終的にすべてのログを取得し終えて、これ以上取得するログが無くなった場合は、上記コマンドの結果が remote: Total 0 (delta 0), reused 0 (delta 0), pack-reused 0 となります。サンプルの無限ループは終了条件をサボっているので、 Ctrl + C で止めてください。 以上で、めでたしめでたし、です。 参考サイト

これは何？ $ git clone [巨大なリポジトリ] の実行結果が fatal: the remote end hung up unexpectedly というエラーになってしまい、クローンに失敗する場合の対処法をまとめてみました。 対処法 Step1. postBuffer の拡張 http.postbuffer の設定値が小さすぎることが原因の場合があるので、拡張します。 $ git config --global http.postbuffer 4M 4M〜16M あたりまで試して無理なら、この対処法での解決は諦めて、次のStepに移ります。 Step2. リポジトリの最新断面だけを取得する Step1だけで解決しない「巨大なリポジトリ」は、経験的には5年以上継続して追加修正の開発が行われているような歴史のある（或いは歴史は長くないがコミットされているファイルのサイズが大きい）リポジトリであることが多いように思われます。 解決方法としては、まず最初に最新の断面だけを取得し、過去のコミットログが必要であれば、徐々に遡りながら何度かに分けて取得するアプローチをとります。 リポジトリの最新断面だけを取得する。 $ git clone --depth 1 [巨大なリポジトリ] main（旧: master）ブランチ以外のブランチに関する最新断面も取得しておきたい場合は、次のコマンドです。 $ git clone --depth 1 --no-single-branch [巨大なリポジトリ] 最新断面だけ取得すれば、今後の開発が続けられるとか、最新断面だけが欲しいという用途であれば、これで完了です。 過去のコミットログをすべて取得したい場合は、次のStepです。 Step3. データ取得範囲を限定して徐々に過去のコミットログを取得する 最新断面のみをcloneした対象のリポジトリの過去のコミットログを遡及して取得するには、やりかた色々ありますが、ここでは2パターン紹介しておきます。 まずは、clone したディレクトリに移動しておきます。 $ cd [Step2.で clone した巨大なリポジトリ] 残りのコミットログをすべて取得する 残りのコミットログが一気に取得できるサイズであれば、このコマンド一発で済みますが、そもそもリポジトリ全体を git clone できなかったような巨大リポジトリなので、これを先に実行しても同様のエラーになると思います。 $ git fetch --unshallow 次の手順を一定程度繰り返した上で、残りを一気に...みたいな使い方ができる、という参考までに載せておきます。 コミット数を指定して徐々に取得する 例えば、1000コミット分ならエラーにならずに取得できるサイズだとして「更に1000コミット分の履歴を遡及して取得する」というコマンドが以下のコマンドです。 $ git fetch --deepen 1000 これをループ処理で実行するなどして、小刻みにコミットログを過去に遡及して取得していく、というアプローチです。 loop-sampl.sh while true do git fetch --deepen 1000 done 最終的にすべてのログを取得し終えて、これ以上取得するログが無くなった場合は、上記コマンドの結果が remote: Total 0 (delta 0), reused 0 (delta 0), pack-reused 0 となります。サンプルの無限ループは終了条件をサボっているので、 Ctrl + C で止めてください。 以上で、めでたしめでたし、です。 参考サイト