この記事の目的

• 「Gitって何」というレベルの人が、とりあえずGitを使ってUnityプロジェクトをバックアップできるようになる
  • 想定としては非プログラマ（デザイナーとか、VRChatユーザとか）
  • 想定ユーザは1人だけで、チーム開発ではない
• ここでいう「バックアップ」は次のことができる
  • 今のUnityプロジェクトの状態を保存できる
  • 操作をミスってぶっ壊したときに、直前のプロジェクトの状態に戻せる
• Gitの「むずかしい」機能は使わない
  • ブランチ操作などはしない

今回使うもの

• GitHub for Unity

インストール手順

1. GitHub for Unityをダウンロードする

• GitHub for Unity

こちらからGitHub for Unityのunitypackageをダウンロードしてください。
（アセットストアから導入しても可）

2. バックアップしたいUnityプロジェクトにアセットを追加する

バックアップしたいUnityプロジェクトをUnityで開き、さきほどのunitypackageを追加してください。

導入が完了すると、メニューのWindow -> GitHubの項目が追加されています。

3. 初期設定をする

Window -> GitHubから、GitHub for Unityのウィンドウを開きます。
初回起動時は裏でインストールが実行されるため、ちょっと待たされる場合があります。

ウィンドウが開けたら、Settingを選び、NameとEmail欄を設定してください。
適当な名前とメールアドレスでもOKです（プロジェクトをpublicに公開するなら、ちゃんとしたものを入力しておいた方がいい）。

4. プロジェクトをGit管理下に置く

Initializeのタブを開き、Initialize a git repository for this projectのボタンを押します。

このボタンを押すとUnityプロジェクトに対してGitの初期設定が実行され、このプロジェクトでGitが使えるようになります。

5. 現状の状態で1回まずバックアップをとる

インストールした直後の状態で、まず1度バックアップを取ります。
（ちなみにGitの場合はバックアップを取る作業のことを「コミット」すると呼びます）

changesのタブを開き、すぐその下のAllを押します。
すべてのファイルにチェックが付いたことを確認してから、下の方のCommit summaryとCommit descriptionを入力してください。

• Commit summary : このコミットにつける名前
• Commit description : このコミットでやった作業の詳細

summaryとdescriptionは適当でも構いませんが、あとからバックアップを見直す時に困るのである程度分かるように入力しておくことを推奨します。

すべて入力できたら、右下の Commit to [master] を押します。

正しくコミットできたら、Historyタブにこのコミットが追加されています。

導入は以上です。

使い方

現在のプロジェクトの状態でバックアップをとる

GitHub for Unityを導入した状態でプロジェクトを操作すると、Projectビューにマークが付きます。

これは、「このファイルはまだコミットされていない」という意味になります。
つまり「バックアップしていないファイルだよ」という表示になります。

（差分が出ているファイルにマークが付いている）

バックアップを取る場合はさきほどと同じく次の操作を行います。

1. changesタブを開く
2. 上の方にあるRefreshボタンを押す
3. このコミットへ含めたいファイルにチェックを入れる
4. summaryとdescriptionを入力する
5. Commit to [master]

正しくコミットできたら、Historyタブにコミットが追加されています。

コミットの頻度はどうしたらいいか

「区切りがいいタイミング」でコミットする（バックアップする）とよいでしょう。
たとえば「新しいアセットを追加した」「Prefabの設定値を変更した」など。

「今日1日分の作業をまるごとコミットする」でも構いませんが、巻き戻した時に大量のファイルが戻ってしまいます。
適切な粒度でコミットするようにしましょう。

直前のバックアップへ巻き戻す

間違えてファイルを消してしまったり、設定値がおかしくなってしまった場合に、直前のコミットの状態に戻すことができます。

1. changesタブを開く
2. 巻き戻したいファイル/フォルダを右クリックして、discardを選ぶ

discardすると削除したファイルは復活し、変更したファイルの設定は元に戻ります。

注意点として、discardで巻き戻した設定をまた元に戻すことはできません。
保存したかったファイルを間違えてdiscardしてしまうと取り返しがつかないので、かなり注意する必要があります。

おまけ：前回のバックアップをなかったことにしたい

バックアップしたはいいものの、ミスってたため「前回のバックアップ」をまるごとなかったことにしたい場合。

