ユル～く使うGitLab（ギットラボ）＜リポジトリ運用編＞

はじめに

非常に高機能なGtLab（Github）を使う上で大事な、「どういう風に使うのか」をまとめていくシリーズです。

今回のリポジトリ運用編は、書いてる人が非職業エンジニアなので非常にユルめのルールなのが特徴。
(元になっているのはみんな大好きGithub Flowです)
習うより慣れろとはいいますが、前提となる知識がないととっつきにくさを感じたまま、いつしか嫌になってしまうものです。
GitLabに混乱中の方にとっての、ちょっとしたガイドになればいいなという気持ちで記事を書いています。

対象者

• 「業務でちょこっとプログラミングするのでGitLabを使いたいな～」と思ってる方
• 「GitLabを使い始めたけど、なんかもうどう運用したらいいかわからない」とお困りの方
• 「自分で運用ルールを作るのメンドクセ」な方

目標

• 「GitLabを使うのが怖い！　ブランチとかマージとか怖い！」という恐怖心が薄れる
• 「何をどう進めればいいかわからない！　ローカルでGit使ってれば十分でしょ！？」という苛立ちがおさまる
• 「GitLabってこんなユルい使い方でもいいんだ！　やってみようかな～」というワクワクが起きる

運用ルールについて

運用する上で大事なのは、
基本に忠実に
カッコつけてややこしい事をしない
他の人が見やすいように意識する
です！

1.リポジトリはフォーク（Fork）しない！！

フォークすることによってブランチがややこしくなります。
よっっっっっっっぽど失敗が許されないリポジトリでなければ、
フォーク　→　クローンでなく、直接クローンしましょう。

リポジトリ＝プロジェクトの作り方はこちらを参照。
【GitLab】プロジェクト（リポジトリ）を作成する

2.切るブランチの種類は絞る！！

今回のルールでは基本的に、以下三種のブランチしかつかいません。
hotfix？　忘れましょう。

• Master
• 最終的なリリース用。
• 最終的にDevelopがマージされます。
• GitLabのプロジェクトのトップページはデフォルトでMasterがトップページのようです。
• Develop
• 各機能を統合する用。
• 各Featureがマージされ、最終的にMasterにマージします。
• リリース前の動作確認は、Masterにマージ前にこのブランチでやりましょう。
• Feature/●●（モジュールの名前）
• 実際各モジュールを作ったりする用。
• モジュール毎に作成して、最終的にDevelopにマージします。
• プロジェクトにかかわる各人がプッシュしていきます。

もし**「モジュール毎にブランチ切るとかメンドクセ！」**な場合は、
Feature/開発する（プッシュする）人の名前でもいいんじゃないかと思います。

具体的な運用イメージはこんな感じ。
（実際に私がGitLab上で作ってみました）

ちなみに、複数人じゃなく個人での開発だったら、Featureは不要かも。

1. Developでどんどん開発して、
2. できたらMasterにマージ

4.複数人で一つのファイルを編集しない！！

コンフリクト予防にとても大事です。
もちろん、Gitはコンフリクトが起きても解消しやすいよう作られていますが、
コンフリクトが起きると焦るのが人の心です。
できるだけ心臓に悪いことは起きないようにしておくのが良いでしょう。

5.コミットメッセージの書き方を決める！！

あとから見返したときに、何をどうしたコミットかわからないと困ります。
せめて、新規ファイル作成(add)なのか、更新(update)なのか、削除(del)なのかくらいはわかるようにしておきましょう。

だいたいこんな感じてかいてます。

[作業の種類]どのファイルをどうしたか簡単なまとめ
(空行)
もう少し詳しいコミットの内容

GitLab上でパッと出てくるのは一行目なので、並ぶとこんなかんじ。

具体的な書き方は以下の通り。

ファイル新規追加の場合

[add]A.pyを新規作成。

A.pyの開発をとりあえずはじめました。

ファイル編集の場合

[update]A.pyのパスを変更。

●●行目のパスを絶対パスに書き直しました。

6.マージリクエストはだしておく

自分一人の開発ならいいですが、複数人で進めている場合はマージリクエストはだしておきましょう。
書き方はまた別途記事にする予定ですが、
マージリクエストを出しておくことによって、他のメンバーへの進捗の報告になったり、相談したりすることができます。
どんな昨日の開発をしているモジュールなのか、備忘録のためにも書きましょう。

マージリクエストは、プロジェクトのページのここから出せます。

こんな感じの緑のボタンをクリックして、

どのブランチを（source branch)どのブランチへ（target branch）マージしたいのか指定して、緑のボタンをクリック。

そうすると、コメントをかくページに移動するので、実装予定の機能とかを書いて、下の方の緑のボタンをクリック。

これでマージリクエストが作成できました！

ちなみに、マージしたいときは、各マージリクエストの「Merge」ボタンをクリック。

これができればもう、GitLabを完全に理解したと言っても過言ではありません（過言です）

7.帰る前にはコミット＆プッシュする！！

最低でも帰宅前、作業中断前の段階で一回コミットして、プッシュするようにします。
進捗状況をほかの人がわかるようにすると同時に、何より自分の保険のためにしておきます。
久々に再開したらなんかよくわかんなくなっちゃった・・・なんてことは避けたいですね。

8.困ったら話し合う&ReadMeに書いておく

上記のルールはとても基礎的なものです。
実際に使っていく中でいろいろ想定していなかった状況が出てくるはず。
そんな時は、同じプロジェクトを進めているメンバーと運用について話し合いをして、そのリポジトリのルールを定めていきましょう。
もちろん、その独自ルールは書き残します。
Masterブランチの「.git」があるディレクトリーに「README.md」ファイルをプッシュするか、
プロジェクトのトップページの「Add Readme」をクリックして作成しましょう。

.mdだから、マークダウン記法で書こうね！
tMarkdown記法 チートシート

おわりに

私も最初にGitLabを触ったときは、もう何をするにも恐くて震える指で緑のボタンをクリックしていました。
だいたいGitLabで挫折してしまう人は、どういうふうにリポジトリを運用したらいいかわからない≒余計なことをしてしまいそうで怖い！という気持ちになってしまうのだと思います。
GitLabに振り回されてしまってる状態ですね。
でも、よく考えてみてください。GitLabはツールです。全ての機能を理解して使うより、必要な機能をどのように使うかの方が重要です。
本記事で書いたような簡単なルールで運用をしばれば、いじっていくうちになんとなく「次はこうしたらいいのかな？」という予測が立てられるようになるので、トラブル時に「何が何だかわからない！！」なんてパニックに陥ることは減るのではないかと思います。
もし、このユル〜い運用ルールで物足りなさや不便さを感じるようになれば、あなたはもう立派なGitlab使いです。
もっとガチめな運用ルールを調べて、どんどん導入して行きましょう！

それでは皆さま、よきGitLabライフをお過ごしください！！

参考URL

GitHub初心者はForkしない方のPull Requestから入門しよう
トピックブランチと統合ブランチでの運用例【ブランチ】 | サルでもわかるGit入門 〜バージョン管理を使いこなそう〜 | どこでもプロジェクト管理バックログ
GitHub Flow 図解
Gitのコミットメッセージの書き方
仕様書のレビューをGitlabのMerge Requestでやろう！