Gitまとめ チェックアウト 今いるコミットを移動する。 ブランチを移動するときにも使う。 git checkout コミットID 今時分がいるブランチは「*」をつけて表す。 フォーク・クローン フォーク 他の人が公開しているリモートリポジトリを、自分のアカウントにコピーすること。 クローン リモートリポジトリを自分のPC（ローカル）にダウンロードすること。 git clone リモートリポジトリのURL ※ただし実際の開発現場では、フォークせずに１つのリモートリポジトリを複数人が直接クローンして作業することが多い。不用意にリポジトリが分散するのを防ぐため。 マージ ブランチを取り込むこと。 マージはコミットで表される。 # ブランチＡにブランチＢを取り込む git checkout ブランチA # マージコミットを作りたいブランチに移動 git merge ブランチB push ローカルリポジトリで起きた変更をリモートリポジトリに反映する。 git push リモートリポジトリ名 ブランチ名 pull リモートリポジトリで起きた変更を、ローカルリポジトリに反映する git checkout プルしてきたいブランチ git pull リモートリポジトリ名 ブランチ名 revert 過去のコミットを打ち消す。 コミット自体を削除するわけではなく、あくまで反対の内容で新規コミットを作ることで過去の変更を打ち消す。 あいだに別のコミットが存在しても、rebertは可能。 git revert コミットID rebase 履歴を一直線にする。 mergeとrebaseの違い merge：過去のコミットは改変されずに、マージするためだけの新しいコミットが作成される rebase：もともとのコミットが改変されてリベース先のブランチに乗っかり、履歴が一直線になる。 ※ rebaseは履歴を改変する。コミットを新しく作り直すため、rebase前後でコミットIDがかわってしまう。 リモートリポジトリ上に存在しているブランチをrebaseしてしまうと、普通の方法ではpushできなくなる。 git checkout リベースしたいブランチ git rebase リベース先のブランチ リモート追跡ブランチ リモートブランチとローカルブランチの間にある。 ローカルリポジトリ内にあり、リモートブランチをローカルにコピーしただけのもの。 読み取り専用。 fetch リモートリポジトリから最新の状態を取得し、ローカルリポジトリ内のリモート追跡ブランチを更新する。 リモートリポジトリの状況は知りたいけど、まだローカルブランチに反映させたく内場合などに使用。 fetchしただけだと、リモート追跡ブランチ（origin/◯◯）にコミットがダウンロードされただけで、ローカルブランチは更新されていない。 ローカルブランチに反映させたくなったら、リモート追跡ブランチをmergeする。 git checkout main git featch git merge origin/main prune リモートリポジトリで既に削除されたブランチを、ローカルリポジトリでも削除する。 git branch -a # リモート追跡ブランチを含めたすべてのブランチを確認する git fetch --prune # リモートリポジトリで消えた追跡ブランチを消去する git branch -d ブランチ名 最新のコミットメッセージを修正する コミットメッセージをタイポなどしてしまった場合は、amendを使う。 push前なら修正できる。 git commit --amend # viが立ち上がり、直近のコミットメッセージを修正できる。 別ブランチから特定のコミットのみ取り込む（チェリーピック） Ａブランチにコミットするはずが、間違えてＢブランチにコミットしてしまった場合などに使用。 任意のコミットを、今いるブランチ上にコピーしてこれる。 git cherry-pick コミットID # 今いるブランチにコミットをコピー ※ あくまで特定のコミットを今いるブランチにコピーしてくるだけ。元のコミットは残ったまま。 元のコミットを削除するには 間違えて作成した元のコミットを打ち消したい場合はrevertを使う。 コミットに目印をつける（タグ） タグを使うと、履歴上の重要なポイントに目印をつけることができる。 - アプリ開発で、リリースしたときにバージョン番号のタグを付ける - 受託開発で、納品したときに日付のタグを付ける - Web開発で、リニューアルオープンしたときにタグを付ける # 新規タグを作る git tag タグ名 # タグをリモートリポジトリに共有する git push origin タグ名 # ローカルリポジトリのタグを削除する git tag -d タグ名 # リモートリポジトリのタグを削除する git push origin --delete タグ名 間違えてHEADに直接コミットしてしまったら detached HEAD状態 どのブランチにも所属しない無所属状態のコミット。 過去のコミットにチェックアウトし、そのまま新しくコミットを作成した場合などに起こる。 そのままコミットを積み重ねることもできるが、次にチェックアウトしたときに目印がないため戻ってこれなくなる。 通常時はHEADはブランチを指す detachd HEAD状態は、HEADが直接コミットを指してしまっている状態 HEADが分離した状態でコミットをしてみると 一見ちゃんとコミットできているように見えるが、masterブランチにチェックアウトしてみると コミットDがなくなってしまう。 対処法 HEADに直接コミットし、detaced HEAD状態になっていることに気付いたら、慌てずそこから新規ブランチを作る。 git checkout -b ブランチ名

