Gitコマンドを忘れてしまったの見直し　~> その2 変更をやり直したい時に使うコマンド checkout git checkout -- <ファイル名> git checkout -- <ディレクトリ名> git checkout -- . #現在いるディレクトリ以下の変更を全てを取り消す ”--”と付いてるのは、ブランチ名とファイル名が被ってしまった時に gitがどっちを指しているのかが分かる様にするためにつけられている。 このコマンドで重要なのは、ステージにあげる前の変更に対して 変更を取り消しているということ つまり、git addした後の取り消しはまた別のコマンドが必要 reset git reset HEAD <ファイル名> git reset HEAD <ディレクトリ名> git resetHEAD . #全部の変更を取り消す 指定した変更をステージから取り消すだけなので、 ワークツリーにあるファイルには影響を与えない つまり自分のローカルの中身は変更がないので、 もし、こちらも変更をしたいのであれば git checkoutをしないとワークツリーには反映されない amend git commit --amend #リモートリポジトリにpushしたコミットはやり直すと大変なことになる... 本当に注意しないといけないのはあくまでpushしたコミットは 決してやり直してはいけない このコマンドの裏側で何を行っているのかというと、、、 ステージに上がっている変更を元にリポジトリの内容を 上書きするということをやっているため 最悪の場合は、マージができなくなる事もあるので 決してpushしたコミットに関して--amendコマンドは使わないこと もし、コミットした内容を変更したい時は 新しくコミットして変更すること ちなみに、git --amendコマンドの内容を確認する際は git logなどを使う事が多いと思うが小ネタとして log git log -p -n 1 #この様に打つと直前のコミットの内容が見れる logに入っている最中は "j＂を打つと下にスクロール、 "p"を打つと上に移動する。 抜けたい時は"q"を打てばいい

Gitを使う際に地味に知っておくと良いコマンド エイリアスをつける alias git config --global alias.ci commit git config --global alias.st status git config --global alias.br branch git config --global alias.co checkout #この様にエイリアスを設定しておくとコマンドを効率よく打つことができる ※もし、--globalをつけないと現在のプロジェクトに対してのみconfigファイルに設定される Gitで管理したくない情報の管理について gitでバージョン管理したくないファイルを管理する方法 バージョン管理したくないファイルとは 例：パスワードやサーバ情報、キャッシュなど自動生成されるファイル .gitigonreファイルに書く index.html #指定したファイルを除外したい時 /root.html #ルートディレクトリを指定したい時 dir/ #ディレクトリ以下を除外したい時 //.css など #/以外の文字列にマッチさせる場合

