GithubでPrivate Repositoryを始めてみる

2020年3月14日

さて最近のソースコード管理といえばGithubですね。これまで無料で使うには「Public Repository」しかななく、全世界にゴミコードが公開されてしまうと恥ずかしいので利用してきませんでしたが（誰もみちゃいないですが。。）、マイクロソフトに買収されちゃった後、全世界に公開されない「Private Repository」も無料である程度使えるようになりましたので、その簡単な手順を初心者の視点でまとめてみたいと思います。

業務でチームで開発していると粗相しちゃうと無駄な工数が発生しちゃいますので、IT業ではプログラム知識以前に必須のツールですね。github以外にもgitを使ったサービスがたくさんありますが、基本は同じですね。

そもそもGitって何？

私の理解では「分散型」ソースコード管理システムですね。gitとgithubはちょっと違っていて、gitはプログラムそのもの、githubはgitをリモートリポジトリとして提供しているサービスですね。「分散型」なのは自分のPCの「ローカルリポジトリ」内でいろいろブランチを変更するとフォルダ内のファイルがちゃんと変わるのをみると実感できるのではと思います。

Gitの一番難しい点は非常に柔軟なシステムなので、色々な運用が可能、という点ではないでしょうか。メリットでもありますね。git-flowと呼ばれるオススメ運用方法などがありますので、まずはそちらをさっと理解するのも良いと思います。

ここではgit-flowの一部を利用して、以下の手順でサンプルプロジェクト(hellowgit)を回してみたいと思います。

ざっくりいうと開発はdevelopブランチから作ったfeatureブランチで行い、そこからdevelopにマージして、完成形(release)に持っていく、ってことですね。developやmasterには直接編集したりしちゃいかんということですね。やろうと思えばできちゃいますが。

・masterブランチを作成する。
・developブランチを作成する。
・featureブランチを作成する。
・featureブランチで開発。
・featureブランチをdevelopにマージ。
・developからreleaseにマージ。
・releaseからmasterにマージ。
・releaseからdevelopにマージ。

まずはGitHub.comでアカウントを作ってみます。フリーのメールアドレスがあれば簡単に作れます。

あとはローカルPCにgitが必要ですね。私の場合Ubuntu18ですと以下のコマンドでインストールできます。

sudo apt-get install git

masterブランチを作成する

まずはプロジェクトの作成ですが、ローカルPCで作る方法（git init）もありますが、ここではgithubで空プロジェクトを作ってgit clone する方法を試してみます。

githubのRepositoriesタブからNewボタンですね。

repository nameを入力、リポジトリのタイプにPrivateを選択、リポジトリをreadmeだけで作成チェックにチェックを入れてリポジトリを作ってみます。

developブランチを作成する

次はローカルPCにmasterブランチを持って来ます。URLをリポジトリの「Clone or download」からコピーしてきます。

リポジトリを作りたいローカルPCのフォルダで

#ユーザ名はgithubユーザ名
$ git clone https://github.com/ユーザ名/hellowgit.git

を実行するとhellowgitフォルダが作成されてクローンされるものと思います。hellowgitフォルダに移動して 「ls -al」 してみると「.git」という隠しフォルダができるのがポイントですね。

コマンドでgit cloneでmasterブランチが取ってこれたのを確認してみます。

$ git branch

#出力結果
* master

*がついているのは現在チェックアウトしているブランチですね。

ここからdevelopブランチを作ってgithubにアップしてみます。

ここでのサンプルはテストなのでdevelopをpushしてますが、実環境ではちゃんとdevelopブランチがgithubにないことを確認してpush実行してください。developがある場合はもうプロジェクトが進んでいる証拠ですので、developのpushは現場有識者に確認ですね。

$ git branch develop
$ git checkout develop

これで「develop」ブランチが出来て、「develop」をチェックアウトしている状態になりました。これはローカルリポジトリ（ローカルPC）でのはなしですね。

$ git branch
#出力
* develop
  master

今回はdevelopブランチを作るだけですので、そのままリモートリポジトリ（github）に「push」(アップロードすること)します。