はじめに みなさん！プログラムファイルの管理はしっかりできていますか？ 今回は初心者がついついGitでやらかしがちな3つのケースに焦点を当てて話していきたいと思います。 ※ Gitの基本的概念や使い方に関しては別の記事を見てください。 ケース1.　「間違えてaddしてしまった」 本来addする予定のないファイルを間違えて勢いでaddしてしまった！やばい！ってなったことありませんか？ そんな時は、、、 $ git reset ファイル名 上記のコマンドを叩くことでステージングエリアに追加された特定のファイルを取り消すことができます。 また全てのファイルを取り消したい時は、、、 $ git reset 上記のコマンドを叩くことでステージングエリアに追加された全てのファイルを取り消すことができます。 ケース2.　「間違えてcommitしてしまった」 無事addし、commitした直後に実はいらないファイルも混ぜてしまってた！やばい！ってなったことありませんか？ そんな時は、、、 $ git reset --soft HEAD^ 上記のコマンドを叩くことで直前のcommitを取り消すことができます。 しかし、この--softってなんじゃって思いませんか？ 思った方は勘が鋭いですね！ 実は他にも種類があります。 それらについてまとめたものを以下の表で示します。 オプション 意味 --soft commitを取り消した後もインデックスと作業ツリーの状態はそのままである --mixed(デフォルト) commitを取り消した後作業ツリーの状態はそのままであるが、インデックスの状態は実行前の状態に戻る --hard commitを取り消した後インデックスと作業ツリーの状態までも実行前の状態に戻る 簡単にいうと --softは作業ツリーの修正をしたい時 --hardは1つ前のcommitの状態に戻りたい時 に用います。 ※ --hardは変更内容が全て無くなるので注意して用いてください。 ケース3.　「間違えてpushしてしまった」 無事add, commitし、勢いよくpushしたが実はブランチを間違えてしまってた、中途半端なcommitだった！やばい！ってなったことありませんか？ そんな時は、、、 $ git reset --hard HEAD^ 　 // 直前のcommitの取り消し $ git push -f origin ブランチ名 　// 強制push 上記のコマンドを叩くことで誰にもバレずにpushを取り消すことができます。 しかし、チーム開発には向いていません。 なぜなら、仮に自分以外のメンバーがローカル環境にローカル環境にpullし別の開発を始めていたら不整合が生じて今後pullができなくなります。 ではどうするか、、、 $ git revert 　 　　　　　　// 直前のcommitを打ち消すcommit $ git push origin ブランチ名 上記のコマンドを叩くことで間違えてpushしたcommitを残しつつ、取り消しを意味する新しくcommitを作成しpushを取り消すことができます。 おわりに add, commit, pushとGitの流れに沿ってやらかしそうなところをピックアップしてみました。 本記事でおっちょこちょいさんを少しでも助けれたらなと思います。 それでは！よいGitライフを〜！