GitHub for Unityからは、「バックアップの操作を打ち消す」という操作ができます。

1. Historyタブを開く
2. なかったことにしたいコミットの履歴を右クリック
3. Revertを押す

Revertすると、「そのコミットの逆の操作」をしたコミットが生成されます。
これによって前回のバックアップを擬似的になかったことにできます。

（新しいファイルを追加したのなら、それを消す変更を追加することでプラスマイナスゼロにする）

まとめ

GitHub for Unityを使えば、とりあえず「バックアップする」「壊れた時に直前の状態に戻す」ということができるようになります。

ただし、GitHub for Unityは必要最低限の操作しかできません。
なので、次のような複雑な操作は実行できません。

• 特定のコミットの状態に完全に戻したい
• 複数人で同時にプロジェクト編集したい
• 変更を残したままコミットだけなかったことにしたい
• 現在の状態を保持したまま、別の作業を並行して行いたい

これらの操作がしたくなった場合は、 Git for Windowsを導入した上で、他のGUIツールを使ってみるとよいでしょう。
（SourceTreeやGitHub Desktopなど。余力があるならコマンドラインでGit操作できるとなおよい。）

おまけ：サーバにバックアップを保存する

GitHub for Unityを使えば、そのままGitHub（サーバ）にバックアップを保存することができます。

容量制限に注意

なお、GitHubは無課金では1GBまでしかサーバに保存できません。
また通信量も規制の対象になり、一ヶ月あたりに1GBまでしか通信できません。
（プロジェクト単位ではなく、ユーザ単位での制限なので大量のプロジェクトをアップロードするとすぐに達してしまう）

もし制限を超えた場合はアップロードができなくなる点に注意してください（勝手に課金されたりはしません）。
そのため大きなプロジェクトをGitHubにアップロードする際は注意が必要です。

ちなみに、月$5でこの容量を50GBまで増やすことができます。

（容量を増やす場合は、ユーザ設定のBilling -> Git LFS Data -> Edit -> Add more data pack）

アップロード方法

1. GitHubアカウントを作る

• GitHub

GitHubにアクセスし、新しいアカウントを作ります。

2. Unity上でサインインする

GitHub for Unityのウィンドウの右上にあるSign inを押してGitHubにサインインします。

3. リモートリポジトリを作る

GitHub for Unityのウィンドウの左上の、Publishボタンを押します。

すると新しくリモートリポジトリを作る画面が出てくるので、名前などをつけてリモートリポジトリを作ります。

Make repository privateにチェックをいれると、自分だけがアクセスできるリモートリポジトリになります。
プロジェクトの内容を第三者に見られたくない場合は必ずチェックしてください。

リモートリポジトリができると、現在のプロジェクトの状態が自動でアップロードされます。
アップロード状況はブラウザからGitHubを開くことで確認できます。

4. 定期的にサーバにアップロードする

リモートリポジトリの設定ができると、GitHub for Unityのウィンドウの左上のボタンが変わります。

• Fetch : サーバの状態をダウンロードする（反映はしない）
• Pull : サーバの状態をダウンロードして、プロジェクトに反映する
• Push : ローカルの状態をアップロードする

コミットが終わったらPushするようにするとよいでしょう。

アップロードしたプロジェクトファイルのダウンロード方法

たとえば「別のPCで作業をしたい」等となった時はサーバにアップロードしてあるプロジェクトファイルをダウンロードしてくる必要があります。

GitHubのダウンロードボタンは使えません

GitHubにはアップロードしたファイルをZipでダウンロードするボタンがあります。
ここからZipファイルをダウンロードして解凍すれば保存したプロジェクトファイルが入手できます。
が、ダウンロードボタンからプロジェクトファイルをダウンロードした場合、音声や画像データが読み込めない状態になります。

これは特定の拡張子のファイルはGitHubの別のサーバに保存されているからです。（Git LFSという機能が使われている。）
アップロードに失敗しているわけではないので安心してください。正しい方法でダウンロードすればちゃんと復元できます。

どうしたらいいの

一番簡単な方法はGitHub Desktopを使うことです。

• GitHub Desktop

1.ダウンロードしてインストールする

ここからダウンロードしてインストールしてください。

