【gitが素人でも簡単】オフラインでアプリインストール不可のPCでも、gitでソース管理したい



# 概要

コンプライアンスの要件が厳しかったり、SSHサーバが立てられなかったり、~~上司がソース管理の必要性が理解できていない~~などの理由で、ファイルサーバの設定権限を一切持てないような、辛い立場に置かれている人のための記事。

そんな状況でも、設計効率をちょっとでも上げたいと思い、「オフラインでもgitが使えるかもしれない・・・」と導入を検討し始めるが、

**「なんかgitって、そもそもインターネットのサービスや専用のファイルサーバが使えないんじゃ・・・」**
と思えてしまう記事が普通に多くて、色々調べてみるも、結局導入にあきらめてしまう。
それでは、どれだけ経っても、開発の効率があげられない・・・。

なので、
**そもそも、インターネット繋がなくてもgitは使える。**
ということを、この記事で伝えたいです。

※私もどうしたらいいか、結構試行錯誤しながらやってきた経緯があって、
　もしおかしい点があれば、連絡ください。

### 注意

git, mercurial, Subversion専用のファイルサーバがすでにあったり、Webサービスを使っている場合は、そちらを使いましょう。

と言っても、自社専用のファイルサーバしか用意できていない場合などもあると思うので、他社間で作業される場合、この記事が有効な時もあると思います。

## 前提

例えば、こういう条件で開発しなくてはいけない、って状況はありませんか。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/281173/beed508a-c9bf-26bf-f962-c3215d3455a2.png)

開発者は専用PCを持っていて、一方で作業用のPCもあるのだけど、それは例えば専用の機械に繋がっていたり、データ情報漏洩の対策が打たれていてネットに接続できない仕様だったり。

こういうとき、gitを使った解決策は2つあり、

**(1) USBメモリや外付けHDD・SDDなどにベアレポジトリを作る
(2) git用のバンドルファイルを使う**

があります。
今回は、当たり前すぎて語られない(1)に関しての解説記事です。

(2)は多少ステップを踏むので、解説記事があるのはまあ分からなくもないのですが、
(1)はgitが標準的に使われている開発環境では「そんなん当たり前に出来ることちゃうん？」という声が聞こえてきそうです。

**だけど、gitを標準的に使ってこなかった開発環境では、(1)という選択肢があることすら把握できない！！**
その割に、githubのリモートリポジトリとやり取りする方法とかはよく書かれているわけで、「ああ、私たちが使っている世界とは違うんだな・・・」と感じて、ソース管理を諦めてしまう・・・という悲しいことが起きるのです・・・。

**もう一つ、混乱のもとになるのが、SourceTreeやGitKrakenなどに代表されている”gitを分かりやすくするソフト"(クライアントツール)"です。**
これらを使えば、gitが使えるんだな～と言う理解になってしまい、オフラインで使う場合に**「あれ？入門書読んでプッシュしたけど同じようにプッシュできないぞ？」**ということが起きてしまいます。

~~ちなみに、別にプッシュなしでコミットだけでも使えなくはないけど、プッシュやマージなどは非常に便利なので、使えれば使ってあげたい。~~

やってて気づいたのですが、特定の手順をきちんと踏まないと、git pushすることが出来ません。
これもオンライン環境に相当するリモートリポジトリが用意されていないだけなのですが、このことに気づかず試行錯誤で作業してしまうことがあります・・・・。

## インストール

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/281173/f01aafbb-fa9d-9355-b2f5-bbe96bad08fc.png)

専用の外部ストレージを用意し、GitとSourceTreeをインストールします。

Git *Portable Git版も可
https://git-scm.com/download/win

SourceTree
https://www.atlassian.com/ja/software/sourcetree
SourceTree Portable(非公式)
https://github.com/cosmomill/SourceTreePortable/releases/tag/2.0.19.1.0

GitやSourceTreeをPortable版にするか否かは実はどちらでも良いのですが、

* ソース管理用の外部ストレージを専用に持っておくのが効率良いと思う
* 非Portable版は、いくつか設定があって面倒

ってことで、今回はPortable版で説明します。
バージョンはSourceTree Portableが2.0.19.1、Portable Gitが2.31.0です。

インストールするとこんな感じ
Reposフォルダは適当に作りました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/281173/33fcb2a2-c456-757f-f13f-9c9522585b39.png)



## ベアリポジトリの作成