はじめに みなさん！プログラムファイルの管理はしっかりできていますか？ 今回は初心者がついついGitでやらかしがちな3つのケースに焦点を当てて話していきたいと思います。 ※ Gitの基本的概念や使い方に関しては別の記事を見てください。 ケース1.　「間違えてaddしてしまった」 本来addする予定のないファイルを間違えて勢いでaddしてしまった！やばい！ってなったことありませんか？ そんな時は、、、 $ git reset ファイル名 上記のコマンドを叩くことでステージングエリアに追加された特定のファイルを取り消すことができます。 また全てのファイルを取り消したい時は、、、 $ git reset 上記のコマンドを叩くことでステージングエリアに追加された全てのファイルを取り消すことができます。 ケース2.　「間違えてcommitしてしまった」 無事addし、commitした直後に実はいらないファイルも混ぜてしまってた！やばい！ってなったことありませんか？ そんな時は、、、 $ git reset --soft HEAD^ 上記のコマンドを叩くことで直前のcommitを取り消すことができます。 しかし、この--softってなんじゃって思いませんか？ 思った方は勘が鋭いですね！ 実は他にも種類があります。 それらについてまとめたものを以下の表で示します。 オプション 意味 --soft commitを取り消した後もインデックスと作業ツリーの状態はそのままである --mixed(デフォルト) commitを取り消した後作業ツリーの状態はそのままであるが、インデックスの状態は実行前の状態に戻る --hard commitを取り消した後インデックスと作業ツリーの状態までも実行前の状態に戻る 簡単にいうと --softは作業ツリーの修正をしたい時 --hardは1つ前のcommitの状態に戻りたい時 に用います。 ※ --hardは変更内容が全て無くなるので注意して用いてください。 ケース3.　「間違えてpushしてしまった」 無事add, commitし、勢いよくpushしたが実はブランチを間違えてしまってた、中途半端なcommitだった！やばい！ってなったことありませんか？ そんな時は、、、 $ git reset --hard HEAD^ 　 // 直前のcommitの取り消し $ git push -f origin ブランチ名 　// 強制push 上記のコマンドを叩くことで誰にもバレずにpushを取り消すことができます。 しかし、チーム開発には向いていません。 なぜなら、仮に自分以外のメンバーがローカル環境にローカル環境にpullし別の開発を始めていたら不整合が生じて今後pullができなくなります。 ではどうするか、、、 $ git revert 　 　　　　　　// 直前のcommitを打ち消すcommit $ git push origin ブランチ名 上記のコマンドを叩くことで間違えてpushしたcommitを残しつつ、取り消しを意味する新しくcommitを作成しpushを取り消すことができます。 おわりに add, commit, pushとGitの流れに沿ってやらかしそうなところをピックアップしてみました。 本記事でおっちょこちょいさんを少しでも助けれたらなと思います。 それでは！よいGitライフを〜！

git resetは基本使わない 間違えてgit pullしちゃったけどやっぱり取り消したいとき、 調べるとgit reset --hardをすればいいよ！という記事をよく見かけた。 基本的にgit reset --hardは（複数人での開発のときは特に） ログが変わってしまうため使わないほうが良い。 git revertを使おう git revertは取り消したいコミットを打ち消すコミットを作成するので コミットを消したログもちゃんと残せる。 参考

