「バックマージって分かる？」と言われ、 混乱したので、具体的に理解するためのメモ。 バックマージの理解 developからmasterへの方向がフォワードで、 masterからdevelopへの方向がバックということで、 hotfixが発生した場合、 masterが前の方向でmasterより後ろの方向にあるのがhotfix、 hotfixより後ろの方向にあるのがdevelopとなる。 developからmasterにマージすること（通常のマージ）を単にマージと言っていて、（フォワードマージと言う時もあるらしい） hotfixからdevelopにマージすることをバックマージと言っている。 hotfixは、緊急対応用のブランチなので、 masterからブランチを切ってくるので、緊急対応後、masterに反映するだけでなく、 developにも反映する必要が発生する、ということで、 このhotfixの文脈でバックマージという言葉がよく出てくる。 参考 What is a back-merge 【Git】git-flowを知ろう！　利用時のルールについて 余談 調べていて、developからfeatureにマージするような時もバックマージと言う言葉で表現するのか？ 今回そういう文脈に遭遇したので、少しスッキリしない部分があるが。

コミットした後、git statusすると再度同じmodifiedが表示される。 $ git status On branch master Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: data/postgres/pg_stat_tmp/db_0.stat modified: data/postgres/pg_stat_tmp/db_13117.stat modified: data/postgres/pg_stat_tmp/global.stat no changes added to commit (use "git add" and/or "git commit -a") 解決法 Git管理する必要がなければ、Git管理から除外する。 git add（ステージングに追加）はしない。 $ git rm --cache data/postgres/pg_stat_tmp/db_0.stat $ git rm --cache data/postgres/pg_stat_tmp/db_13117.stat $ git rm --cache data/postgres/pg_stat_tmp/global.stat $ git commit -m "remove data/postgres/pg_stat_tmp/" 対象のファイルがGit管理から外れているか確認する。 下記のエラー（検索対象ファイルについて、Git管理上のどのファイルとも一致していない。という旨のメッセージ）が出ると、Git管理から除外されていることがわかる。 $ git ls-files --error-unmatch data/postgres/pg_stat_tmp/db_0.stat $ git ls-files --error-unmatch data/postgres/pg_stat_tmp/db_13117.stat $ git ls-files --error-unmatch data/postgres/pg_stat_tmp/global.stat error: pathspec 'data/postgres/pg_stat_tmp/global.stat' did not match any file(s) known to git Did you forget to 'git add'? 再度git statusすると、Untracked files(未追跡ファイル)として出現する。 $ git status On branch master Untracked files: (use "git add <file>..." to include in what will be committed) data/postgres/pg_stat_tmp/ nothing added to commit but untracked files present (use "git add" to track) Untracked files(未追跡ファイル)を削除する。 $ git clean -df 再度 git statusすると、Untracked files(未追跡ファイル)が消えていることがわかる。 $ git status On branch master nothing to commit, working tree clean 以上 参考

