プロジェクトをコピーしてそれぞれ別物として運用したいときになど！

git clone --mirror git@github.com:a.git hoge
git clone --mirror 複製元のgithubのリポジトリurl 複製先のフォルダ名 


cd 複製先ローカルフォルダに入る


※※ githubで複製先のリモートリポジトリを新しく作っておく ※※


git remote set-url origin git@github.com:複製先.git


git push --mirror origin

＊この記事では、GitHubDesktopを使用しています。

---

自作したゲームのプロジェクトをGithubでpushしたら、こんなエラーが起きました。

error: RPC failed; curl 55 Send failure: Connection was aborted

「データサイズが大きすぎて送れなかったファイルがある」ということらしいです。
Gitは元々キロバイト単位の使い方が基本の為、画像や動画、ゲームプロジェクト等の大きなデータを扱うのには不向きなもの。

GitLFS(GitLargeFileStorage)とは

GitHubで、大サイズのデータでも扱える様にしてくれる拡張機能。
ファイルのメタ情報だけをgitで保存し、ファイルの実態はリモートサーバーで管理する仕組みです。

導入方法

Lfsを使用する為には、各リポジトリに対してインストールを行う必要があります。
_
1.ダウンロードページからインストーラーを入手する。

2.落とせた後、GitHubDesktopからlfsを使用したいリポジトリでコマンドプロンプトを開く。

3.コマンドラインに

$ git lfs instal

と入力。
リポジトリのあるディレクトリに.gitattributesが作成される。

これで準備は完了です。
LFSを使って、ファイルの保存が行える様になりました。

使用方法

先ほど作成された.gitattributesを開いてみると、

何も入力していないので、まだ中身は空っぽ。
この中に、次の方法でファイルを追加していきます。

---

コマンドプリンプトで、

git lfs track ”*拡張子”

を入力することで、
特定の拡張子データがトラックされる。

例えばpsdをトラックするなら、

git lfs track "*.psd"
Tracking”*.psd”

こうなれば成功。
.gitattributesを見てみると、

psdが追加されました。

こんな調子で、データサイズの大きいモノを追加していきます。
UE4のプロジェクトだと、主に以下。

.uasset
.uproject
.wav
.fbx（引用）

追加できたら、変更が反映されているかGitHubDesktopで確認。

しっかり認識できてるみたいなので、comitしたらpushして完了です。

メモ

そもそも今回LFSを使うことになったのは、プロジェクトのリポジトリをゲーム作成してから完成まで一回もコミットしてなかった為、最終的なデータサイズが大きくなりすぎた事が原因でした。
そもそもGitとしての使い方をしてなかったのが問題なので、もっと使う機会増やして覚えます…

前提

• Mac を使っている
• Git インストール済
• Docker インストール済

できること

• Laravel8の開発環境が構築できる
• phpMyAdminでDBを参照できる

手順

1. Laradockをローカル環境に複製し、環境設定ファイルを編集する
2. Dockerコンテナを起動し、コンテナに入る
3. Laravel８をローカル環境にインストールし、環境設定ファイルを編集する
4. Laradockの環境設定ファイルを編集し、Dockerコンテナ再起動
5. Laravel8とphpMyAdminの表示を確認する

※コンテナはnginxとPHP-FPM、MysqlそしてphpMyAdminを用意します

構築する

1. Laradockをローカル環境に複製し、環境設定ファイルを編集する

Laradockを複製（複製場所は"/Users/任意の名前"）

git clone https://github.com/LaraDock/laradock.git

環境設定ファイル（.env）を編集

cp env-example .env
vim .env

編集箇所と内容

DATA_PATH_HOST=.laradock/data
COMPOSE_PROJECT_NAME=project_name
MYSQL_VERSION=5.7.31

ファイル末尾に追記

DB_HOST=mysql

2. Dockerコンテナを起動し、コンテナに入る

Dockerコンテナを起動

docker-compose up -d nginx mysql phpmyadmin
docker-compose ps

Dockerコンテナに入る

docker exec -it river_web_workspace_1 bash

3. Laravel８をローカル環境にインストールし、環境設定ファイルを編集する

Laravel８をローカル環境にインストール（ディレクトリ名はsrc）

composer create-project laravel/laravel src

環境設定ファイル（.env）を編集

vim .env

編集箇所と内容

DB_HOST=mysql
DB_DATABASE=default
DB_USERNAME=default
DB_PASSWORD=secret

4. Laradockの環境設定ファイルを編集し、Dockerコンテナ再起動

exit
vim .env

編集箇所と内容

APP_CODE_PATH_HOST=../src

docker-compose up -d nginx

5. Laravel8とphpMyAdminの表示を確認する

http://localhost/
http://localhost:8081/

データベース名：mysql
ユーザー：default
パスワード：secret

※DB編集する際は、先ずはルートではいり、上記ユーザーに編集権限を付与します

データベース名：mysql
ユーザー：root
パスワード：root

以上になります。

はじめに

この記事では、git sumoduleの基本的な使い方についてまとめました。

参考

この記事は以下の情報を参考にして執筆しました。

• git submoduleの基礎
• 7.11 Git のさまざまなツール - サブモジュール

git submoduleとは

git submoduleとは、外部のgitリポジトリを自分のgitリポジトリのサブディレクトリとして登録し、特定のcommitを参照する仕組み。

基本的な使い方

作業中のリポジトリのサブモジュールとして既存のリポジトリを追加する。
サブモジュールを新たに追加するには以下のコマンドを実行する。
追跡したいプロジェクトのURLを引数に指定する。

git submodule add URL


デフォルトでは、このコマンドでしていしたリポジトリと同名のディレクトリにサブプロジェクトのデータが格納される。