2. GitHubにサインインする

起動したらFile -> Option -> AccountsからGitHubにサインインしてください。

3. アップロードしたファイルをダウンロードする

File -> Clone repository... を押す。

ダウンロードしたいリポジトリを選び、保存先を選んでCloneを押す。

Git LFSを初期化しますか？と聞かれたらInitialize Git LFSを押す。

これで正しく画像や音声データを含んだ状態でプロジェクトがダウンロードできました。

4. Unityで開く

あとは普通にUnityで開けばOKです。

概要

右も左もわからない状態ではありましたが、
１年間テックベンチャーでがむしゃらにやったので
１年に一回くらいはネタというか自己満記事を。（寒くてすみません。。）

デスノートにて

｢デスノート」面白いですよね。
アニメの中で、Ｌがキラを学生と断定したシーンありますよね？

人が不審死をした事例をプロットして一週間ごとに区切って重ね合わせると、
特定時間には一切事件が起きていない。
起きていない時間は平日の特定時間だが、
曜日によって途中に細切れの時間がある。

よって、大学生の時間割と考えるとあてはまる、
つまり、キラは大学生に違いない！というシーンです。

で、今回は別に直接は関係ないんですが４月になったので
自分のGitで１年間のコミットを振り返ってみたところ、
これ、なんかデスノートで見たプロットに似てるなと思ったので投稿に至りました。笑

今年１年間のコミットログ

このログに特に意味はないですし、人それぞれなので比べるつもりはありませんが、
自分の中ではまあ頑張った勲章なのかなと。

みなさんもリモートワークなどで大変かとは思いますが、
昨年度の振り返りもしつつ、また新年度を心機一転頑張りましょう！！

というわけで、

おわり。

備忘録もかねてGitのコマンドをまとめます。初学者向け

■ローカルリポジトリの新規作成

git init

• .git ディレクトリが作成されます。 リポジトリと、Gitのバージョン管理に必要な各種ファイルが作成されます。

■ローカルリポジトリの変更をステージに追加(コミットの前準備)

git add <追加したいファイル名もしくはディレクトリ名>
git add . //すべてのファイルを追加

■ローカルリポジトリの変更を記録(コミット)

git commit //コミットメッセージ記入用のエディタが開く
//一行目：変更内容の要約
//二行目：空行
//三行目：変更した理由
git commit -m "コミットメッセージ"

■リモートリポジトリからローカルリポジトリにコピーを作成

git clone <リポジトリ名>

■現在の変更状況確認

git status

■コードの変更差分確認

• git addする前

git diff
git diff <ファイル名>

• git addした後

git diff --staged

■変更履歴の確認

git log 
git log --oneline //1行で表示

■リモートリポジトリ(Github)を新規登録

※originというショートカットキーでURLのリモートリポジトリを登録する

git remote add origin <リモートリポジトリのURL>

■リモートリポジトリへローカルの変更を送信する(Push)

git push <リモート名><ブランチ名>

リモートリポジトリ(Github)を新規登録

■Gitコマンドにエイリアス(略称)をつける

git config --global alias.br branch //globalオプションでPC全体の設定に適用される

■.gitignoreファイル(履歴管理から除外するファイルを指定するファイル)の書き方

#でコメントアウト
home.html //除外するファイルを指定
dir/ //ディレクトリ以下を指定 

■ファイルへの変更を取り消す

git checkout <ファイル名またはディレクトリ名>
git checkout -- . //すべての変更を取り消す

■ステージした変更を取り消す

git reset HEAD <ファイル名またはディレクトリ名>
git reset HEAD . //すべての変更を取り消す

※ファイルの変更内容はそのまま残る

■直前のコミットをやり直す

git commit --amend

※amendは「修正」の意

■リモートリポジトリの表示

git remote
git remote -v //リモートリポジトリの情報を表示

■リモートから情報を取得

git fetch <リモート名>

■リモートから情報を取得してマージする(pull)

git pull <リモート名><ブランチ名>
git pull //上記コマンドと同じ動作をする。省略可能

pullではFetchとマージを同時に行っています。
pullした内容はすべてmasterブランチにマージされてしまうので注意

■ブランチを新規追加

git branch <ブランチ名>

■ブランチ表示