はじめに 変更履歴を保存せずにWordファイルに内容を上書きするのは危険である。 内容を消した状態で保存すると元に戻せない。Wordファイル自体を消してしまうと元に戻せない。 あまり望ましくない対策 Wordの校閲ツールで変更履歴を保存 共同編集する校閲ツールとしては非常に優れているが、いくつか欠点がある。 (おそらく)複数回前の履歴一覧を見ることができない。 Wordファイル自体を消してしまうと元に戻せない。 図表番号が反映されないバグがある。 バージョンごとに新しいファイル名で保存する。 卒論_1章_ver1.docx、卒論_1章_ver2.docx、...みたいな感じ 保存する手間がかかる。容量がひっ迫される(Dropbox等の保存容量が制限されているクラウドストレージを用いている場合は困る)。 非常に細かい変更履歴管理をしづらい(ファイル数が増えるため) 何を変更したのかメモできない。.txtファイル等で別途管理する必要がある。 Google Driveの変更履歴を利用 ファイルごとの管理はできるがフォルダごとの管理はできない(はず) 測定データを含むフォルダ全体を巻き戻したい場合、ファイル一個一個につき処理を行う必要がある。 今回紹介する方法 GitHubデスクトップというアプリで変更履歴管理を行う。 変更履歴はgitで管理 GitHubでオンライン上に変更履歴を保存する。PCが壊れた時の対策。 共同編集は校閲ツールで行う 変更前のファイルと変更を加えるファイルを用意(ファイルは2個で済む)。 両方とも変更履歴を停止する。 変更内容の組み込み機能を用いて変更内容を反映。 環境構築 GitHubアカウントの作成 アカウント作成を参考に行う。 GitHubデスクトップのインストール・設定 インストール方法を参考にインストールを行う。 GitHubデスクトップを起動し、認証方法を参考にGitHubアカウントへのログインを行う。 変更履歴を管理するフォルダの指定 リポジトリの作成の新しいリポジトリの作成を行う(チュートリアルリポジトリの作成とクローンではない)。Local Pathは変更履歴を管理したい卒論の入っているフォルダを指定する。 リポジトリのアップロードのパート4: リポジトリを GitHub に公開するを参考にして、先ほど作ったリポジトリをGitHub上にアップロードする。 Keep this code privateにチェックがついていることを確認する。ついている限りほかの人から見られることはない。 Wordの変更履歴を見れるようにする設定 設定を参考にtikaとJavaのインストールを行う。 変更履歴記録の流れ 添削してもらったWordファイルをコピーしてファイル名_base.docx、ファイル名.docxの二つのファイルを作る。 編集するのはファイル名.docxである。 Git側 Wordである程度変更を加える。 GitHubデスクトップを開く Summaryをクリックして今回の変更内容を簡潔に述べる。 Changes内の任意のファイルをクリックすると変更内容が表示される。 Historyで過去の変更履歴を見れる。 Commit to masterで変更内容をPCのリポジトリに保存。 定期的に中央上のPush originでGitHub上に変更履歴をアップロード。 Repository>View on GitHubで実際にアップロードされていることを確認できる。 提出できる状態になるまで以上の流れを繰り返す。」 Word側 提出できる状態になったら、Wordの校閲ツールの中からファイルを比較を選び、ファイル名_base.docx、ファイル名.docxを比較する。 これによって変更内容がWordの校閲ツールに反映されたため、提出する。 詳細(おまけ) gitでできること 変更履歴をCommitの形で管理 変更内容をChanges上で見やすい形で見ることができる 初版からすべての変更履歴を簡単にHistoryからみることができる。 Revert Commitで変更履歴の巻き戻しが可能。 Branchで複数の方向の変更を行う場合でも対応可能。 Mergeで複数人、複数の方向の変更をまとめることが可能。

