10
6

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

ノンプログラマの同志へ向けた、GitLabのススメ

Last updated at Posted at 2018-09-20

Qiita初投稿です。
業務で必要になり、プログラミングをヨチヨチ初めて一年弱になりました。
(pythonしか書けません!)
最近GitLabを使うようなりいろいろ考えることがあったので、
誰かの役に立てばいいなと思い記事にしました。

「Git」とか「GitLab」って?

Gitはバージョン管理ツール、
Gitlabはコード管理サービス……だそうです。
正直、厳密なことはよくわからず使っています。
ざっくり、コーディングの軌跡を残せたり、
コードをクラウドで他人と共有できる
ナウでイケてるアゲな何かという理解です。

ちゃんと知りたい方は、以下の記事を参照。
GitLabとは?GitHub買収で10倍のインポート数。使い方を解説

「ノンプログラマ」なのに「GitLab」?

「ノンプログラマ」って?

当記事では職業プログラマ、エンジニアではないという意味で
「ノンプログラマ」という言葉を使っています。
例えば業務の効率化、自動化目的でプログラミングを手段として使うことになった人です。
(私のことです)

なんで「GitLab」を使うの?

各人が作った小規模なスクリプトをきちんと管理したくて導入することになりました。
というのも職業エンジニアの方がお仕事で作るシステムやアプリケーションと違い
要件定義や仕様はおろか、メンバー内でのコーディングのルールもない状況でした。
作ったスクリプトも基本的に各自のローカルで保存しているだけ。
(しかもちゃんと管理できてない人が大半)
後々誰かが見返すことも意識しながら仕事をする環境を作りたかったのです。

GitLabを使ってみて

良かったこと

  • コーディングを始める前に、タスクを言語化する習慣がつく!
  • やろうとしていることや懸念点、打ち合わせの内容などをオープンにして書き残せる!
  • 質問があった時に、参考にしてもらえそうなものをすぐに提供できる!
  • プッシュしておけば、うっかりローカルのファイルを消しても大丈夫!
  • 連携しながらの開発が容易になるので、積極的に作業分担できる!

難しかったこと

  • そもそも、Gitの仕組みや考え方について理解できる人が少ない。(学習コストがかかる)
  • あやふやな知識でつかおうとすると、誤った操作をしてしまう。(そしてGit嫌いが誕生する……)
  • ノンプログラマに適したモデルケースがなかなか見つからない。

特に「GitLabスゲー!」と思ったこと

  • ブランチを切ることで、ほかの人との並行開発がスムーズになった!
  • おかげで、一人で片付けるのが大変そうな規模の依頼にも気軽に応じられるようになりました。
  • issueやプルリクを立てておけば、やり取りした際もスレッドで残せる!
  • メールだとさかのぼるのが面倒な時もスレッド形式だと楽だし、書き込むときも同様です。

GitLabを使いやすくするためにしたこと

前述した「難しかったこと」への対応策をいくつか。
この件については、また別の記事で詳しく書く予定ですので、とりあえず大雑把に。

GUIを使う

本来、Gitを使うときはコマンドプロンプト(真っ黒い画面のやつ)にコマンド入力しますが、
ノンプログラマにはハードルが高く、クライアントをインストールして使うことに。
GUIだとブランチの様子など可視化される為、
プロジェクトが複雑になってきても現状を把握しやすいです。
今使っているクライアントはこれ。
sourcetree

運用ルールを作る

前述したように、自分たちに合うようなモデルケースが見つからなかったので、
Git-Flowの運用ルールをもとに、独自にルールを作ってみました。
Git-Flowについてはこちら。

Git-flowって何?

こだわったポイントは以下の五つです。

  1. リモートリポジトリのForkはしない。
  2. 基本的にMasterブランチを使う
    (プロジェクトのトップページに表示されるのがMasterだから)
  3. ブランチを切る必要がある場合は、
    MasterからDevelop、DevelopからFeatureを切る。
  4. 帰宅するときは必ずその時点までのコミットをプッシュしておく。
  5. 単独でも複数人でのプロジェクトでも、マージする際はマージリクエストを出す。

issue,マージリクエストのテンプレート化

これまでは各人が依頼内容を個人的なメモに取ってそれをもとに開発を進めていました。
しかし、それだと情報共有がしにくい!
さらに自分もメイン業務に追われてどこまで開発したのか、
何をしようとしていたのか分からなくなることも……。
コーディングを始める前に要件の整理をしてもらうことにしました。
また、各々好き勝手に書くと収拾がつかなくなるとも考えて、
テンプレートを埋めてもらう形式にすることに。

内容は大まかに以下の通りです。

  • issueについて
  1. 何をする必要があるか
  2. それを達成するための課題は何か
  3. 思いつく限りの解決法(具体的な技術含めて)
  4. 他の人に助けてほしいこと
  • マージリクエストについて
  1. 何をするスクリプトか
  2. 具体的に何をしているか箇条書き(○○のファイルを開く~など)
  3. 依頼にはなかったが、あったほうがよさそうな機能などの提案
  4. 自信がないので念入りにチェックしてほしい部分

まとめ

実際のところ、複数人での共同開発をしないのであれば
GitとGitLabのほんの一部の機能しか使いません。
それでも、導入のメリットがあると主張したい!

  • コーディングを始める前に要件、タスクを整理して明文化する
  • 「このコードは、自分以外の誰かが見る!」という意識をもってコーディングする
  • だれが何の意図をもってどのような経緯で開発を進めていたかのログを残す。

などなど。
ノンプログラマであっても仕事を進めるうえで必要、
だけどなかなか根付かない意識や文化ってありますよね。
GitLabを使えば、こういう意識を持ちやすい環境作りができるのではないかと思います。
ナウでイケてるアゲなツール、GitLabを
ノンプラグラマの同志のみなさんも使ってみてください!

10
6
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
10
6

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?