$ git push origin develop

再びgithubに戻るとブランチに「develop」が追加されたことが分かるかと思います。

featureブランチを作成する。

次は実際のソースコードの開発フェーズに移動したとします。

例えば途中でプロジェクトに参画した場合などはまずはdevelopにpullですね。

$ git pull origin develop

これでローカルリポジトリのdevelopがリモートリポジトリと同じになるはずです。

branchがdevelopチェックアウトなのを確認して、featureブランチを作ってチェックアウトです。

$ git branch feature/add1
$ git checkout feature/add1

現在チェックアウト中のブランチの確認です。

$ git branch
#出力
  develop
* feature/add1
  master

featutreブランチで開発

ここでようやく開発です。以下のようなサンプルファイルを追加してみます。

#hellow.py
print('hellowwwwww')

もともとあったreadme.mdもちょっと編集してみます。

# hellowgit
追加してみました

これをローカルPCでコミットして、リモートリポジトリに「push」します。変更したり追加したりしたファイルは「git add ファイル名」で追加ですね。これ指定しないと永遠にリモートリポジトリに反映されません。よくある「git add .」は使わないほうが良いと個人的には思います。ゴミが混入しちゃうと凄い面倒です。

$ git add hellow.py README.md 
$ git commit -m "feature/add1"
$ git push origin feature/add1 

githubに戻って今度は「feature/add1」ブランチがリモートリポジトリ（github）に追加されたことが確認できました。

ちなみにもし色々修正してもコードが思ったように動作しなくて最後のコミット状態に戻せるコマンドを私は多用してますので参考までに。

 $ git reset --hard 

(前提として編集ファイルがgit add でgit に載せられている状態である必要があります。)

featureブランチをdevelopにマージ

開発も一段落したと仮定して、feature/add1の機能をdevelopにマージです。

マージするには「Pull Request」をしてそれを承認することになります。ここでは実際はテストですので、自分で「Pull Request」してそれを承認してマージすることになります。

もともとの使われ方が、公開されているコードに対して世界中のプログラマさんが、こんなの作ったからこれ取り込んでみて、というリクエストをコードを管理している管理人さんに対して行い、管理さんがマージするか拒否するかを決定する、といった使われ方を想像すれば「Pull Request」の意味も筋が通るのではと思います。

こんな感じで差分も見れて、取り込んでもOKなら「Merge pull request」へ進みます。取り込まない場合はちょっと下にある「Close pull request」をクリックです。

developからreleaseにマージ

で次は最終リリースに入ると仮定します。

developブランチをチェックアウトしてリモートリポジトリから最新のdeveplopブランチを取ってきます。

$ git checkout develop
$ git pull origin develop

developブランチがチェックアウトされていることを確認します。

$ git branch
* develop
  feature/add1
  master

似たようなコマンドですが、releaseブランチを作ってチェックアウト、リモートリポジトリにpushします。

$ git branch release
$ git checkout release
$ git push origin release

これでreleaseブランチがgithub上に追加されたものと思います。

次はreleaseのタグ付けです。

releaseタブからタグ付けのこんな画面に移動して、「Create a new release」をクリックです。

最後適当にバージョン番号などを入れて、「Publish release」ボタンをクリックするとリリース用ファイルが管理できます。

releaseからmasterにマージ

リリースも無事完了したと仮定して、今度はreleaseをmasterにマージです。

releaseからdevelopにマージ

次はreleaseからdevelopへのマージが教科書的には正しいですが、実際は中身が同じでmergeできないと言われますので、masterからdevelopへマージしときます。これしないとmasterのコミットが進んでしまっている状態で色々よろしくない状態になっちゃいますね。

最後にmasterとdevelopローカルリポジトリ同期ですね。チェックアウトするブランチは変えなくても良さげですが念の為。。

$ git checkout develop
$ git pull origin develop
$ git checkout master
$ git pull origin master

まとめ

実際は現場の有識者に確認することになりますが、まずは最低限の理解はしとかないとまずいですね。

以上になります。