やりたいこと

• サイズの大きいファイルを含むgitリポジトリをGitHubの様なクラウドサービスにではなく自前のストレージで保管したい。

• ローカル内のUbuntu(192.168.0.10)にdockerでLFS Test Serverをインストール。SSH経由でUbuntuにgitリポジトリを作り、作業マシンでclone、LFSの設定をする。

手順

• 以下のDockerfileを作り、LFS_HOST・LFS_ADMINUSER・LFS_ADMINPASS等の環境変数を書き換えておく。その他の変数はLFS-Test-Serverのgitページに書いてある。LFS_HOSTで指定したホスト名でアクセスを受け付ける。LFS_HOSTはIP以外にもavahi名でもいけたりする。

Dockerfile

FROM ubuntu
SHELL ["bash", "-c"]

ARG GOLANG_URL
ENV LFS_HOST=192.168.0.10:8080
ENV LFS_ADMINUSER=admin
ENV LFS_ADMINPASS=passwd
ENV PATH $PATH:/usr/local/go/bin:/lfs-test-server

RUN apt update && apt upgrade -y && apt install wget git -y
RUN wget $GOLANG_URL -O - | tar -C /usr/local -xzf - && echo -e "\n\n# Add golang to path\nexport PATH=\$PATH:/usr/local/go/bin:/lfs-test-server" >> ~/.bashrc && go version
RUN git clone https://github.com/git-lfs/lfs-test-server.git && cd lfs-test-server && go get github.com/github/lfs-test-server && go build
CMD ["bash", "-c", "cd /lfs-test-server && ./lfs-test-server"]

• Dockerfile内で記述したGLANG_URL引数にGoのlinuxバイナリのダウンロードURLを設定してビルド。

docker build --build-arg GOLANG_URL="https://golang.org/dl/go1.15.3.linux-amd64.tar.gz" --tag=lfs-test-server .

• buildしたdockerイメージをポート8080と1080を解放してrunする。

docker run -it -p 1080:1080 -p 8080:8080 --restart=always --name=lfs-test-server lfs-test-server

• Ubuntu上にgitベアリポジトリを作る

Ubuntu

mkdir test.git
cd test.git
git init --bare --shared

• ブラウザで192.168.0.10:8080にアクセスするとBasic認証が求められるのでDockerfileで設定したLFS_ADMINUSERとLFS_ADMINPASSでログイン。管理画面からユーザーを追加する。

• 作業マシンでリポジトリをクローンしてLFS設定、PUSHしてみる。

作業マシン

git clone ubuntu_user@192.168.0.10:test.git
cd test
git lfs track *.mp4
git config -f .lfsconfig lfs.url http://192.168.0.10:8080/
git add -A
git commit -m "test"
git push

pushするとユーザーとパスを求められるので先ほどの管理画面で追加したユーザーとパスを入力するとpush処理が行われる。

状況

リモートリポジトリで追跡しているブランチを変更したい場合。
私は、
1. create-react-appでプロジェクトを作成してからmasterブランチにpush
2. masterブランチからdevelopブランチを作成し、developで作成中のコードを管理
ということをよくするので必要な作業。

リモートで作成されたブランチはローカルに反映されているか？

ローカルからリモートブランチを作成した場合は問題ないが、GitHubのGUIなどからリモートでブランチを作成した場合、作成したブランチはローカルに認識されていない可能性がある。
以下のコマンドを実行して、表示されたブランチの中に新しく作成したリモートブランチが存在するかを確認する。

$ git branch -a

存在しない場合、次の章の手順を実行する。存在する場合は次の章の手順はとばす。

リモートの変更をローカルに反映

以下のコマンドを実行。

$ git fetch

ブランチの切り替え

以下のコマンドを実行してブランチを切り替える。

$ git checkout -b ローカルのブランチ名 origin/リモートのブランチ名

ローカルのブランチ名がmain、リモートのブランチ名がdevelopである場合の具体例を以下に示す。

$ git checkout -b main origin/develop

注意

本記事の内容はGitHubでリポジトリを作成した際に、README.mdに記載されている内容である。

ローカルリポジトリの作成とファーストコミット

作業ディレクトリにローカルリポジトリを作成し、作成したローカルリポジトリにコミットしておく。
以下のコマンドを順に実行。

$ git init
$ git commit -m "first commit"

リモートリポジトリを指定してpush

ローカルリポジトリとリモートリポジトリを接続するため、git remote addコマンドでリモートリポジトリを追加する。
さらに追加したリモートリポジトリに、先ほどローカルリポジトリにコミットした内容をpushする。
以下のコマンドを順に実行。
※初めのコマンドはブランチ名のリネームをしている。リネームする必要がなければ、実行は不要。

$ git branch -M main
$ git remote add origin リモートリポジトリのURL
$ git push -u origin main

当たり前のこと