Gitでsetsockopt IPV6_TCLASS 8: Operation not permitted:の表示を消す。 開発環境 Ubuntu 18.04 LTS, WSL 1, Git 2.17.1 問題 git pullをした際に以下の表示が出る。 $ git pull setsockopt IPV6_TCLASS 8: Operation not permitted: こちらの記事において同様な表示が出ていることが確認された。Gitのバージョンをアップデートすることにより解決されていたのでアップデートを行う。(アップデート手順はこちらを参照した。) $ git version git version 2.17.1 $ sudo add-apt-repository ppa:git-core/ppa The most current stable version of Git for Ubuntu. For release candidates, go to https://launchpad.net/~git-core/+archive/candidate . More info: https://launchpad.net/~git-core/+archive/ubuntu/ppa Press [ENTER] to continue or Ctrl-c to cancel adding it. Get:1 https://dlm.mariadb.com/repo/mariadb-server/10.4/repo/ubuntu bionic InRelease [6265 B] Get:2 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB] Get:5 http://ppa.launchpad.net/git-core/ppa/ubuntu bionic InRelease [20.8 kB] Get:6 https://dbeaver.io/debs/dbeaver-ce InRelease [2086 B] Hit:7 http://archive.ubuntu.com/ubuntu bionic InRelease Get:8 http://archive.ubuntu.com/ubuntu bionic-updates InRelease [88.7 kB] Get:3 https://downloads.mariadb.com/MaxScale/6.2.0/apt bionic InRelease [6385 B] Get:9 http://archive.ubuntu.com/ubuntu bionic-backports InRelease [74.6 kB] Get:4 https://downloads.mariadb.com/Tools/ubuntu bionic InRelease [2165 B] Get:10 https://dbeaver.io/debs/dbeaver-ce Packages [458 B] Get:11 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages [1958 kB] Get:12 http://ppa.launchpad.net/git-core/ppa/ubuntu bionic/main amd64 Packages [4188 B] Get:13 http://ppa.launchpad.net/git-core/ppa/ubuntu bionic/main Translation-en [2252 B] Get:14 https://downloads.mariadb.com/MaxScale/6.2.0/apt bionic/main amd64 Packages [1397 B] Get:15 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages [2303 kB] Get:16 https://downloads.mariadb.com/Tools/ubuntu bionic/main amd64 Packages [2742 B] Get:17 http://security.ubuntu.com/ubuntu bionic-security/universe amd64 Packages [1150 kB] Get:18 http://archive.ubuntu.com/ubuntu bionic-updates/universe amd64 Packages [1767 kB] Get:19 http://security.ubuntu.com/ubuntu bionic-security/universe Translation-en [264 kB] Get:20 http://archive.ubuntu.com/ubuntu bionic-updates/universe Translation-en [381 kB] Fetched 8124 kB in 43s (187 kB/s) Reading package lists... Done $ sudo apt update Get:1 https://dlm.mariadb.com/repo/mariadb-server/10.4/repo/ubuntu bionic InRelease [6265 B] Hit:4 http://ppa.launchpad.net/git-core/ppa/ubuntu bionic InRelease Hit:5 http://security.ubuntu.com/ubuntu bionic-security InRelease Hit:6 http://archive.ubuntu.com/ubuntu bionic InRelease Hit:7 https://dbeaver.io/debs/dbeaver-ce InRelease Hit:8 http://archive.ubuntu.com/ubuntu bionic-updates InRelease Hit:9 http://archive.ubuntu.com/ubuntu bionic-backports InRelease Hit:2 https://downloads.mariadb.com/MaxScale/6.2.0/apt bionic InRelease Hit:3 https://downloads.mariadb.com/Tools/ubuntu bionic InRelease Fetched 6265 B in 14s (432 B/s) Reading package lists... Done Building dependency tree Reading state information... Done 11 packages can be upgraded. Run 'apt list --upgradable' to see them. $ sudo apt install git Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: git-man libpcre2-8-0 Suggested packages: git-daemon-run | git-daemon-sysvinit git-doc git-email git-gui gitk gitweb git-cvs git-mediawiki git-svn The following NEW packages will be installed: libpcre2-8-0 The following packages will be upgraded: git git-man 2 upgraded, 1 newly installed, 0 to remove and 9 not upgraded. Need to get 7790 kB of archives. After this operation, 6681 kB of additional disk space will be used. Do you want to continue? [Y/n] y Get:1 http://ppa.launchpad.net/git-core/ppa/ubuntu bionic/main amd64 git amd64 1:2.34.1-0ppa1~ubuntu18.Preparing to unpack .../libpcre2-8-0_10.31-2_amd64.deb ...Unpacking libpcre2-8-0:amd64 (10.31-2) ...Setting up git-man (1:2.34.1-0ppa1~ubuntu18.04.1) ...Setting up libpcre2-8-0:amd64 (10.31-2) ... Setting up git (1:2.34.1-0ppa1~ubuntu18.04.1) ... Processing triggers for man-db (2.8.3-2ubuntu0.1) ... Processing triggers for libc-bin (2.27-3ubuntu1.4) ... $ git version git version 2.34.1 結果、変わらず。 $ git pull setsockopt IPV6_TCLASS 8: Operation not permitted: Already up to date. 調べていると、こちらの記事を見つけたので試してみる。 $ cd ~/.ssh $ touch config $ sudo vi config $ cat config AddressFamily inet setsockopt IPV6_TCLASS 8: Operation not permitted:が消えたか確認してみる。 $ git pull Already up to date. 表示されなくなりました。 まとめ 今回の解決方法は単にIPV4のみ接続するように変更しただけなので、IPV6の操作が許可されていないという根本的解決には至っていないのですが、とりあえずこのままにしておきます。(configの設定の参考：sshdで「IPv4」「IPv6」のどちらかのプロトコルのみ接続させる方法) 参考 ・bitbucket ssh error setsockopt IPV6_TCLASS 8 Operation ・Ubuntu で git のバージョンを最新版にする ・WSLではじめてgitつかうとダメだった ・sshdで「IPv4」「IPv6」のどちらかのプロトコルのみ接続させる方法