Gitのインストーラが新しくなるたびに、 ウィザードの質問が増えるのでちょっと記録しておく。 対象 Windows 10 Pro Git 2.31.1 64-bit ダウンロード Git公式サイト ウィザードの流れ 基本的にはすべてデフォルトでもOK。でもいつも新しい画面が出て悩んでしまう。。。 Select Components コンポーネント選択 Git Bash Here・・・これは必ず選択 Git GUI Here・・・GitデフォルトのGUI画面を表示するけど見づらいしほぼ使ったことない Select the components you want to install; clear the components you do not want to install. Click Next when you are ready to continue. ↓↓↓↓↓↓↓ インストールするコンポーネントを選択します。インストールしたくないコンポーネントをクリアします。続行する準備ができたら、[Next]をクリックします。 Select Start Menu Folder Windowsのスタートメニューのフォルダを選択 スタートメニューをあえて変えたい場合に指定することもできるが余計わからなくなるだけなのでデフォルトがいいかな。 Don't create a Start Menu folder・・・Git自体をスタートメニューから起動したことないのでスタートメニューに入れなくてもいいかも。 Setup will create the program's shortcuts in the following Start menu folder. ↓↓↓↓↓↓↓ セットアップは、次のスタートメニューフォルダにプログラムのショートカットを作成します。 to continue, click Next. If you would like to select a different folder, click Browse. ↓↓↓↓↓↓↓ 続行するには、[Next]をクリックします。別のフォルダを選択する場合は、[Browse...]をクリックします。 Choosing the default editor used by Git デフォルトのエディタを選択 Vim使いならデフォルト。 いつもデフォルト選択してたけど、「Atom」選択してみようかな。 説明にも"最新のGUIエディターに切り替えることを強く勧める"とのことだし。 The Vim editor, while powerful, can be hard to use. Its user interface is unintuitive and its key bindings are awkward. Note: Vim is the default editor of Git for Windows only for historical reasons, and it is highly recommended to switch to a modern GUI editor instead. Note: This will leave the 'core.editor' option unset, which will make Git fall back to the 'EDITOR' environment variable. The default editor is Vim - but you may set it to some other editor of you choise. ↓↓↓↓↓↓↓ Vimエディターは強力ですが、使いにくい場合があります。そのユーザーインターフェイスは直感的ではなく、そのキーバインディングは扱いにくいです。 注：Vimは歴史的な理由からのみGit for Windowsのデフォルトのエディターであり、代わりに最新のGUIエディターに切り替えることを強くお勧めします。 注：これにより、「core.editor」オプションが未設定のままになり、Gitが「EDITOR」環境変数にフォールバックします。デフォルトのエディターはVimですが、他のエディターに設定することもできます。 選択肢はこんな感じ Adjusting the name of the initial branch in new repositories 新しいリポジトリ作成時の初期ブランチの名称 GitHubもデフォルトが「main」になったので、ここは「main」を指定してもよさそう。 Let Git decide(Gitに決めさせる) Let Git use its default branch name (currently: "master") for the initial branch in newly created repositories. The Git project intends to change this default to a more inclusive name in the near future. ↓↓↓↓↓↓↓ 新しく作成されたリポジトリの最初のブランチに、Gitにデフォルトのブランチ名（現在は「master」）を使用させます。 Gitプロジェクトは、近い将来、このデフォルトをより包括的な名前に変更する予定です。 Override the default branch name for new repositories(新しいリポジトリのデフォルトのブランチ名を上書きする) New! Many teams already renamed their default branches; common choices are "main", "trunk" and "development". Specify the name "git init" should use for the initial branch: ↓↓↓↓↓↓↓ 新着！多くのチームはすでにデフォルトのブランチの名前を変更しています。一般的な選択肢は、「main」、「trunk」、「development」です。 「gitinit」が最初のブランチに使用する名前を指定します。 下の注釈 This setting does not affect existing repositories. ↓↓↓↓↓↓↓ この設定は、既存のリポジトリには影響しません。 Ajusting you PATH environment パス環境設定 WindowsのコマンドプロンプトやPowerShellからもGitコマンド実行できるので推奨のGit from the command line and also from 3rd-party softwareかな。 Use Git from Git Bash only(GitBashのGitのみを使用する) This is the most cautious choise as your PATH will not be modified al all. You will only be able to use the Git command line tools from Git Bash. ↓↓↓↓↓↓↓ PATHがすべて変更されるわけではないため、これは最も慎重な選択です。 GitBashのGitコマンドラインツールのみを使用できます。 Git from the command line and also from 3rd-party software(コマンドラインおよびサードパーティソフトウェアからのGit) (Recommended) This option adds only some minimal Git wrappers to you PATH to avoid cluttering your environment with optional Unix tools. You will be able to use Git from Git Bash, the Command Prompt and the Windows PowerShell as well as any third-party software looing for Git in PATH. ↓↓↓↓↓↓↓ （推奨）このオプションは、オプションのUnixツールで環境が乱雑にならないように、PATHに最小限のGitラッパーのみを追加します。 Git Bash、コマンドプロンプト、Windows PowerShellのGit、およびPATHでGitを探しているサードパーティソフトウェアを使用できます。 Use Git and optional Unix tools from the Command Prompt(コマンドプロンプトからGitとオプションのUnixツールを使用する) Both Git and the optional Unix tools will be added to your PATH. Warning: This override Windows tools like "find" and "sort". Only use this option if you understand the implications. ↓↓↓↓↓↓↓ GitとオプションのUnixツールの両方がPATHに追加されます。警告：これは、「検索」や「並べ替え」などのWindowsツールを上書きします。このオプションは、影響を理解している場合にのみ使用してください。 Choosing HTTPS transport backend HTTPS通信時使うツール こだわりがなければUse the OpenSSL libraryでいいかな。 Use the OpenSSL library(OpenSSLライブラリを使用する) Server certificates will be validated using the ca-bundle.crt file. ↓↓↓↓↓↓↓ サーバー証明書は、ca-bundle.crtファイルを使用して検証されます。 Use the native Windows Secure Channel library(ネイティブのWindowsセキュアチャネルライブラリを使用する) Server certificates will be validated using Windows Certificate Stores. This option also allows you to use your company's internal Root CA certificates distributed e.g. via Active Directory Domain Services. ↓↓↓↓↓↓↓ サーバー証明書は、Windows証明書ストアを使用して検証されます。このオプションを使用すると、会社の内部ルートCA証明書を使用することもできます。 ActiveDirectoryドメインサービス経由。 Configuring the line ending conversions 行末「改行コード」変換の設定 あとでも設定変更できるけど、WindowsならCheckout Windows-style, commit Unix-style line endingsかな。 改行コードがごちゃ混ぜのときに統一してくれるのでいい感じ。実装時にしっかり統一してくれるエンジニアばかりではないので。 Checkout Windows-style, commit Unix-style line endings(Windowsスタイルをチェックアウトし、Unixスタイルの行末をコミットします) Git will convert LF to CRLF when checking out text files. When committing text files, CRLF will be converted to LF. For cross-platform projects, this is the recommended setting on Windows ("core.autocrlf" is set to "true"). ↓↓↓↓↓↓↓ Gitは、テキストファイルをチェックアウトするときにLFをCRLFに変換します。テキストファイルをコミットすると、CRLFはLFに変換されます。クロスプラットフォームプロジェクトの場合、これはWindowsで推奨される設定です（「core.autocrlf」は「true」に設定されています）。 Checkout as-is, commit Unix-style line endings(そのままチェックアウトし、Unixスタイルの行末をコミットします) Git will not perform any conversion when checking out text files, When committing text files, CRLF will be converted to LF. For cross-platform projects, this is the recommended setting on Unix ("core.autocrlf" is set to "input"). ↓↓↓↓↓↓↓ Gitは、テキストファイルをチェックアウトするときに変換を実行しません。テキストファイルをコミットするときに、CRLFはLFに変換されます。クロスプラットフォームプロジェクトの場合、これはUnixで推奨される設定です（「core.autocrlf」は「input」に設定されます）。 Checkout as-is, commit as-is(現状のままチェックアウト、現状のままコミット) Git will not perform any conversions when checking out or committing text files. Choosing this option is not recommended for cross-platform projects ("core.autocrlf" is set to "false"). ↓↓↓↓↓↓↓ Gitは、テキストファイルをチェックアウトまたはコミットするときに変換を実行しません。このオプションを選択することは、クロスプラットフォームプロジェクトには推奨されません（「core.autocrlf」は「false」に設定されます）。 Configuring the terminal emulator to use with Git Bash GitBashで使用するターミナルエミュレーターの構成 ターミナルの選択はUse MinTTYかな。Linuxコマンドとかも使えていい感じ。 以前、Use Windows' default console window選択したら予想以上に使いづらかった。。 Use MinTTY (the default terminal of MSYS2) (MinTTYを使う) Git Bash will use MinTTY as ternimal emulator, which sports a resizable window, non-rectangular selections and a Unicode font. Windows console programs (such as interactive Python) must be launched via winpty to work in MinTTY. ↓↓↓↓↓↓↓ Git Bashは、サイズ変更可能なウィンドウ、非長方形の選択、およびUnicodeフォントを備えたターミナルエミュレーターとしてMinTTYを使用します。 MinTTYで動作するには、Windowsコンソールプログラム（インタラクティブPythonなど）を winpty経由で起動する必要があります。 Use Windows' default console window(Windowsのデフォルトのコンソールウィンドウを使用する) Git will use the default console window of Windows ("cmd.exe"), which works well with Win32 console programs such as interactive Python or node.js, but has a very limited default scroll-back, needs to be configured to use a Unicode font in order to display non-ASCII characters correctly, and prior to Windows 10 its window was not freely resizable and it only allowed rectangular text selections. ↓↓↓↓↓↓↓ GitはWindowsのデフォルトのコンソールウィンドウ（ "cmd.exe"）を使用します。これはインタラクティブなPythonやnode.jsなどのWin32コンソールプログラムでうまく機能しますが、デフォルトのスクロールバックは非常に限られているため、非ASCII文字を正しく表示するためのUnicodeフォントであり、Windows 10より前は、ウィンドウのサイズを自由に変更することはできず、長方形のテキストしか選択できませんでした。 Choose the default behavior of `git pull` git pullのときのデフォルトの動作を選択 ここはスタンダードのDefaultでいいかな。 Default (fast-forward or merge) (デフォルト fast-forward か merge) This is the standard behavior of git pull: fast-forward the current branch to the fetched branch when possible, otherwise create a merge commit. ↓↓↓↓↓↓↓ これは git pullの標準的な動作です。可能な場合は現在のブランチをフェッチされたブランチに早送りします。それ以外の場合は、マージコミットを作成します。 Rebase (リベース) Rebase the current branch onto the fetched branch. If there are no local commits to rebase, this is equivalent to a fast-forward. ↓↓↓↓↓↓↓ 現在のブランチをフェッチされたブランチにリベースします。リベースするローカルコミットがない場合、これはfast-forwardと同等です。 Only ever fast-forward (fast-forwardのみ) Fast-forward to the fetched branch. Fall if that is not possible. ↓↓↓↓↓↓↓ フェッチされたブランチにFast-forwardします。それが不可能な場合は落下します。 Choose a credential helper 資格情報ヘルパーの選択 新しく追加されてた確認事項、、、正直よくわからん。。 Git Credential Managerは.NET framework使うみたいだし非推奨だし選択しないかな。 Noneもしゃくだし。。 Git credential Manager Core (NEW!) Use the new, cross-platform version of the Git Credential Manager. See more infomation about thhe future of Git Credential Manager here. ↓↓↓↓↓↓↓ （NEW！）Git CredentialManagerの新しいクロスプラットフォームバージョンを使用します。 Git Credential Managerの将来について詳しくは、こちらをご覧ください。 Git Credential Manager (DEPRECATED) The Git Credential Manager for Windows handles credentials e.g. for Azure DevOps and GitHub (requires .NET framework v4.5.1 or later). ↓↓↓↓↓↓↓ （非推奨）Git Credential Manager for Windowsは、資格情報を処理します。 Azure DevOpsおよびGitHubの場合（.NET Framework v4.5.1以降が必要）。 None Do not use a credential helper. ↓↓↓↓↓↓↓ クレデンシャルヘルパーを使用しません。 Configuring extra options 追加オプション パフォーマンス上がるらしいのでEnable file system cachingだけ選択するかな。 Enable file system caching(ファイルシステム・キャッシュを有効) File system data will be read in bulk and cached in memry for certain operations ("core.fscache" is set to "true"). This provides a significant performance boost. ↓↓↓↓↓↓↓ ファイルシステムデータは一括で読み取られ、特定の操作のためにメモリにキャッシュされます（「core.fscache」は「true」に設定されます）。これにより、パフォーマンスが大幅に向上します。 Enable symbolic links(シンボリックリンクを有効にする) Enable symbolic links (requires the SeCreateSymbolicLink permission). Please note that existing repositories are unaffected by this setting. ↓↓↓↓↓↓↓ シンボリックリンクを有効にします（SeCreateSymbolicLink権限が必要です）。既存のリポジトリはこの設定の影響を受けないことに注意してください。 Configuring experimental options 実験的なオプション とりあえずいらんかな。 Enable experimental support for pseudo consoles.(疑似コンソールの実験的サポートを有効) (NEW!) This allows running native console programs like Node or Python in a Git Bash window without using winpty, but it still has known bugs. ↓↓↓↓↓↓↓ （NEW！）これにより、winptyを使用せずにGit BashウィンドウでNodeやPythonなどのネイティブコンソールプログラムを実行できますが、既知のバグが残っています。