git branch
git branch -a //すべてのブランチを表示する

■ブランチの切替

git checkout <ブランチ名>
git checkout -b <新ブランチ名>　//ブランチを新規作成して切り替える

■変更履歴のマージ

git merge <ブランチ名>
git merge <リモート名/ブランチ名>

■ブランチを変更/削除

git branch -m new_branch_name //ブランチ名の変更
git branch -d branch //ブランチの削除
git branch -D branch //ブランチの強制削除

■履歴を整えて変更をmasterに取り込む

git rebase <ブランチ名>

■タグ付コマンド

git tag //タグの一覧を表示
git tag タグ名 //タグを作成(簡易Ver)
git tag -a <タグ名> -m <メッセージ> //タグを作成(注釈付き)
git show  タグ名 //タグのデータを表示　
git push oigin --tags //リモートリポジトリにタグの送信

■作業を一時避難する

Stashとは「隠す」の意
現在行っている開発中に別の作業(バグ修正など)を
行いたいときなどに使用する

git stash //作業を一時避難する
git stash list //避難した作業の確認

■避難した作業を復元

git stash apply //最新の状況を復元
git stash apply --index //ステージの状況も復元
git stash apply <スタッシュ名>

■避難した作業を削除

git stash drop//最新の作業を削除
git stash drop <スタッシュ名>//特定の作業を削除
git stash cleaｒ //全作業を削除

何が起きたの

これまでgitクローンする方法は特に意識してなかったんですが、今回httpでクローンしたところ、cloneもpullもできるのにpushだけエラーが出るという事が起こりました。

httpでクローン

$ git clone http://[ドメイン]/hoge.git

ファイルを編集し...よし！pushだ！

$ git push origin develop
warning: redirecting to https://[ドメイン]/hoge.git/
(中略)
error: RPC failed; curl 18 transfer closed with outstanding read data remaining
fatal: the remote end hung up unexpectedly
fatal: the remote end hung up unexpectedly
Everything up-to-date

なんでやねん

error: RPC failed; curl 18 transfer closed with outstanding read data remaining

というエラーでぐぐると、どうもpushするときのサイズが小さすぎるのでサイズ増やせば解決するとのことでしたが、変わらずエラーが出てしまいます。

解決

こちらなどを参考にssh設定し、以下コマンドでクローン

$ git clone git@[ドメイン]:hoge.git

改めてファイルを再編集し、さきほどと同じpushコマンドを実行すると無事成功！やった〜！

今回の解決法はこちらを参考にしました。
https://stackoverflow.com/questions/38618885/error-rpc-failed-curl-transfer-closed-with-outstanding-read-data-remaining

そういえば今回の事象以外でもSSHでクローンしないことで、他のgitコマンドを実行したときに問題になったような...。いろいろ検証不足で恐縮ですが「クローンの方法によって後々問題が発生する」ことを忘れないように自戒も込めて記事にしました。m(_ _)m

なぜ書いたのか

Git初学者にとっては、学習する上で未知のコマンドや用語が出てきます。
自分自身の整理も兼ねてまとめました。

Git

ファイル(ソースコード)の変更履歴を管理するための分散型(※後述)
バージョン管理システム。Linuxの開発者が作成しました。

Github

オンラインでソースコードやデータを管理できるwebサービス。
Issueやプルリクエスト(※後述)など、チーム開発において不可欠な機能が多く備わっている。

repository(リポジトリ)

ソースコードや設定ファイルなど、開発に関連する諸々のデータの置き場
(repository=貯蔵場所)

※ローカルリポジトリとリモートリポジトリがある(下記)

用語	意味
ローカルリポジトリ	個人の開発環境のリポジトリ(PCなど)
リモートリポジトリ	ネットワーク上の開発環境(GitHubなど)

Decentralized and centralized(分散型と集中型)

用語	意味
集中型	ひとつのリポジトリに接続してみんなで使う(例：Subversionなど)
分散型	個人のパソコン上にリポジトリを持ち、好きなタイミングで好きなリポジトリに同期する(例：Githubなど)

Pull Request(プルリクエスト)

開発者のローカルリポジトリで加えた変更を、他の開発者に通知、コードレビューしてもらう機能です。
※コードレビューによってバグの事前抑止やコードの品質を保つことができます。
レビュー、修正が完了すればmasterブランチにマージします。