概要 Unityで作成したコードをGitHubでバージョン管理する手順を記載しています。 Unityは、EclipseやAndroid Studio、Visual Studioなどと違い、GitHubとの連携が最初から用意されているわけではないようで、下記のような方法を選択するようです。 Github for Unity(https://unity.github.com/) UnityのAssetとして、GitHub管理したいプロジェクトに追加する方式。 Source Tree(https://www.sourcetreeapp.com/) OS上のファイルをGit管理する。という扱いでUnityをGitHub管理する。 GitHub Desktop(https://desktop.github.com/) GitHub純正のGit管理アプリ。GitHub側に近いUIなので、ローカル上の管理は戸惑うかも。 前提環境 *　macOS 12.2.1（Monterey） *　SourceTree *　Unity 2020.3.29f1（Personalライセンス） *　Github Free（https://github.co.jp/pricing.html ） やってみる Unity Hubなどから新規で作成したプロジェクトをGitHubで管理するまでの流れで進めていきます。 個人的に多いのが２Dでのテンプレで作成しているので、下記のような感じの構成になります。 プロジェクト名は「Sample2D」としておきます。 . ├── Assets │   └── Scenes ├── Library │   ├── APIUpdater │   ├── Artifacts │   ├── PackageCache │   ├── PackageManager │   ├── ScriptAssemblies │   ├── ShaderCache │   ├── StateCache │   └── TempArtifacts ├── Logs ├── Packages ├── ProjectSettings ├── UserSettings └── obj └── Debug というわけで、上記のプロジェクトをGitHubへ登録します。 SourceTreeのインストールなど 前回（SourceTreeでGitHubを使う ）で解説したので、そちらを一読してください。 GitHubにリポジトリを作成する SourceTreeからGitHubにリポジトリを作成することはできないようです。 なので、先にGitHub側でリポジトリを作成します。 作成するのは、作成したUnityプロジェクトと同名（Sample2D）としておきます。 自分用のリポジトリなのでPrivateを選択します。 そして、.gitignoreを追加します。（重要） ここで、Unity用の.gitignoreが標準で用意されているので、追加しておくと余計なファイルをGitHubに登録しないようになります。 はい。まずは、空っぽのリポジトリができました。 SourceTreeでローカルにクローンしてくる SourceTreeを開いて、リモート側に作成したリポジトリを探します。 見つけたら、リポジトリの右側の「クローン」をクリックして、適当なところにクローンします。 一応書いておきますが、Unityプロジェクトが置かれているところには、すでに同名のフォルダがあるので別の場所にしましょう。 クローンすると、SourceTreeのローカル側に表示されます。 ローカルにクローンしたフォルダにコピーする Unityプロジェクトをクローンしたフォルダにコピーします。 GitHubにプッシュする 正確には、ローカルのGitリポジトリにコミットして、リモートのGitHubにプッシュです。 UnityプロジェクトでGitHub管理にしたくないものの選別は、すでにUnity用の.gitignoreがあるので、気にせずコミットしてOKです。 下記のように、フォルダにコピーした時点で、コミット対象はこのくらい。と数が表示されている（今回は３０ファイル）。 リポジトリをダブルクリックして開くとコミット対象のリストが確認できる 「保留中のファイル」のチェックをつけると、すべての対象にチェックがつくので、チェックをつけます。 コミットメッセージに適当に記載して、コミットボタンをおします。 下記のような確認が表示されるのでOKをクリック この時点では、GitHubにはあがってません。まだローカルGitへコミットしただけです。 続いて、GitHubへプッシュします。 上記のように、プッシュに通知がきていると思います。 クリックすると、下記のように確認が表示されるので、一応確認してOKボタンをクリックします。 これで、GitHubにプッシュされたはずです。 GitHubで確認してみる GitHub側で対象のリポジトリを見てみると、無事、Pushできていることが確認できました。 このあとの問題 自分はやらかしたので、一応書いておきますが、Unity Hub側で新しくクローンしてプッシュさせたフォルダに切り替えてください。 そうしないと、Git管理されていないほうを更新していって、でもSourceTreeにはコミット対象はない。と言われるアホなことをしでかします。 以上で、UnityをGitHub管理するまでの手順でした。

　こんにちは。 　この記事は、GitのWorking TreeやIndexについて分かるようになる記事です。 なぜコミットの前にgit addするのか分からない git restoreで何が復元されるのかが分からない git reset で何がリセットされるのか分からない 　このような疑問を持つ人向けに、Working Tree (Working Directory)とIndex (Staging Area)について解説していきたいと思います。またよく使うGitコマンドがこれらにどう作用するかについても見ていきたいと思います。 　用語の定義はこちらのGit公式リファレンスから引用しています。 今回使うリポジトリの準備 　あまりGitリポジトリを初期化したことのない方が読む可能性を考え、このセクションに今回使うリポジトリの準備方法を書いておきます。折りたたんでおきますので、見たい方のみご覧ください。 リポジトリの準備 適当なフォルダを作成し、そこにcmdやbashでcdを使って移動します。 {your-folder}をご自身で作成したフォルダに読み替えてください。 $ cd {your-folder} Gitリポジトリを作成し、自分の名前やメールアドレスを設定します。 この名前やメールアドレスは、GitHubなどのサービスにgit pushを行った時点で公開されます。またgit pushが自動的にされることはありません。 $ git init $ git config --local user.name "Your Name" $ git config --local user.email "you@example.com" Gitで管理する対象のテキストファイルを作成します。 $ echo Hello > hello.txt $ git add hello.txt $ git commit -m 'initial commit' 正しく操作が行えていることを確認します。 git logコマンドを実行して、次のようにコミットが作成されていることを確認してください。 名前やcommitの次に続く文字列, コミット日時などは違っていても問題ありません。 $ git log commit a0fc295ef07209bcc5b3f5b3f9bd93adb84f7f5a (HEAD -> main) Author: YourName <youremail@example.com> Date: Wed Feb 23 02:40:25 2022 +0900 initial commit 以上で準備は終了です。 トラブルシューティング 上の手順でエラーが出て進めない場合、エラーメッセージに応じて手順をやり直してください。 次のエラーが出た場合は手順2に戻ってください。Gitリポジトリの初期化(git init)ができていません。 fatal: not a git repository (or any of the parent directories): .git 次のエラーが出た場合は手順2に戻ってください。名前やメールアドレスの設定が不足しています。 Author identity unknown *** Please tell me who you are. 次のエラーが出た場合は手順3に戻ってください。コミットができていません。 fatal: your current branch 'main' does not have any commits yet Working TreeとIndexの概観 　まずは簡単にWorking TreeとIndexの概観を説明します。 　私は絵が得意なので、mspaintで図を描いてみました。 　以下の図は、git addを行うことでWorking Treeにある変更をIndexに登録し、git commitを行うことでIndexに登録した変更をコミットできることを表しています。 　この概観を踏まえて各セクションに進むと読みやすいと思います。 Working Treeとは？ 　Working Tree (Working Directory) とは、今まさにあなたが触っているファイル群のことです。 　Gitでは、Working Treeの役割を砂場と説明しています。このWorking Tree上はコードを修正する実際の作業を行ったり、まだ採用するか分からない修正を試してみる場だからです。 　変更を加えたファイルは、git statusを実行した時にChanges not staged for commit:の下に羅列されます。これによって、どのファイルを変更したかを確認することができます。 　例えば、Git管理されているhello.txtに変更を加えると、次のように表示されます。 (main)$ echo "Bonjour, Monde" > hello.txt (main *)$ git status On branch main Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: hello.txt no changes added to commit (use "git add" and/or "git commit -a") 　このmodified: hello.txtの部分が、現在Working Tree上にhello.txtに対する変更があることを示しています。 git diffでWorking Treeの差分を確認する 　git diffコマンドはこのWorking Treeへの修正の差分を表示するコマンドです。 　Working Treeに差分があるときにgit diffを実行すると、次のようにhello.txtの中身がどのように変更されたのかを確認することができます。 git-diff diff --git a/hello.txt b/hello.txt index 3fa0d4b..97f001a 100644 --- a/hello.txt +++ b/hello.txt @@ -1 +1 @@ -Hello +Bonjour 　これはhello.txtの中身がHelloからBonjourに変更されていることを示しています。 　注意すべき点として、git diffが表示しているのはWorking TreeとIndexの差分であることが挙げられます。 　先ほどはIndexに登録された修正がなかったため、Working TreeとCommit HEAD (一番上のコミットをHEADと呼びます)の差分が表示されているように見えました。しかしIndexに変更を登録しながらWorking Treeを修正する場合には、git diffの表示がWorking TreeとIndexとの差分であることを意識する必要があります。 　Git概観の再掲： git restoreでWorking Treeの変更を取り消す 　git restore <FILE>を実行すると、Working Tree上の変更を取り消すことができます。 $ (main *)$ git restore hello.txt $ (main)$ git status # hello.txtへの修正が取り消された On branch main nothing to commit, working tree clean 　くどいようですが、ここで取り消される変更はWorking Treeのもののみです。Indexに登録された変更やコミットに影響を与えることはありません。 　試しに変更をIndexに登録してからgit restoreを実行してみましょう。 $ (main)$ echo Bonjour > hello.txt # 改めてhello.txtを変更する $ (main *)$ git add hello.txt # hello.txtをIndexに登録する $ (main +)$ git restore hello.txt # hello.txtのワーキングツリー上の変更を取り消す $ (main +)$ git status On branch main Changes to be committed: (use "git restore --staged <file>..." to unstage) modified: hello.txt 　git addを行った後にgit restoreを行っても変更が残っていることが分かります。 　これは、hello.txtにはワーキングツリー上の変更がもはやない(Indexに登録されている)ためです。 余談: 新規ファイルはWorking Treeには含まれない 　新規ファイルはgit addを行うまではGitの管理対象のファイルではありません。 　git statusを実行すると、新規ファイルはUntracked files:の下に羅列されます。これは「Gitによって追跡されていないファイル」ということです。 (main *)$ echo Guten Tag > gutentag.txt # 新規ファイルを作成 (main *)$ git status On branch main Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: hello.txt Untracked files: (use "git add <file>..." to include in what will be committed) gutentag.txt no changes added to commit (use "git add" and/or "git commit -a") 　またgit diffを行っても新規ファイルの差分は表示されません。 Indexとは？ 　Index (Staging Area) とは、次にgit commitする時にコミットされる準備段階のことです。 　　変更を加えたファイルは、git statusを実行した時にChanges to be committed:の下に羅列されます。これによって、どのファイルが次のコミットに取り込まれるかを確認することができます。 　例えば、hello.txtをIndexに登録すると、次のように表示されます。 (main +)$ git status On branch main Changes to be committed: (use "git restore --staged <file>..." to unstage) modified: hello.txt git diff --cached でIndexの差分を確認する 　git diffでWorking TreeとIndexの差分を確認できたように、git diff --cachedを使うことで、IndexとHEADの差分を確認することができます。 　HEADとは現在の一番上の(新しい)コミットのことです。 　Indexに何かしらの変更が登録されているときにgit diff --cachedコマンドを実行すると、次のように差分を表示することができます。 git-diff--cached diff --git a/hello.txt b/hello.txt index e965047..632e4fe 100644 --- a/hello.txt +++ b/hello.txt @@ -1 +1 @@ -Hello +Bonjour Git概観で表現すると次の通りです。git diffとは比べている場所が違いますね。 git restore --stagedでIndexに登録された変更をWorking Treeに差し戻す 　git restore <FILE>でWorking Treeの変更を取り消すことができたように、git restore --staged <FILE>でIndexに登録した変更をWorking Treeに差し戻すことができます。 　Indexにhello.txtが登録してある状態を、git restore --stagedを使って解除してみます。 (main +)$ git restore --staged hello.txt (main *)$ git status On branch main Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: hello.txt no changes added to commit (use "git add" and/or "git commit -a") Changes not staged for commit:の下にmodified: hello.txtがあることから、Indexに登録されていた変更がWorking Treeに差し戻されていることが分かります。 　このとき注意するべき点として、Working Treeに変更が入っている状態でIndexの修正を差し戻すと、Working Treeの修正が勝ちます。 　例えば、まずある変更がIndexに登録されているとします。(Hello -> Bonjour) (main +)$ git diff --cached diff --git a/hello.txt b/hello.txt index e965047..632e4fe 100644 --- a/hello.txt +++ b/hello.txt @@ -1 +1 @@ -Hello +Bonjour 　この状態で、Working Treeに変更を加えるとします。(Bonjour -> Guten Tag) (main +)$ echo Guten Tag > hello.txt (main *+)$ git diff diff --git a/hello.txt b/hello.txt index 632e4fe..9626a13 100644 --- a/hello.txt +++ b/hello.txt @@ -1 +1 @@ -Bonjour +Guten Tag 　この時、hello.txtはIndexにある変更が登録されており、かつその状態からさらにWorking Treeが変更されている状態になります。 　git statusを見ると、Changes to be committed:とChanges not staged for commit:の両方にhello.txtがいることを確認できます。 (main *+)$ git status On branch main Changes to be committed: (use "git restore --staged <file>..." to unstage) modified: hello.txt Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: hello.txt 　この時、git restore hello.txtを行うと、hello.txtの中身は当然Working Treeの変更が取り消されてBonjourになります。 　一方、git restore --staged hello.txtを行うと、hello.txtの中身はGuten Tagになるのです。 git reset HEADでもOK 　Indexに登録した変更をWorking Treeに戻したいとき、git reset HEADを使うこともできます。 　このコマンドを使うとファイルを一つ一つ指定する必要がなく、まとめてWorking Treeに戻したいときには便利です。 (main +)$ git reset HEAD Unstaged changes after reset: M hello.txt おまけ: StashとWorking TreeとIndex 　皆さんがお世話になったことがあるであろうgit stashは、Working TreeとIndexの変更を両方まとめてStashという領域に保存しておくコマンドです。git stash popやgit stash applyを行うと、その変更の両方ともがWorking Treeに適用されます。 おまけ: git reset 　git resetとはHEADの位置を動かすコマンドです。 　例えばgit reset HEAD^とというコマンドを打つと(HEADは一番上のコミットを指し、^は一つ前のコミットを指しますので、HEAD^は一番上から二番目のコミットを指します)、HEADを一番上から二番目のコミットに移すことができます。つまり、一番上のコミットを取り払うことができるのです。 　ここで、git resetは取り払ったコミットのぶんの変更をどのように扱うかでいくつかの選択肢を持ちます。 　Working Treeに取り込むなら--mixed(デフォルト), Indexに取り込むなら--soft, 一切を取り込まないなら--hardといったオプションがあります。 (@はHEADの省略記法です) おわりに 　この記事を読んでWorking TreeとIndexについての理解が少しでも深まったと思って頂けたら幸いです。 　ここで紹介した以外にも、GitコマンドにはWorking TreeやIndexに作用するものが多くあり、またどちらに作用するかをオプションで切り替えられるものも多くあります。そのようなものを使うとき、自分がどのような操作をしたいのかを意識してオプションを選択できるといいですね。

概要 macosでGitHubを使おうとすると、基本はIDE（統合開発環境）にGit連携機能があり、それを経由してリモート先としてGitHubにPushしたりするわけですが、Unityを使うと、どうもこのGitHub連携部分がなくて困った。 そこで、SourceTreeでGitHub操作をすることを整理してみる ざっと流れを記載すると SourceTreeを入手する Github（Private）のリストを表示する Github（Private）にローカルのプロジェクトをリポジトリ追加する GitHubのパスワード認証は廃止された ご存知の方は多いだろう。 GitHubは2021/8にIDとパスワードを用いたパスワード認証が廃止された。 https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/ この廃止によって、意外にGitHub連携に関して記述してある記事も使えなくなっていたりする。 （パスワード認証だと書いているわけではないが、当時は一般的だったので、、、） 本記事は、このパスワード認証が廃止されたことが前提で進める。 前提環境 macos 12.2.1（Monterey） Githubのアカウント所持 macosにGitインストール済み 手順 SourceTreeを入手する まずは、SourceTreeを入手します。 https://www.sourcetreeapp.com/ インストールしたいPCでアクセスすれば、自動的に適切なOSのDownloadボタンが表示されるので、そのままダウンロードします。 *Sourcetree_4.1.6_242.zip SourceTreeをインストールする DownloadしたZipを解凍すると、「Sourcetree.app」が入手されるので、これをアプリケーションフォルダに移動させます。 ローカル内のGit管理プロジェクトを検出する アプリケーションフォルダに移動させた「Sourcetree.app」を起動します。 右下の「続行」をクリックします。 「GitとMercurialのグローバル作成者の詳細を設定する」にチェックを入れます。 作成者名には、公開用の名前を入れます。（要はなんでもいい） 作成者のメールアドレスには、自分のメールアドレスを入れます。（どんなメアドでもいい） 右下の「完了」ボタンをクリックします。 ひとまずSourceTreeを起動しました。 つづいて、「ローカル」のタブをクリックします。 すでに、どこかのフォルダをGitのローカルリポジトリとして設定しているなら、そこでもいいですし、簡単なのは自分のユーザーフォルダを「ディレクトリスキャン」から選択するのが簡単でいいです。 ローカル側のGitプロジェクトが列挙される （自分が認識していたプロジェクト以外に列挙される驚き。あ、昔作ってたわ・・・みたいな） リモート（GitHub）の登録リストを表示する 続いて、GitHub側のリポジトリを列挙してみます。 自分のGitHubアカウントにサインインしてみます。 GitHubにサインインします。 「リポジトリをフィルタ」の右側にある「・・・」ボタンをクリックして、「アカウント」を選択します。 GitHubアカウントを設定します。 左下の「追加」ボタンをクリックします。 下記の状態にまずは選択を変更します 「ユーザー名」には、GitHubのユーザーIDを入力します。 「パスワード」には、GitHubのアカウントパスワードではなく・・・・・Tokenを入力します。 Tokenってなに？と思う人は、下記をみてね。 GitHubのPrivateリポジトリも列挙される ローカルプロジェクトをローカルリポジトリに追加する ローカルリポジトリ（Git）に追加するなら、下記から行います。 ローカルリポジトリのプロジェクトをリモートリポジトリ（GitHub）に追加する ★SourceTreeからGitHubに新規リポジトリ作成はできません！ つまり、何が言いたいかというと、下記のようなことができません。 ローカルのリポジトリ一覧からGitHubへ追加するものを選択します。 右クリックして「リモートに公開...」を選択します。 上記のように追加しようとすると、下記のエラーとなります。 エラーとしては、リポジトリが見つからない。ということなのですが、EclipseやAndroid Studioではできるローカルからリモートへの最初のコミット＆プッシュがリモートへのリポジトリ作成をついでにやってくれる。という機能がないようです。 てっきり、Token作成時の権限の問題かと思ったのですが、そうではないようです。 では、どうするのか？というと、先にGitHub側でリポジトリを作成して、それをローカルにクローンします。 空のリポジトリがクローンされるので、そこにプッシュするファイルをコピーして、それを再度SourceTreeでローカルリポジトリとして認識させて、リモートにプッシュするようなことをします。 現状、Unityが、この方法をとらないといけないようなので、別途UnityプロジェクトをGitHubへ登録する記事を書いて補完しようと思います。 GitHubのToken まずは、GitHub（https://github.com/ ）のWebにサインインします。 画面右上から「Setting」を選択し、「Developer settings」を選択します。 そして、「Personal access tokens」を選択します。 Tokenを作成していない場合は、Tokenを作成します。 「Generate new Token」ボタンをクリックしてTokenを作成します。 Note欄は、複数のTokenを作成した際に区別するためのものなので、適当な名前をつけてください。 自分の場合は、PC別でTokenを使い分けているので、PC名にしてます。 Expirationは、無期限だとちょっと問題なので「９０days」ぐらいで良いです。 期限が切れたら、また更新してください。 あとは、必要な権限にチェックをつけます。 参考までにandroid studio用に作成したもので下記を見てください。 https://qiita.com/TAKANEKOMACHI/items/0101f0ff88fad2696e81