GitコマンドやGithubについて、よく使われるらしい用語をまとめます。 適宜追記したり、今後別途切り出して記事にするものもあるかもしれません。 リポジトリ -Repository データを管理する場所。 2種類のリポジトリが存在する。 ローカルリポジトリ: 自分のPC上（ローカル環境）に置かれるリポジトリ。 リモートリポジトリ: 外部サーバーやネットワーク上に置かれるリポジトリ。 クローン -Clone ローカル環境で使用するためにリモートリポジトリのコピーを作成する機能。 ブランチ -Branch 主流（マスターブランチと呼ぶ）から分岐させ、並行作業を行うため機能ごとに作成する。 分岐させたブランチでの修正内容は他のブランチの影響を受けない。 コミット -Commit おこなった作業内容をローカルリポジトリに反映する操作。 プッシュ -Push コミットされた内容をリモートリポジトリに反映する操作。 プル -Pull リモートリポジトリの内容をローカルリポジトリに反映する操作。 プルリクエスト（プルリク） -Pull request Githubに備わっているレビュー機能。 おこなった作業内容を基のブランチに取り込む際に、第三者に内容を確認してもらう。 マージ -Merge 異なるブランチの作業内容を反映すること。マージ先とマージ元双方に履歴が残る。 コンフリクト -Conflict マージした際に、同じファイルの同じ箇所に対して変更がなされていると、変更同士が衝突する。 自動で反映されないため、手動で修正が必要になる。 参考にした資料 エンジニアhub

昨年12月、Github公式ブログより以下の通達がされました。（要約） 2021年8月13日以降、GitHub.comでGit操作を認証する際にアカウントパスワードを受け付けなくなる 認証には、tokenやsshベースによる認証が必要となる つまり、パスワードベースからSSHベースへ認証ベースを変更する必要があり、 変更していないと・・・ コマンドラインでのgitアクセス パスワードを利用した、githubリポジトリへのアクセス が使用できなくなってしまうそうです。 方法自体は各所に書かれており、何番煎じかもよくわからないものになりますが 以下、私が行った設定をメモ的に残します。 （*Mac環境にてiTerm2を使用） 1. ローカルにSSHキーを作成する SSHキーを生成 ssh-keygen -t ed25519 -C "<Githubに登録しているemail>" ターミナルを開き、上記のコードを入力。 SSHキーがユーザーディレクトリ直下の隠しフォルダ内に作成される。 （~/.ssh/id_ed25519とid_ed25519.pub） .pubは公開鍵。付いていない方は秘密鍵。もちろん他人に共有してはいけません ssh-agentを起動させる eval "$(ssh-agent -s)" ~/.ssh/configを編集する Host * AddKeysToAgent yes UseKeyChain yes Identifyfile ~/.ssh/id_ed25519 をファイル内に追記。 SSHキーをssh-agentに登録する ssh-add -K ~/.ssh/id_ed25519 Identity added: が出たら終了。 2. SSHキー（公開鍵）をGithubに登録 公開鍵をクリップボードにコピー pbcopy <~/.ssh/id_ed25519.pub Github上でSettings -> SSH and GPG keys -> New SSH key -> 上記でコピーした公開鍵をペーストして "Add SSH key"をクリックして、終了。