git merge --no-ffはmerge commitを明示的に行うコマンドなので、
commit画面が出てくるのは当たり前のこと。
それで良い。この動作が正常。
要はmerge.ff=falseしてると起こる。

記事のターゲット

・gitについてよくわからないけど、とりあえず使っていけばなんとかなるかな、と考えている人。
・先輩がなんとなくやっているから、そういう設定にした、なんかワンラインで書く時にcommit画面出てきてめんどくさいな、と思っている人。

環境

$ git config -l
alias.ci=commit
alias.st=status
alias.br=branch
alias.co=checkout
merge.ff=false
pull.ff=only

(不要の部分は削除した。)

git mergeには大きく２種類ある。

コンフリクトや３ウェイマージ周りの話はしません。
要は、多くの場合、mergeをする場合、事足りるのでデフォルトがFAST-FORWARDの設定になっている。
が、多くの諸先輩方は、git merge --abortなどでcommit後に前バージョンに戻りたい事柄が多かったか、それでトラブったケースがあるので経験談からとりあえず--no-ffしとけという話。
（やってみればわかると思うけど）

FAST-FORWARD MERGE

直訳：早送りマージ

詳細は上記本家リンクに任せるとして、重要なのは下記かなと。

・特別な設定がない場合、git merge -にて選択される手法はこっち。
・マージされたブランチにマッチするようにブランチポインタを更新するだけで、マージコミットは作成しません。
・できない場合 (マージされた履歴が現在の履歴の子孫ではない場合)、マージコミットを作成します。
・この動作は、--no-ffオプションで抑制でき、すべての場合にマージコミットを作成します。

TRUE MERGE

直訳：真のマージ

詳細は上記本家リンク
・マージされるブランチは、両方を親として持つマージコミットによって結合される。
・マージされるすべてのブランチからの変更を調整するマージされたバージョンがコミットHEADされる。
・複雑な競合が発生したマージを試みて、最初からやり直したい場合は、git merge --abortで回復できる。（らしい）

回避方法

何もむずかしくない、git merge - -m 'message'するだけ。

ワンラインサンプル

$ git co - && git merge - -m 'merge branch into main' && push origin HEAD

コメント

先達は偉大だ。
基本的には特にこだわりはなくオススメ設定を受け入れさせてもらっている。
それでもなんでだろ？と思ったことはちゃんと調べていきたいと思います。

References

Git公式ドキュメント
gitのmerge --no-ff のススメ

ブランチの作り方

$ git checkout develop

$ git checkout -b 作成するブランチ名

$ git push -u origin 作成したブランチ名

プルリクエスト作成方法

1.以下のコマンドを実行する。

$ git add .

$ git commit -m "コミット内容"

$ git push origin develop

2.右上の緑色のCompare & pull requestボタンをクリック。

3.プルリクエスト内容を記入する。

4.どのブランチからどのブランチにpull requestするかを確認する。

-例-
developブランチからsampleブランチへのpull request

sample ... develop

5.「Create pull request」ボタンを押して、Pull Requestを作成。

最新情報をローカルに反映させたい時

1.commit、pushまで終わらせた状態で以下のコマンドを実行する。

git checkout develop

git pull origin develop

git checkout 開発用ブランチ

git merge origin develop

2.もし、コンフリクトが発生した場合は、以下を実行する。

# コンフリクト内容を解消した上で、、
$ git add .

$ git commit -m "コミット内容"

$ git push origin 開発用ブランチ

$ git merge origin develop

概要

Xcodeでプロジェクトを作成した際に、.gitignoreが作成されないままinitialコミットされるので、.gitignoreを追加して再コミットする。

手順

.gitignoreの生成

以下のサイトでXcode用の.gitignoreを生成し、プロジェクトに追加する。
https://www.toptal.com/developers/gitignore

initial commitの取消

initial commitはgit resetではなく、以下のコマンドで取り消し可能。
取り消し後、再度コミットし直す。

git update-ref -d HEAD

GitとGitHub用語集(初心者用)

Gitとは

Gitとは、プログラムソースなどの変更履歴を管理する分散型のバージョン管理システムのこと。プログラムの編集などができ、変更履歴も管理することが出来る。Gitがあることにより、昔の状態をみたり、復元したりが簡単になる。

GitHubとは

GitHubとはGitを利用した、開発者を支援するWebサービス。　GitとGitHubの違いに私も最初は混乱しましたが、Gitはツールの名前で、GitHubはGitを使ったWebサービスの名前。

リポジトリ(repository)

いわゆる貯蔵庫のこと。システムの開発プロジェクトに関連するデータの一元的な貯蔵庫を意味する。一種のデータベースで、各工程の様々な情報を管理することが可能。

ローカルリポジトリ(local repository)

Gitのリポジトリはローカルリポジトリとリモートリポジトリに分けられる。ローカルリポジトリは自分のマシン内に作られ、ワーキングツリーが所属するリポジトリのこと。※ワーキングツリーに関しては後ほど説明あり

リモートリポジトリ(remote repository)