branch(ブランチ)

開発プロジェクトをチームで枝分かれして並行作業を行うための機能。(branch=枝)
ブランチは複数作成可能です。
基本的にmasterブランチは常にデプロイ(公開)できる状態に保ち、バグ修正や機能追加などの新規開発はmasterブランチから新しいブランチを作成して(ブランチを切るという)開発を行います。

Work Tree(ワークツリー)

作業中のディレクトリのこと。ファイルを変更する作業場

Index(インデックス)

リポジトリにコミット(後述)する準備をするための場所

HEAD

今自分がいる最新のコミットのこと

Add(アド)

指定したファイルをインデックスに登録してコミット対象にするコマンド

Commit(コミット)

ファイルやディレクトリの変更を、リポジトリに記録する操作(コマンド)。
(Commit=結束する)

コミットを実行すると、リポジトリの中では、前回コミットした時の状態から現在の状態までの差分を記録したコミット(またはリビジョン)と呼ばれるものが作成されます。

このコミットは、次の図のように時系列順につながった状態でリポジトリに格納されています。このコミットを最新の物から辿ることで、過去の変更履歴やその内容を知ることができるようになっています。

Push(プッシュ)

ローカルリポジトリ(あなたのPC)からリモートリポジトリ(Githubなど)に変更を反映させるための操作(コマンド)

Merge(マージ)

ブランチを統合させる操作(コマンド)。
作業終了したブランチをmasterに反映(合流)させる。※履歴が枝分かれして残っていく
(Merge=合流する)

Rebase(リベース)

ブランチを統合させる操作(コマンド)。
作業終了したブランチをmasterに反映(合流)させる。※履歴が一本化する
(Re+base=ベースの変更)

MergeとRebaseの違い

Merge	Rebase
履歴が複雑になりがち	履歴が見やすい
コンフリクトの解決が簡単	コンフリクトの解決が面倒

※pushしていないローカルの変更にはrebase、pushした後はmerge
コンフリクトが起きそうならmergeを使うのが妥当

Fetch

リモートリポジトリからローカルリポジトリに情報を取得する操作(コマンド)
(Fetch=取ってくる)
リモートリポジトリの内容を確認したいだけの時などに使う。ローカルリポジトリの内容は変更されない

Pull(プル)

リモートリポジトリの変更をローカルリポジトリに反映させること。
フェッチとマージを同時に行う操作（コマンド）

Conflict(コンフリクト )

(Conflict=競合)
別々のブランチで別々の変更をしてマージすると発生する。

gitignoreファイル

Git管理しないファイルやディレクトリを指定し除外できる
ファイル

Git-flowとは？

簡単にいうとGitのブランチを活用したGitの開発手法。
メリット...開発スピードの向上、コンフリクトやマージのミスの発生を防げる。
デメリット...開発スタート時に運用ルールを決めておかないとプロジェクトがまとまらない。
※コンフリクト....同じ箇所を別々のブランチで別々の変更をかけてマージすること。

Git-flowの５つのブランチ

1　フィーチャー......開発を行うためのブランチ。用途は個々の機能の実装やバグの解決
2　デベロップ..........開発を行うためのブランチ
3　リリース.............リリース前に準備、微調整を行うブランチ。
4　マスター............リリースしたデータをおいておくブランチ。
5　ホットフィックス......リリースされたデータに緊急の修正をするためのブランチ。

詳細

開発を進める際にデベロップからフィーチャーブランチを作成し、作業を進めていく。それが終わったらデベロップブランチにマージという工程を繰り返す。
この工程を繰り返してリリースのタイミングになったらデベロップブランチからリリースブランチを作成する。ここでのマージ先はデベロップではなくマスターブランチ。
リリース後にバグが見つかった場合、マスターブランチからホットフィックスブランチを作成しバグの対応を行う。

まとめ　　　　　　　

　　　　　　　　　　　分岐元 　　　　　　　　マージ先
フィーチャー　　　　デベロップ　　　　　　デベロップ
リリース　　　　　　デベロップ　　　　　　デベロップ・マスター
ホットフィックス　　マスター　　　　　　　デベロップ・マスター