0 はじめに Git入門の備忘録を記載する。 参照 Git入門 サル先生のGit入門 1 gitとは何か？ gitのバージョンを確認する。 $ git --version 2 バージョン管理の流れを理解しよう バージョン管理の流れには、①作業ディレクトリ(ワークツリー)、②ステージングエリア（インデックス）、③リポジトリ（ローカル、リモート）がある。 状態 内容 作業ディレクトリ 作業ディレクトリではファイルを作ったり修正したりする。 ステージングエリア ある程度まとまりになったらステージングエリアにいく。 リポジトリ 最後にきれいにまとまったものを履歴データベースに保存する。ローカルは個人PCで、リモートは共有するために用いる。 3 gitの設定 gitでは名前とEmailを記載するようになっているので初期設定する。 gitは名前とEmailを設定する。 $ git config --global user.name "hdk" $ git config --global user.email “hdk@gmail.com” メッセージを色分けする。 $ git config --global color.ui true 設定情報を確認する。 $ git config -l 4 初めてのコミットをしてみよう $ mkdir myweb $ cd myweb 初期化処理する。 $ git init $ vim index.html 1．作業ディレクトリ -> 2. ステージングエリア（インデックス） $ git add index.html 2. ステージングエリア（インデックス）-> 3. リポジトリ（ローカル） $ git commit index.html メッセージを書き込む必要があるので、「initial commit」などとわかりやすく記載する。 ログを確認する。 $ git log 5　gitのログを確認してみよう。 ログを確認する。 $git log ログを1行で表示する。 $git log　--oneline 変更箇所だけを見る。 $git log　-p ファイルの変更箇所の数をみる。 $ git log　-stat 6 現在の状態を把握しよう ファイルがどのような状態なのかを確認する。 $ git status 正しく修正しており更新する場合は、1．作業ディレクトリ -> 2. ステージングエリア（インデックス）とする。 $ git add index.html 間違って修正した場合は、ファイルをもとに戻す。 $ git checkout -- index.html 7 差分を確認してみよう どこをどう変更したか確認する。 $ git diff $ git diff -cached 8 gitでのファイル操作について indexのhtmlファイルのみをステージングエリアに移行する。 $ git add index.html フォルダ直下のファイルをすべてステージングエリアに移行する。 $ git add . htmlファイルを移動する。 $ git mv index.html 9 git管理に含めない設定について バージョン管理をする必要がない、意味がないログファイルなどを無視したい場合の操作について説明する。 $ vim .gitignore .gitignoreファイルで編集する。 *.log と記載することで.logファイルを無視するように設定できる。 10 直前のコミットを変更する $ vim index.html $ git add . $ git commit -m "ライン2を追加" $ git log コミットするほどでもない追加事項がある場合は、「--amend」を用いる。 $ vim index.html $ git add . $ git commit --amend $ git log 11 過去のバージョンに戻ってみよう (1) バージョン管理のよいてっはいつでも過去に戻って間違いがなかったようにできることである。 $ vim index.html $ git add . それで前のコミットに戻りたい。 $ git reset --hard HEAD または $ git reset --hard IDを記載する 12 過去のバージョンに戻ってみよう (2) 13 ブランチを使ってみよう ブランチには主に統合ブランチとトピックブランチがある。 統合ブランチはリリース版が何時でも作成可能なようしておくためのブランチです。そのため、安定した状態を保っておくことが重要です。通常、masterブランチを統合ブランチとして使用します。 トピックブランチは、機能追加やバグ修正といったある課題に関する作業を行うために作成するブランチです。複数の課題に関する作業を同時に行う時は、その数だけトピックブランチが作成されます。 ブランチの一覧を表示する。 $ git branch *master 新しいブランチ「hoge」を作るときは、 $ git branch hoge hogeに移動するときは $ git checkout hoge masterに移動するときは $ git checkout master 14 ブランチをマージしてみよう $ git branch hoge *master hogeのほうで作られたものをmasterにマージする。 $ git merge hoge もうマージしたのでhogeがいらないときは削除しましょう。 $ git branch -d hoge $ git branch *master 15 マージの衝突を解決してみよう (1) ブランチ「hogehoge」を作成して「hogehoge」にチェックアウトしたい $ git checkout -b hogehoge $ git branch *hogehoge master 同じ行を書き直してマージするとコンフリクト衝突が発生する。 16 マージの衝突を解決してみよう (2) $ vim index.html コンフリクトしている場合は統一したい方に修正する。コメントなどは削除する。 その後は素直にコミットできる。 $ git add . $ git commit -m "ライン2を追加" 17 タグを使ってみよう リリースタグには注釈付きタグを使ってコメントや署名を追加します。 軽量タグはローカルで一時的に使用する使い捨てなどに使用します。 軽量タグ 名前を付けられる 注釈付きタグ 名前を付けられる コメントを付けられる 署名を付けられる $ git log git logしたときに見られる番号commit IDををわかりやすい言葉に置き換えるのがタグの機能である。 直近のcommit IDにタグをつける $ git tag v1.0 $ git show v1.0 指定したcommit IDにタグをつける $ git tag v0.9 CommitのID タグを削除する $ git tag -d v0.9 18 エイリアスを使ってみよう コマンドを省略して登録する。 $ git config --global alias.co checkout $ git config --global alias.st status $ git config --global alias.br branch $ git config --global alias.ci commit 使用例 $ git st 登録してコマンド一覧の表示 $ git config -l 19 はじめての共同作業 共有リポジトリ ourweb.git ローカル Aさん myweb Bさん myweb2 共有リポジトリ $ cd ourweb.git $ git init --bare 20 共有リポジトリにpushしてみよう Aさんが共有リポジトリに登録する場面を想定する。 リモートリポジトリのアドレスは名前を付けて記録しておくことができます。記録しておくと、pushするときには毎回長いリモートリポジトリのアドレスを入力する必要がなくなります。 まずは「origin」という名前でリモートリポジトリを登録してからpushを行います。 リモートリポジトリを追加するには、remoteコマンドを使用します。は登録名、はリモートリポジトリのURLを指定します。 $ git remote add origin ~/ourweb.git originに向かってmasterを突っ込む $ git push origin master 21 リポジトリの内容を共有してみよう Bさんが共有リポジトリから共有する場面を想定する。 リポジトリを複製するにはcloneコマンドを使用します。はリモートリポジトリのURL、は複製先のディレクトリ名を指定します。 $ git clone ~/ourweb.git/ myweb2 Bさんが編集して共有リポジトリに登録する。 $ vim index.html $ git add . $ git commit -m "line2 added" $ git push origin master Aさんが、更新された共有リポジトリからローカルリポジトリにマージする。 $ git pull origin master 22 共有時のトラブルを解決する vim index.html コンフリクトが起きたところを削除する。 $ git commit -am "conflict fixed" $ git push origin