自身の手元側にあるローカルリポジトリに対して、外部にあるリポジトリのことを指す。サーバなどネットワーク上にあるリポジトリもそれに当たる。公開、共有がスムーズなので複数人での開発に使われたり、個人開発でもネットワーク状にデータを保存したい時、共有したい時に使う。

フォーク(fork)

forkはGitHubが提供する機能の一つ。fork は他の開発者のリポジトリを github上でclone(クローン）する。また、forkは、fork元への貢献を前提とする。開発を援助する前提の上で使う必要がある。

クローン(clone)

クローンとはリモートリポジトリを手元のマシンの指定した場所に複製する。

イニット(init)

一言でいうとリポジトリを新規作成、空のレポジトリが作成される。また、すでに存在するリポジトリの初期化をしたい場合にも使われる。

ワーキングツリー(working tree)

Gitの管理下に置かれた、自分が実際に作業をしているディレクトリのこと。作業ディレクトリ、ワークツリー、様々な呼ばれ方をする。

インデックス(index)

インデックスとは、コミットする前に更新内容の一時的な保存をする場所のことで、ステージとも呼ぶ。

アド(add)

ワーキングツリーにあるファイルの更新内容を、インデックスに反映するためのコマンド。コミットする対象を登録する作業。

コミット(commit)

追加・変更したファイルをリポジトリに記録。ゲームのセーブみたいな感じ。

コミットメッセージ(commit message)

コミットした内容を記述する。変更内容の要約、変更した理由（内容、詳細）などを記述する。

ヘッド(HEAD)

今いるブランチの最新のコミットの代名詞を指す。デフォルトではmasterの先頭を表し、HEADが移動することで、使用するブランチが変更される。

プル(pull)

リモートリポジトリのコミットをローカルリポジトリに送り込む。データのダウンロードのようなもの。

ブランチ(branch)

プロジェクトを分岐させることにより、プロジェクト本体に影響を与えずに開発を行える機能。ブランチにより、不具合が発生した場合も対応しやすく、１つのプロジェクトを同時進行で作業が可能。また、ブランチには下の画像のように複数種類がある。

マスターブランチ(master branch)

プロジェクトの本流のブランチで、リポジトリに最初のコミットを行うと、masterという名前のブランチを作成される。その後のコミットはブランチを切り替えるまでmasterブランチに追加されていく。

マージ(merge)

加えた修正を統合する作業をする。変更を加えたブランチを元のブランチにマージして修正する。

リセット(reset)

最新のコミットを取り消すまた、ステージされたファイルを取り消す。

リバート(revart)

取り消したいコミットに対して、それを打ち消すようなコミットを新しく作成する。ただ、既存コミットの履歴が消えるわけではなく、コミットログには残っている。

リベース(rebase)

指定したコミットをブランチを変えて作り直すことが可能。また、コミットをひとまとめにしたりして、ログを綺麗にするコマンド。

スタッシュ(stash)

コミットせずに変更を退避したいときに使用。あるブランチで作業中だけど、いますぐやりたいことができた時、作業するブランチを間違えてしまった時にコミットしていない変更を一時退避することが出来る。

コンフリクト(conflict)

Gitの場合同じファイルの同じ場所への変更が同時にある時に生じるエラーのことを指す。

フェッチ(fetch)

リモートリポジトリの最新の履歴の取得を行う。取得を行うのみなので、マージが自動で行われないのがpullとの違い。

チェックアウト(checkout)

今作業しているブランチから出て、他の作業ブランチで作業をしたい場合に使用するコマンド。

プッシュ(push)

ローカルリポジトリの内容をリモートリポジトリに反映させる。

プルリクエスト(pull request)

開発者のローカルリポジトリでの変更を他の開発者に通知するGitHubの機能。会社やチームでコードレビューする時に使用。

Gitでブランチの派生元を最新版に変更する

rebaseコマンド
Gitでブランチの派生元を最新版に変更するにはrebaseコマンドを使用する。rebaseコマンドは、Gitでブランチを作成した後に派生元に変更があった際に、派生元を最新版のものに変更することができる。rebaseコマンドの使用方法は以下の通り。

使用例
リモートのdevelopブランチより作成したfeatureブランチがある想定。
developブランチに変更があったためrebaseコマンドで派生元を最新版に変更してみる事に。

git rebase origin/develop

以上で派生元が変更される。ちなみに競合などがあった場合は手作業で修正を行う。修正が完了したら以下のコマンドを入力する。

git add <file>

git rebase --continue

これで派生元を最新版に変更することが可能。

git pullしたら、

git: error: unable to locate xcodebuild, please make sure the path to the Xcode folder is set correctly!
git: error: You can set the path to the Xcode folder using /usr/bin/xcode-select -switch

とかでた。

ああ、最近MacのOSアプデしたなと。

色々やったのですが、そもそもXcodeがインストールされてなかったので、
AppStoreからXcodeをインストールしたら治りました。