Git-flow流れ
1 developブランチからfeatureブランチを作成して、機能・タスクごとに開発を進める
2 1. をdevelopブランチにマージする
3 1.〜2. を繰り返して開発を進める
4 全データが揃いリリースのタイミングになったら、releaseブランチを作成し、バグ修正やドキュメントの整備をおこなう
5 4. をmaster, developブランチにマージして公開する
6 もし急なバグが見つかったら、hot-fixブランチを用意して対応する
7 6. をmaster, developブランチにマージして公開する

感想

Github-flowとの違いを理解することが難しかった......
完璧ではないがある程度は理解できたと思っています。

参考サイト
https://liginc.co.jp/248864
https://tracpath.com/bootcamp/learning_git_git_flow.html

はじめに

ググるとlibcurl-develをリンクしろというのが多くひっかかりますが、libcurl-develをリンクしていてもエラーが出るケースがあります。

例えば、最小のgit環境を作ろうと、以下のようにした場合、

Dockerfile

FROM centos:7 AS src
RUN yum install -y  git
FROM centos:7
COPY --from=src /usr/bin/git /usr/bin/git
ENTRYPOINT ["/bin/sh"]

centos7のgitはhttpsにも対応しているのですが、できあがったコンテナではhttpsが利用できません。

# git clone https://github.com/qualitiaco/action-lambda-build-pack-sample.git
Cloning into 'action-lambda-build-pack-sample'...
warning: templates not found /usr/share/git-core/templates
fatal: Unable to find remote helper for 'https'

原因

文字通り「remote helper for 'https'」というのがないのが原因です。

これは、git-remote-httpsという名前で、/usr/libexec/git-coreの下にあります。

# ls -l /usr/libexec/git-core/git-remote-https
-rwxr-xr-x    4 root     root       1495272 Dec 10 21:39 /usr/libexec/git-core/git-remote-https

解決方法

/usr/libexec/git-core/git-remote-httpsをコピーします。

OSによってはgit-remote-httpへのsymlinkになっている場合もあるので、その場合、git-remote-httpもコピーします。

確認

Dockerfile

FROM centos:7 AS src
RUN yum install -y  git
FROM centos:7
COPY --from=src /usr/bin/git /usr/bin/git
COPY --from=src /usr/libexec/git-core/git-remote-https /usr/libexec/git-core/
ENTRYPOINT ["/bin/sh"]

# git clone https://github.com/qualitiaco/action-lambda-build-pack-sample.git
Cloning into 'action-lambda-build-pack-sample'...
warning: templates not found /usr/share/git-core/templates
remote: Enumerating objects: 103, done.
remote: Counting objects: 100% (103/103), done.
remote: Compressing objects: 100% (49/49), done.
remote: Total 103 (delta 30), reused 89 (delta 21), pack-reused 0
Receiving objects: 100% (103/103), 11.33 KiB | 0 bytes/s, done.
Resolving deltas: 100% (30/30), done.

動きました。

alpineでもっと小さく

alpineだと、もっと小さくなりますが、追加でいくつかファイルが必要になります。

Dockerfile

FROM alpine AS src
RUN apk add git
FROM alpine
COPY --from=src /usr/bin/git /usr/bin/git
COPY --from=src /usr/lib/libpcre2-8.so.0 \
                /usr/lib/libcurl.so.4 \
                /usr/lib/libnghttp2.so.14 \
                /usr/lib/
COPY --from=src /usr/libexec/git-core/git-remote-https /usr/libexec/git-core/
COPY --from=src /etc/ssl/certs/ /etc/ssl/certs/
ENTRYPOINT ["/bin/sh"]

これで動きます。

おわりに

git cloneで「fatal: Unable to find remote helper for 'https'」のエラーが出る場合についての、libcurl-develを入れて再コンパイルしましょう、では解決いない場合の解決方法について説明しました。

*本記事は @qualitia_cdevの中の一人、@hirachanさんに作成して頂きました。

課題

submoduleを持つリモートリポジトリをローカルにgit cloneした際に、submoduleがあるはずのフォルダが空になっている。

解決

git cloneした後に、以下のコマンドを打つ

git submodule init

git submodule update

該当のフォルダをlsするとsubmoduleのフォルダやファイルがきちんと存在している。