Gitコマンドを忘れてしまったの見直し　〜その1〜 gitに関係ないコマンドもあるが基本的にgitを使う中で必要なコマンドも 載せておく 基本中の基本のコマンド 移動コマンドとディレクトリ作成 cd ~ mkdir ~ ディレクトリ内を表示してくれる ls ~ #指定したディレクトリ内やファイルの中身を表示 ls -a #ディレクトリ内全てを表示 Gitコマンドについて いつも忘れがちなコマンドが多く、使っていかないと 覚えないので、日々使ってみる。 初歩的なgitコマンド達 init git init .gitディレクトリが作成され、gitを使う際に必要なファイルなども作られる git hubからプロジェクトなどをcloneする時に使う clone git clone <リポジトリ名> リモートリポジトリをローカルリポジトリにダウンロードする プロジェクト内の変更をステージに追加するコマンド add git add <ディレクトリ名> git add <ファイル名> git add . #現在いるディレクトリ内の全てをステージに追加してくれるので、注意も必要 ステージに上がっている変更を反映させるコマンド commit git commit #gitのエディタが立ち上がる、欠点としては何を変更したのかの中身は見れない。ちょっとめんどい git commit -m "<メッセージ>" #一番使いやすい。自分だけでやってる時はよく使う git commit -v #変更内容の詳細が見れるので、間違ったコミットをしないようにするため、正式にチームにコミットする時は使うべき addする時もそうだけど、commitする時は変更内容をしっかりと確認する癖をつけないと 大変なことになることもあるので、よく使うコマンドではあるけど気をつけること。 変更がないか確認したい時のコマンド status git status 注意することとしては、ちょっとした違いがあること ステージに変更されているものと、 addする前のものは分けて表示される。 変更分の中身を見れるコマンド diff git diff #git addする前の変更分を見れるコマンド #要するにワークツリーとステージとの差分を表示している git diff --staged #git addした後の変更分を確認したい時に使うコマンド #要するにリポジトリとステージとの差分を表示している コミットした履歴を追ったり、見れるコマンド log git log #よく使うコマンド git log --online #一行で表示してくれる git log -p <ファイル名> #ファイルの変更差分を表示してくれる git log -n <コミット数> #表示するコミット数を制限する ファイルを削除できるコマンド rm git rm <ファイル名> git rm -r <ディレクトリ名> #ファイルごと削除したい場合 #ワークツリーからもリポジトリからも削除される git rm --cached <ファイル名> #リポジトリからは削除したいけど、ワークツリーにはファイルを残したい時は ファイル名を変更したい時 mv git mv <旧ファイル名> <新ファイル名> #ファイル名を変更したい時に使用する ※以下のコマンドでも代替ができる mv <旧ファイル名> <新ファイル名> git rm <旧ファイル名> git add <新ファイル名> コマンドをいちいち覚えるのが面倒であれば下の3ステップを使うのが良さそう ステージに上がっている変更をリポジトリにも反映させる push git push <リモート名> <ブランチ名> #例： git push origin master git push -u origin master #↑の様にコマンドを打つと次回からgit pushと打つだけでよくなるオプション よく使うけど、注意が必要なコマンドも多い、 特に変更をpushする時は、本当に上げていい変更なのかや 変更したものだけをpushするのが安全な気がする。

Gitコマンドを忘れてしまったの見直し　~> その1 <~ gitに関係ないコマンドもあるけど、基本的にgitを使う中で必要なコマンドも 載せておく 基本中の基本コマンド 移動コマンドとディレクトリ作成 cd ~ #ディレクトリを移動する mkdir ~ #ディレクトリを新規作成する ls ~ #指定したディレクトリ内やファイルの中身を表示 ls -a #ディレクトリ内全てを表示 rm ~ #ファイルを削除する cp ~ #ファイルをコピーする mv ~ #ファイルの移動とファイル名の変更を行う cat ~ #ファイルの中身を表示する Gitコマンドについて いつも忘れがちなコマンドが多く、使っていかないと 覚えないので、日々使ってみる。 初歩的なgitコマンド達 init git init .gitディレクトリが作成され、gitを使う際に必要なファイルなども作られる git hubからプロジェクトなどをcloneする時に使う clone git clone <リポジトリ名> リモートリポジトリをローカルリポジトリにダウンロードする プロジェクト内の変更をステージに追加するコマンド add git add <ディレクトリ名> git add <ファイル名> git add . #現在いるディレクトリ内の全てをステージに追加してくれるので、注意も必要 ステージに上がっている変更を反映させるコマンド commit git commit #gitのエディタが立ち上がる、欠点としては何を変更したのかの中身は見れない。ちょっとめんどい git commit -m "<メッセージ>" #一番使いやすい。自分だけでやってる時はよく使う git commit -v #変更内容の詳細が見れるので、間違ったコミットをしないようにするため、正式にチームにコミットする時は使うべき addする時もそうだけど、commitする時は変更内容をしっかりと確認する癖をつけないと 大変なことになることもあるので、よく使うコマンドではあるけど気をつけること。 変更がないか確認したい時のコマンド status git status 注意することとしては、ちょっとした違いがあること ステージに変更されているものと、 addする前のものは分けて表示される。 変更分の中身を見れるコマンド diff git diff #git addする前の変更分を見れるコマンド #要するにワークツリーとステージとの差分を表示している git diff --staged #git addした後の変更分を確認したい時に使うコマンド #要するにリポジトリとステージとの差分を表示している コミットした履歴を追ったり、見れるコマンド log git log #よく使うコマンド git log --online #一行で表示してくれる git log -p <ファイル名> #ファイルの変更差分を表示してくれる git log -n <コミット数> #表示するコミット数を制限する ファイルを削除できるコマンド rm git rm <ファイル名> git rm -r <ディレクトリ名> #ファイルごと削除したい場合 #ワークツリーからもリポジトリからも削除される git rm --cached <ファイル名> #リポジトリからは削除したいけど、ワークツリーにはファイルを残したい時は ファイル名を変更したい時 mv git mv <旧ファイル名> <新ファイル名> #ファイル名を変更したい時に使用する ※以下のコマンドでも代替ができる mv <旧ファイル名> <新ファイル名> git rm <旧ファイル名> git add <新ファイル名> コマンドをいちいち覚えるのが面倒であれば下の3ステップを使うのが良さそう ステージに上がっている変更をリポジトリにも反映させる push git push <リモート名> <ブランチ名> #例： git push origin master git push -u origin master #↑の様にコマンドを打つと次回からgit pushと打つだけでよくなるオプション よく使うけど、注意が必要なコマンドも多い、 特に変更をpushする時は、本当に上げていい変更なのかや 変更したものだけをpushするのが安全な気がする。