ターミナル上 git clone https://{ユーザー名}:{トークン}@github.com/{ユーザー名}/{リポジトリ名}.git ※gitのパスワードではなくトークンなのでお間違いなく。

エラー内容 Cloning into 'private-repository'... remote: Support for password authentication was removed on August 13, 2021. Please use a personal access token instead. remote: Please see https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/ for more information. パスワード認証のサポートが2021年8月13日に終わったので、代わりにアクセストークンを仕様してくださいという内容でした。 パスワードをアクセストークに変更して再度挑戦 git clone https://{ユーザー名}:{トークン}@github.com/{ユーザー名}/{リポジトリ名}.git このようにパスワードからアクセストークンへ仕様が変わったので、アクセストークンをどこかにメモしておくといいかもです。

タイトルの通り、Git リポジトリにアクティブな変更が多いため、 Git 機能の一部のみが有効になります。という アラートが表示されてしまった時の解決策を記載いたします。 環境 -> % sw_vers ProductName: macOS ProductVersion: 12.0.1 BuildVersion: 21A559 対処法 ユーザーディレクトリ配下に.gitのディレクトリが誤って生成されてしまっていたことが原因でした… 本来.gitディレクトリは各プロジェクトのディレクトリ配下に作成されているのですが、 誤ってユーザーディレクトリ配下に作成されてしまった結果、大量の差分ファイルが出てしまっていました。 Finder → ユーザーディレクトリ を確認し、.gitのディレクトリを削除すれば解決します! (隠しフォルダは shift ＋　command ＋.　で表示できます)

Goal AWS CodeCommitで複数のAWSアカウントにあるAWS CodeCommitリポジトリを適宜切り替えて使用する際の手順を示します。 Authoring Guidelines 後日、修正する予定です。 References 本文の手順は、次の文書を参考に作成しました。 "I need to access CodeCommit repositories in multiple Amazon Web Services accounts with SSH credentials". Amazon Web Services, Inc. Retrieved 29 November 2021. Pre-Requisites 本文の手順は、次の環境で実施、検証しました。 Windows 10, build 19043.1348 How To 以下の場所にあるSSHのコンフィグレーションファイルを任意のエディタで編集します。 Linux, macOS - ~/.ssh/config Windows - %USERPROFILE%.ssh\config コンフィグレーションファイルに書き込む内容は、次の通りです。 Host codecommit-1 Hostname git-codecommit.ap-northeast-1.amazonaws.com # 1つ目のAWSアカウントで実際の接続に使用するホスト名 User xxxxxxxxxxxxxxxxxxxxx # 1つ目のAWSアカウント用のSSHキーID IdentityFile ~/.ssh/codecommit_rsa_1 # 1つ目のAWSアカウント用のSSH秘密鍵へのパス Host codecommit-2 Hostname git-codecommit.ap-northeast-1.amazonaws.com # 2つ目のAWSアカウントで実際の接続に使用するホスト名 User xxxxxxxxxxxxxxxxxxxxx # 2つ目のAWSアカウント用のSSHキーID IdentityFile ~/.ssh/codecommit_2_rsa # 2つ目のAWSアカウント用のSSH秘密鍵へのパス Gitコマンド発行時に、これまで指定していたホスト名部分をコンフィグレーションファイルに記載した "Host" の値で指定します。 REM これまでの書き方 git clone ssh://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/%REPOSITORY_NAME% REM これからの書き方 git clone ssh://codecommit-1/v1/repos/%REPOSITORY_NAME%