約2年プログラマーやってきて実際によく使っているGitをまとめました。

ローカルとリモートって言われても未だにピンと来ないポンコツですが、
originと開発環境で理解して何とかやってきました←
同じ様な人がいるかもしれないのでそのまま記載していきます。

開発環境のmasterを、強制的にoriginのmasterに合わせる

▼ originのmasterの最新を取ってきて
git fetch origin master
▼ originのmasterに強制的に合わせる！
git reset --hard origin/master

作業中だけどpullした状態で進めたい時

（下記ではmasterブランチを指定しています）

▼ 退避して
git stash
▼ pullして
git pull origin master
▼ 適応させる
git stash apply

addしてしまったファイルを戻す

git add . で一気にaddした後で、上げたくないファイルがあること思い出した時。

git reset ファイル名

編集したファイルを編集前に戻す

（新しく作ったファイルは追跡されていないのでrmで削除する必要あり）

git checkout ファイル名
▼ 全て戻したい場合は「ファイル名」部分を「.」にします
git checkout .

push前の、直前のコミットを取り消したいとき

（ファイルの編集内容は 保持 したい時）

git reset --soft HEAD^

push前の、直前のコミットを取り消したいとき

（ファイルの編集内容も 破棄 したい時）

git reset --hard HEAD^

ブランチにマージする

（下記ではmasterブランチにdevelopブランチをマージしています）

▼ マージしたいブランチに移動
git checkout master
▼ マージ
git merge develop

originにあるブランチを開発環境に作りたいとき

（下記ではdevelopブランチをしています）

▼ originの最新を取ってきて
git fetch
▼ originのdevelopブランチを指定して、developブランチを作成
git checkout -b develop origin/develop

最後に言い訳

現在所属している会社では自宅勤務のこと「リモート」って呼んでいるので、
「リモート」と聞くと 自分のところ 感があるんですよね。（知らんがな）

概要

ローカルのブランチをGithubに挙げることはできていたが、「There isn’t anything to compare.main and master are entirely different commit histories.」という注意書きが表示され、マージできなかった。３時間くらい格闘して、正しいやり方ではない気がするができたので一応書いておく。

コード

$.git pull --allow-unrelated-histories origin main
$.git push --set-upstream origin master:main

説明

①$.git pull --allow-unrelated-histories origin main
これでgithubのmainブランチをローカルのマスターブランチに持ってくる。
おそらくだがこのコマンドによってローカルとリモートの関係ができ、マージできるようになる。
②$.git push --set-upstream origin master:main
これでローカルのmasterブランチをリモートのmainブランチにプッシュできる。
originはリモートのことを指しているらしく、最後の「master:main」のところは前者の部分にローカルのブランチ名、後者にリモートのブランチを書けば、それぞれ任意のプッシュ元、プッシュ先を指定可能になる。

また、プルするリモートのブランチとプル先のローカルのブランチでコンフリクトが起きている場合、①と②の間できちんとコンフリクトを解消しないと②がきちんと機能しなくなるので注意。

参照記事

１．https://hacknote.jp/archives/31307/
２．https://qiita.com/takanatsu/items/fc89de9bd11148da1438
３．https://qiita.com/Lnest/items/9e0f1780ee96b05a0cd4（これはGitの使い方の基礎をまとめたもの）

目的

• CentOS7にGitを導入する方法をまとめる

方法

1. 下記コマンドを実行してGitをインストールする。

   $ sudo yum install git
   

2. 下記コマンドを実行してcommand not foundが出ないことを確認する。

   $ git --version
   

共同開発を初めて、初期に出たエラーです。
なんとも簡単なエラーですが、自分の戒めとして備忘録として載せておきます。

プロテクトされたブランチにプッシュしちゃった

ターミナル

git push origin HEAD
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 1000 bytes | 1000.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
remote: error: GH006: Protected branch update failed for refs/heads/develop.
remote: error: At least 1 approving review is required by reviewers with write access.
To https://githubのURL
 ! [remote rejected] HEAD -> develop (protected branch hook declined)
error: failed to push some refs to 'https://githubのURL'

本来なら新しいブランチを切って、そこから開発用であるdevelopブランチにプッシュするのですが、ロックされているdevelopブランチに直でプッシュしちゃいました。
１つのエラー事例として参考になれば幸いです。

複数の作業ブランチがあり、その中から特定コミットを反映させたい。
しかし、リリースの日程調整上、全てマージするわけにはいかないと言ったこともあり得ます。
このコミットの内容だけ欲しいのになぁという場面で使えます。

cherry-pick

// これを実行するとコミットまで実施される。
git cherry-pick 1fdc89d0

// コミットはせずステージングにあげる
git cherry-pick -n

// 名前を指定する
git cherry-pick -e

// 複数コミットに対して行う(1fdc89d0 ~ 546fc501の間のコミットを対象に)
git cherry-pick 1fdc89d0..546fc501

コミットIDの調べ方

git log

コンフリクトが起きた

コンフリクトの解消をしたら下記で処理を再開できる

git cherry-pick --continue

// やめる時
git cherry-pick --abort

cherry-pickは再使用できない

これはすでにcherry-pickしようとしているコミットIDがブランチに記録されている場合の話。
例えばあるコミットでデグレを起こし、該当箇所をrevertし解消した後Pushしたとする。
この後、再度ローカルブランチで一部コミットだけをcherry-pickして修正を加えるなどができない。そのコミットは履歴に組み込まれているという認識になるため。

こんな場合にも使えるのがcheckout。

checkout branch名 -- file名 で該当ファイルの内容を引っ張る

git checkout branch名 -- file名

これならcode内容をとってくるだけなので、自分で新規コミットを作る形になる。