はじめに 本記事は, 基本的にgitはCUI(コマンド)で操作するものとして記載しています． また本記事は， Gitのインストールから操作方法までの多岐に渡り記載したいと思いますので， 初心者からGitの使い方をちょっと忘れてしまったという人の様々な人の参考になればと思います． ※ 個人的意見もありますので， 注意してください． gitのGUI操作については， 本記事に記載していませんので， 注意してください． 参考程度に， 下記にGUIで操作できるツールを2つ記載しておきます． SourceTree GitKraken gitを使用する目的 基本的に個人および複数人で開発を行うときのソースコードのバージョン管理を行うツールであるという認識 またgitをうまく使いこなすことで， プロダクトの進捗状況およびIssueを管理することができます． 本記事は, ⓪インストール方法， ①ソースコードのコミットからプッシュまでの操作方法 ② Issueの有効的な使い方？ を記載します． ⓪ Gitのインストール まずはgitのインストールができているかを確認してみましょう git --version # git version 2.21.0 この時点でgitをインストールされたことがない人は, git --versionでエラーが出るかな？？と思います... gitをインストールをしたことがない人は下記から始めてください！！！！！ 本記事では， Homebrewを通してgitをダウンロードするので， Homebrewをインストールされていない方は， インストールしてください brew install git 念のためにHomebrewのダウンロード方法については下記に示しますので参考にしてください． /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" 上記のコマンドで, gitのダウンロードは完了です！ 念のために, git --versionしてダウンロードできているか確認してください. gitのアップデートのみ行いたい人は brew upgrade git ここまでがgitのインストールおよびアップデートについてでした． 引き続き，gitの操作の流れについて記載します． ① commitからpushの流れ 1.1 ユーザ設定 Gitではユーザー名とメールアドレスが、コミットのログなどに記録されます． ユーザー名とメールアドレスを確認するには、以下のコマンドを使用します． git config user.name # usernameの表示 git config user.email # 登録しているemailの表示 Gitのユーザー名とメールアドレスを，以下のコマンドで設定することができます git config --global user.name "ユーザ名” git config --global user.email メールアドレス 上記での， --globalオプションは， ユーザごとの設定を行う ~/.gitconfig ファイルに対して、値を設定することです 設定しておくことで， 以降のログインは不要です． 1.2 リポジトリの作成 下記では, 自身でプロジェクトを作成する手順について記載します． 仮に，既にGitのリポジトリが存在し， コードをローカルにコピーしたいときは, git clone {リポジトリURL}で行うことができます． 1.2.1 リポジトリを作成するディレクトリに移動 gitで管理したいフォルダまで移動します． cd ~/使用するプロジェクトのフォルダ 1.2.2 リポジトリの作成 git init 1.3 ローカルリポジトリへのコミット 1.3.1 コミット git add . git commit -m "first commit" add .はディレクトリ内の全てのファイルを示します． 仮にファイルを指定してpushしたい場合は， ドットではなくファイル名に変更することで 特定のファイルのみをpushすることができます． またcommit -mは， pushする際にメッセージを残すことができます． 現時点でのコードの進捗状況を簡易的に記載しておくとベターだと思います． 例) git commit -m "fix miss typo" -mはなく， git commitのみだけでもpushすることができます！！ 1.3.2 コミット状況確認 git log 上記の写真のようにプロジェクトのコミット状況を確認することができます.(写真が雑ですみません) git log --oneline --graph こっちの方が見やすいですね！！ <間違えてcommitした時の対処> 仮にコミットを間違えてしまった場合の対処方法について 記載しておきます． ・ 削除 git reset --hard HEAD^ git reset --hard HEAD^^ git reset --hard HEAD^^^ １つ前のコミット取り消し ２つ前のコミット取り消し ３つ前のコミット取り消し そしてこの状態でリモートへ普通にpushすると， コミット履歴で不整合が生じてしまっているのでpushできません.... そのため，リモートのブランチを修正するために強制pushを使用して ブランチを誤ってpushしてしまう前の状態へ戻しましょう！ ブランチ名の前に「+」をつけることで強制pushになります. git push origin +master # 或いは git push origin +developer ・ 上書き git commit --amend 直前のコミットに上書きする 1.4 Githubへのpush ・ remoteでのpush git remote add origin {プッシュするURL} ・ push git push -u origin master 1.5 pushされているかの確認（Github上で） ② Issueでプロジェクトの管理を行う リポジトリ内のIssuesタブで，プロジェクトの進捗・タスク管理状況などを行います 2.1 Issueの作成によるタスク管理状況の確認 Issuesのタブから [New Issue]ボタンを選択することでIssueを作成することができます． 上記のように, IssuesタブにIssueが作成されます． Issuesを用いて進捗・タスク管理を行うことで， 複数の開発者で進捗を管理することができます． そのため，リモートワークの現在に，とても有効的な手段です！！！ おわりに 本記事は，Gitのインストールからある程度の操作方法までの手順について記載しました． しかしながらpushまでの流れは個人でgit管理を行う上での操作手順でした． 今後，複数人での開発のためのgit操作について記載したいと思います．(git branchなどの操作)