何か新たな開発プロジェクトが始まったら、ベアリポジトリを作成しておきましょう。
このベアリポジトリは、複数台のコンピュータを使って開発する際には便利なものです。

注意として、ここでSourceTreeから直接「Create（新規）」しないことです。
多少面倒ですが、CUIを使います。CUIは同じ機能しか使わないので、慣れれば楽です

※注：先に、SourceTreeでCreateを選択してコミットし続けたのはいいものの、あとで共有が必要になったり、プッシュ・チェックアウト・マージなどが必要になってベアレポジトリが必要になった場合は後述します。

git-cmd.exeを実行

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/281173/ce14fcd5-4e83-a6c4-0c9f-cbe1374d087f.png)

自分の名前を登録しておく(初回のみ)

```
D:\PortableGit> git config --global user.name (自分の名前)
D:\PortableGit> git config --global user.email (自分のメールアドレス)
```

新たなリポジトリを作る
D:\Repos\test.gitにベアリポジトリが作られます。

```
D:\PortableGit> cd D:\Repos
D:\Repos> mkdir test.git
D:\Repos> cd test.git
D:\Repos\test.git> git init --bare

hint: Using 'master' as the name for the initial branch. This default branch name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint:
hint:   git config --global init.defaultBranch <name>
hint:
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint:
hint:   git branch -m <name>

Initialized empty Git repository in D:/Repos/test.git/
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/281173/27eb5c86-8ffd-38b9-df4a-7962918d08cc.png)

※エラーが気になる場合は、以下の一文を入れてみましょう。

```
git config --global init.defaultBranch master
```


## クローン、コミット

ここからはSourceTreePortableを使います。

### クローン

C:\testgit\testに、先ほど作ったtest.gitのベアレポジトリを参照してクローンする場合。
以下のように入力してクローンします。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/281173/67c4cfa6-0730-f8ed-37a9-7e513e618d30.png)

### コミット

例えば、ReadMe.txtというファイルをC:\testに追加したとして、コミットします。
するとSourceTreeには、ReadMe.txtが変更したことが告げられます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/281173/d9057605-da8e-1f41-b88e-ffdd289b8ce6.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/281173/46afb967-ab84-9de5-1d17-8b6d216012f6.png)

コメントを入れて「コミット」ボタンを押すと

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/281173/935eb22c-fcbc-8954-2c35-8c2ee89cd3ae.png)


## プッシュ、プル

プッシュはこんな感じ。
なお、プッシュは後述するように、ベアリポジトリが作れていない場合はできません。これを直す方法は後述します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/281173/2608f3b7-dec8-356b-2dbb-dc4a4676f87e.png)

他のPCとの変更履歴を共有する場合は、プルを使用します。

以上の流れは、gitの解説に山ほど載っている内容ですので、この記事での紹介はこの程度にしておきます。

## 後からベアリポジトリが必要だと気付いた場合

例えば、操作を間違えたとか、CUI操作が面倒だった、しばらくの間は共有の必要性がないと感じていたとかとかいろいろあって、あとになってベアリポジトリが必要になった！というケースもありうると思います。

その場合、新たなベアリポジトリを作成しなおして、それを直接プルによって管理することが出来ます。


とあるローカルレポジトリがあって、それがC:\testgit\anotherpc\test3\に管理され続けてきたとします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/281173/894ca525-b82b-73ed-d236-52a551229a03.png)

ベアレポジトリを作ります。
D:\PortableGit\git-cmd.exeを開いて、次のように入力

```
D:\PortableGit> cd D:\Repos
D:\Repos> mkdir test3.git
D:\Repos> cd test3.git
D:\Repos\test3.git>git config --global init.defaultBranch master
D:\Repos\test.git> git init --bare
Initialized empty Git repository in D:/Repos/test3.git/
```

SourceTreeで、クローン
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/281173/09a4b536-db4f-d110-9c54-a0442c164ce0.png)

**CUIに再び戻って、次のように入力。**
(こういうこと出来るの、なかなかすごいですね。)

```
C:\testgit\test3>git pull ..\anotherpc\test3
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/281173/2ab00f46-dac8-9e6a-3fde-1c3754f8b2c0.png)


無事SourceTreeで開くと、前までのコミットを残しながら、ベアリポジトリを作成できました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/281173/64171225-08ba-ba16-39d9-9562fe47eada.png)


なので、当面はこのようにしてコミットだけを続けておいて、コーディングレベルで、複雑な作業が発生しそうなときには、あとでベアリポジトリにして変換することも可能です。