Goal AWS CodeCommitに既にあるGitリポジトリを古いAWSアカウントから新しいAWSアカウントへ移行する際の手順を示します。 Authoring Guidelines AWS CodeCommitに限らず、GitHubからAWS CodeCommitへの移行、GitHubからGitHubへの移行でも、読み替えによって手順の大筋が把握できるようにAWS Management ConsoleとGitコマンドでの手順で主な流れを記載します。 自動化のため、将来的にAWS CodeCommitのAPIをコールするAWS CLIによる手順も追記する予定です。 References 本文の手順は、次の文書を参考に作成しました。 "Migrate a Git repository to AWS CodeCommit". Amazon Web Services, Inc. Retrieved 29 November 2021. "How to Rename the master branch to main in Git". Tower. Retrieved 29 November 2021. Pre-Requisites 本文の手順は、次の環境で実施、検証しました。 Windows 10, build 19043.1348 How To 新しいリポジトリを作成する 次の任意の手段で、新しいリポジトリを作成します。 AWS Management Console AWS CLI AWS CloudFormation 古いリポジトリの内容を新しいリポジトリへ反映する [!IMPORTANT] この手順では、一度もコミットされていない新しいリポジトリへ古いリポジトリの内容を移行します。既に何らかのコミットがなされている新しいリポジトリへ古いリポジトリの内容を増分移行する手順ではありません。 古いリポジトリのベアリポジトリをローカルに作成し、古いリポジトリの内容を新しいリポジトリへ反映します。 git clone --mirror %OLD_REPOSITORY_PATH% CD %OLD_REPOSITORY_NAME%.git git push %NEW_REPOSITORY_PATH% --all git push %NEW_REPOSITORY_PATH% --tags [!IMPORTANT] git push --all だけではタグが反映されないため、別途 git push --tags を実行する必要があります。 成功したら、ローカルに作成した古いリポジトリのベアリポジトリを削除します。 CD .. RD /S %OLD_REPOSITORY_NAME%.git 新しいリポジトリのデフォルトブランチ名を変更する BLM後の世界情勢に合わせて、新しいリポジトリのデフォルトブランチ名を "master" から "main" へ変更します。 新しいリポジトリをローカルへクローンし、ローカルリポジトリでブランチ名を変更します。 git clone %NEW_REPOSITORY_PATH% CD %NEW_REPOSITORY_NAME% git branch -m master main ローカルリポジトリでブランチ名変更により作成したmainブランチをリモートリポジトリに反映します。 > git push -u origin main Total 0 (delta 0), reused 0 (delta 0), pack-reused 0 To %NEW_REPOSITORY_PATH% * [new branch] main -> main Branch 'main' set up to track remote branch 'main' from 'origin'. 次の任意の手段で、新しいリポジトリのディフォルトブランチを "master" から "main" へ変更します。 AWS Management Console AWS CLI ローカルリポジトリでブランチ名変更により削除したmasterブランチをリモートリポジトリに反映します。 > git push origin --delete master To %NEW_REPOSITORY_PATH% - [deleted] master [!IMPORTANT] ディフォルトブランチを "master" から "main" へ変更せずにmasterブランチの削除をリモートリポジトリに反映しようとすると、エラーにより失敗します。