はじめに みなさんはバージョン管理、どうやっていますか？ 私は断然Git派です。 下記のように旧バージョンのファイルの別名保存でバージョン管理している方は大変だと思います。 ファイル名_yyyymmdd.js ファイル名_var1.1.js etc... この方法はハードディスクの容量を圧迫したり、履歴を追いにくかったり、間違えて削除してしまう等の問題がたくさんあります。 このアナログなバージョン管理の問題と縁がないツールがGitなのです。 当記事では実際にじゃんけんゲームの開発をしながらGitについて学びます。 ついでにJavaScriptについてもちょっとだけ学ぶことができます。 当記事はGitHubは興味あるが使ったことない、プログラミングを学びたいが何をしたらいいかわからない方などにオススメです。 JavaScriptを書いてみたいという方にも少しはオススメできます。 今回は数あるGitのツールの１つ、GitHubを使用します。 なぜGitを学ぶのか 私がGitを学んだ1番の理由は「モダンなプロジェクトはだいたい導入している」からです。 Gitが扱えないとモダンなプロジェクトに参画しにくいです。 参画の選択肢がレガシーなプロジェクトに絞られてしまうことは自身にとって大きな損失です。 エンジニアとしての価値を高めたいと思っている方はGitを学んでおくべきだと思います。 もちろんGitには採用するに値するメリットがあります。 それはローカルリポジトリの存在です。 通常のチームの開発では1つのファイルのコミットに対して全員が影響を受けますが、Gitのローカルリポジトリでは個人PCにのみにコミットされるので 他の開発者への直接的な影響がありません。これにより下記のメリットが生まれます。 個人単位でレビューがしやすくなる。 コードの間違いをコミット履歴を追いながら探しやすい。 過去のソースコードに簡単に戻すことができる。 サービスがダウンしてもローカルで開発を継続できる。 まだまだメリットはあると思いますがキリがないのでこれくらいにしておきます。 Git環境構築 Gitのインストール、GitHubの設定は下記の記事が参考になります。 Windows Windows10にGitをインストールして初期設定する [Windows 10] Git BashでGitHubにSSH接続 macOS MacBookへのgit導入とGitHub運用 じゃんけんゲームについて 機能 1人のプレイヤーがCOMとじゃんけんで対戦可能 勝敗の結果は画面に表示 サーバー環境 名前 役割 HTML ページ構成 CSS デザイン全般 JavaScript ゲームロジック 概要 あなたは今日からじゃんけんゲームの開発プロジェクトに携わることとなりました。 しかし、そのじゃんけんゲームには前任者が残したバグがあり、まともに遊べません。 Gitに触れながら4つの課題をクリアし、じゃんけんゲームを遊べるようにしましょう。 GitHubへのリンク Gitの構成について学ぶ 実際に手を動かす前にGitがどのようにプロジェクトを管理しているか学びましょう。 図に表すと下記のような形になります。 では一つ一つ説明していきます。 リモートリポジトリとは サーバー上に配置されているファイルやディレクトリの状態を記録する場所です。 このリモートリポジトリは他の人と共有することができます。 ローカルリポジトリとは PC上に配置されているファイルやディレクトリの状態を記録する場所です。 皆さんがPCで作業する際はこのローカルリポジトリを使います。 リモートリポジトリから他の人が作業した内容をローカルリポジトリに反映させることもできます。 インデックスとは ローカルリポジトリにコミットするファイルを登録する場所です。 ここに登録されたファイルのみローカルリポジトリにコミットされるので、コミットが不要なファイルがある際は個別に登録するといいでしょう。 ワークツリーとは 実際に作成、修正をしたファイルがあるディレクトリのことです。 じゃんけんゲームのリポジトリを複製する 教材となるリポジトリは別の方も使うのでご自身のGitHubアカウントで、教材用のリモートリポジトリを作成しそこに複製をしてください。 下記の図のようなイメージです。 実際にやってみる GitHubで複製先リモートリポジトリを作成します。 ここではtestという名前の複製先リモートリポジトリを作成しました。 複製元のリポジトリをクローンします。 通常git cloneコマンドではリモートリポジトリの名前のディレクトリが作成されます。 今回は複製をするのでディレクトリ名を変更してcloneしましょう。 git cloneコマンドではURLの後に変更後のディレクトリ名を指定できます。 先程作成した複製先リモートリポジトリのtestをディレクトリ名としました。 $ git clone https://github.com/okioka/GitTrainingRPS test cloneしたローカルリポジトリへ移動します。 $ cd test 現在のremote urlを確認します。 $ git remote -v origin https://github.com/okioka/GitTrainingRPS (fetch) origin https://github.com/okioka/GitTrainingRPS (push) remote urlを複製先リモートリポジトリに変更します。 $ git remote set-url origin https://github.com/okioka/test remote urlが変更されたことを確認します。 $ git remote -v origin https://github.com/okioka/test (fetch) origin https://github.com/okioka/test (push) 複製先リモートリポジトリにpushしてください。 $ git push これでリポジトリの複製が完了しました。 課題をissueで管理する issueとは こちらはGitではなくGitHubに備わっている機能の1つです。 名前の通りリポジトリの課題や問題を管理するための機能です。 開発チームによって様々な運用方法がありますが、私は課題解決のタスク管理ツールとしてissueを使っています。 せっかくある便利な機能なので4つの課題をissueで管理してみましょう。 実際にやってみる issueの一覧はリポジトリ内のissueディレクトリに入っています。 ここではissue#1.mdを基にissueを作成します。 まずは、GitHubの画面からissueを開きNew issueボタンをクリックします。 issue#1.mdの内容を転記しSubmit new issueボタンをクリックします。 残りの３つのissueも同じ手順で作成してください。 次からいよいよ開発です。 issue#１を例に進めていきます。 issueごとにブランチを切る ブランチとは ブランチは履歴を分岐して記録するためのものです。 ブランチの切り方も開発チームによって運用方法がありますが、私はissueごとにブランチを作成しています。 Gitが自動で作成するmasterブランチというものがあります。 基本的にmasterブランチにはリリース可能な状態にしておき、直接作業したりコミットすることはありません。 分岐したブランチが結合したものがmasterブランチです。 イメージとしては下記の図のような感じでしょうか。 ブランチ名の重複はNGなので命名規則を作ってそれに倣った命名をするとよいと思います。 私はブランチ名に「issue番号_ 何をするか_機能」と命名しています。 ここでは「1_feature_update_draw_text」と命名することにします。 実際にやってみる ブランチを作成します。 $ git branch 1_feature_update_draw_text ブランチを切り替えます。 $ git checkout 1_feature_update_draw_text これでブランチの切り替えが完了しました。 現在のブランチを知りたい場合は下記コマンドで確認できます。 $ git branch * 1_feature_update_draw_text master ブランチの一覧が出力されました。 *がついているブランチが現在のブランチです。 開発 では実際に開発してみましょう。 リポジトリ内のindex.jsが対象のコードです。 変更をインデックスに追加する 開発が完了したら変更したファイルをインデックスに追加します。 $ git add index.js git statusコマンドでaddが正常に動作したか確認することができます。 これはブランチの状態を確認する事ができるコマンドです。 様々な場面で使うことがあるので覚えておきましょう。 $ git status On branch 1_feature_update_draw_text Changes to be committed: (use "git restore --staged <file>..." to unstage) modified: index.js ※余談ですが、ワークツリーの変更されたファイル、削除されたファイル、新しく作られたファイル全てをインデックスに追加することもできます。 $ git add -A 変更をローカルリポジトリにコミットする インデックスに存在する変更をローカルリポジトリにコミットします。 git commitコマンドはオプションにmを設定することでコメントを指定することができます。 変更履歴がわかりやすくなるメリットがあるので簡単なコメントを指定しておくとよいでしょう。 $ git commit -m 'あいこのテキスト修正' コミットのログを確認することもできます。 $ git log commit 76d21345a1fd12e61b4477b7b40da41208d6778e (HEAD -> 1_feature_update_draw_text) Author: 木岡おき <okioka@Oki-Special.local> Date: Sun May 16 04:10:51 2021 +0900 あいこのテキスト修正 ログは:qで閉じることができます。 変更をリモートリポジトリへプッシュする ローカルリポジトリの内容をリモートリポジトリへプッシュし反映させます。 初回のプッシュ $ git push --set-upstream origin 1_feature_update_draw_text ２回目以降のプッシュ $ git push プルリクエストを承認・マージする プッシュすることでGitHub上のリモートリポジトリにプルリクエストが発生します。 プルリクエストとは ローカルリポジトリの変更内容を開発チームのメンバーに通知する機能です。 本来であればコードレビューの担当者が確認をし承認するのですが、今回は一人で開発することを想定しているので手順のみを記載します。 ※ちなみにこんな感じで開発者とレビュー担当者がやり取りすることができます。 マージとは 分岐したブランチをmasterブランチに統合することをマージと言います。 実際にやってみる GitHubの画面に現れたCompare & requestボタンをクリックしましょう。 作業したissue番号を入力しCreate pull requestボタンをクリックします。 Marge pull requestボタンをクリックします。 Confirm margeボタンをクリックします。 ブランチの修正内容がリモートリポジトリに反映されました。 これでプルリクエストの承認・マージは完了です。 issueをCloseする タスクが完了したのでissueをCloseしましょう。 対象のissueを開き、下の方までスクロールするとあるClose issueボタンをクリックします。 ここまでの作業で課題の１つが完了しました。 残りの３つの課題も同じ手順で進めましょう！ おわりに 最後まで読んでいただきありがとうございました。 この記事が皆さんの学習の役に立てば嬉しいです！

mainブランチからpullする コンフリクトしたブランチに移動する mainブランチをマージする コンフリクトを解消する pushする プルリクを出す

目的 プライベートリポジトリを公開リポジトリに変更する方法をまとめる 方法 当該のリポジトリを開く。 Settingsをクリックする サイドバーにてOptionsを選択する。 ページ最下部までスクロールする。 Change repository visibilityのChange visibilityをクリックする。 Make publicをラジオボタンで選択する。下部のテキストボックスに当該のリポジトリ名を入力してI understand, change repository visibility.をクリックする。 プライベートリポジトリを公開リポジトリに変更することができた。

Git Large File Storage (LFS) とは、リポジトリ内の巨大なファイルをテキスト形式のポインタに置き換えつつ、実体をリポジトリ外のファイル置き場に逃がす仕組みです。 1 Git は比較的小さなファイル（ソースコード等）を格納することを主眼に置いているため、リポジトリホスティングサービスによってはファイルサイズの上限が設定されていることがあります。例えば GitHub の場合、プッシュしたファイルサイズが 50MB より大きいと警告が表示され、 100MB を超えるとブロックされます。2 巨大ファイルをコミットと関連付けてバージョニングしたい場合、ホスティングサービスが LFS をサポートしているか確認してみましょう。 幸い、GitHub は LFS をサポートしています。3 無料アカウントの場合ストレージの上限は 1GB で、不足分は購入する必要があります。4 素直に必要経費として払えば良い話なのですが、過去にコミットした巨大ファイルが無駄にストレージを食べているなど、お掃除してうまくやりくりしたい時もあるでしょう。本記事では過去にコミットした巨大ファイルを歴史から抹消する方法と、それを利用してストレージを節約する方法をご紹介します。 過去のコミットから不要なファイルを削除する 歴史を改ざんする危険な処理なので事前にブランチを切って実験することをお勧めします。 GitHub 公式ドキュメントの 機密データをリポジトリから削除する で紹介されている方法を利用します。 git filter-branch --force --index-filter \ "git rm --cached --ignore-unmatch <不要なファイルへのパス>" \ --prune-empty --tag-name-filter cat -- --all filter-branch は任意の「フィルタ」処理を指定して過去のコミットを書き換えます。各引数の意味は以下の通りです5： --force 一時ディレクトリで実行している場合等を除き、--force オプションを指定しなければ実行できないようになっています。 --index-filter <コマンド> インデックスに対するフィルタ処理を指定します。6 今回の場合、指定したファイルをコミット対象から除外しています。 --prune-empty フィルタ処理の結果「空コミット」になったコミットを削除します。 --tag-name-filter <コマンド> タグ名を書き換えます。 今回の場合、タグ名はそのまま、タグが書き換え後のコミットを指すように書き換えます。 -- <rev-listオプション> 内部的に呼び出される git rev-list への引数です。 今回の場合、全コミットに対して処理を行います。 リポジトリの規模にもよりますが、filter-branch の実行にはそれなりに時間とマシンパワーを必要とします。コーヒーでも入れて気長に待ちましょう。 GitHub リポジトリを移行してストレージを開放する さて、ブランチから忌まわしき巨大ファイルを抹消できました。しかし、この状態でリポジトリにフォースプッシュしても LFS のストレージ消費は減りません。過去のコミットからポインタが抹消されたに過ぎず、LFS サーバ上の実体はリポジトリが削除されるまで保持されるからです。7 そのため現行リポジトリを削除して、新リポジトリへ移行する必要があります。 git remote add <新リポジトリ> git push <新リポジトリ> <ブランチ名> ここまでの作業を移行したいブランチの数だけ繰り返します。また、移行したいタグがあれば、それらもプッシュします。なお一度にプッシュするサイズが大きすぎると、以下のようなエラーになる可能性があります： RPC failed; curl 92 HTTP/2 stream 0 was not closed cleanly: PROTOCOL_ERROR (err 8) そのような場合は、一時ブランチを作成し、過去から遡るように少しずつチェックアウト＆プッシュすることで回避できます。そして最後に、旧リポジトリをGitHub上から削除すればお掃除は完了です！ 参考リンク How to delete a file tracked by git-lfs and release the storage quota? Git Large File Storage (LFS) 機密データをリポジトリから削除する filter-branch https://git-lfs.github.com/ ↩ https://docs.github.com/ja/github/managing-large-files/conditions-for-large-files ↩ https://docs.github.com/ja/github/managing-large-files/about-git-large-file-storage ↩ https://docs.github.com/ja/github/managing-large-files/about-storage-and-bandwidth-usage ↩ https://git-scm.com/docs/git-filter-branch ↩ インデックスを直接操作するオプションを利用しているのは、チェックアウトしてからワークツリーを操作する--tree-filterオプションよりも高速に動作するためです。 ↩ https://docs.github.com/ja/github/managing-large-files/removing-files-from-git-large-file-storage ↩