読者です 読者をやめる 読者になる 読者になる

『入る学科間違えた高専生』の日記

プログラミングのコードを書いたりする予定です。あとは日記等。あといつまで高専生やねん

情報系学科で教員はGitを教えろ

はじめに

なんか当たりの強いタイトルで申し訳ないですが、そんなつもりはありません。
もしよろしければ暇な時にGitという存在及び add, commit, push, clone, pull, merge 程度の操作を学生に教えて下さいませんでしょうか???
特に専門学校の教員の皆様よろしくお願いいたします。お時間ないようであれば私で良ければ行きます。(交通費出してくださいw)

今やGitはプログラマだけに限らずデザイナーのみなさんもぜひ使っていただきたいバージョン管理ツールです。
GitHubなどでは画像の差分(以下、diff)も表示できるようになったのですごいなぁって思います。(一部のみ?)

なぜこのエントリーを書こうとしたか

はじまりはツイートなんですが…

2つ目のツイートが思った以上に伸びてしまったのでちょっと仕事終わったついでにまだ寝るまでの時間が余っているので書こうと思います。

現状について

あくまでも私の経験からの現状についてです。

学生時代

登場人物は学生時代に 私の研究室のボス高専時代の同学科各位高専時代の某研究会の後輩たち

  • 私の研究室のボス

    • 「Gitってなんや。教えてくれ」
    • 「Gitサーバ建ててそれでプログラム管理しよう」→結局僕しかやってないじゃん!!w
  • 高専時代の同学科各位

    • 「は?なにそれ」→論外。まぁ学科時代が文系だから仕方ない。情報系にも傾いてる変態各位にも伝わらない
  • 高専時代の某研究会の後輩たち

    • 「Git使ってみたいんですけど難しそうで…」→いや、難しそうなのはわかる。やってみようぜ!!

社会人

社会人って言ってもまだ今年新卒1年目なのでデカイ口は叩けませんが…
登場人物: 同じ新卒各位中途採用の人生の先輩方各位手伝っている某Z社のエンジニア各位様

  • 同じ新卒各位

    • A氏「Git使ったことあります!」→「ごめんなさいリポジトリぶっ壊しました」
    • B氏、C氏「Gitってなに?」

全員、情報系の専門学校卒でした…

  • 中途採用の人生の先輩方各位

    • Gitを使ったことがある、使える: 50%
    • Gitを使ったことはないが、知っている: 50%

先輩方の前職的なこともあるのでこんなものなのかなぁといった印象を受けました。

  • 手伝っている某Z社のエンジニア各位

    • リポジトリ破壊作業まではしませんでしたが、コミットが何故か消えるなどの事故はありましたw
      さすがに焦りましたwwリモートは gitbucket を使用させていただきました。

今では見事にGitHubに移行してエンジニア各位がGitの本領を発揮させているように感じます!!

私のGitの使い方

完全個人開発

  • リリース前

基本的に機能要件が結構エグくなってくるまで master 一本でコミットしていくことが多いです。
機能要件がエグくなってきたらそれっぽく develop から feature/○ (○は機能名とか)ブランチを作ってコミットしていく感じです。

  • リリース後

master から develop を生やして feature/○ (○は機能名とか)とか何となく作って、 develop に向けてPull Request(以下、PR)を作成。
でバージョンアップデートのマイルストーンに記述しておいた機能要件を満たしたら masterdevelop からPRを作成。
あとはCIを通して自動ビルド等

結局同じような開発になるんですわ。

f:id:nanashinodonbee:20170216232104p:plain

複数人同時開発

現場とプロジェクトによってまちまちですが、私はプロジェクトリーダーをやっていた(いる)案件では、
masterdeveloprelease/v1.0.0test-release/v1.0.0v1.0.0/issue#1 or feature/issue#1
PRはそれぞれ親ブランチに作成していく形。

f:id:nanashinodonbee:20170216233308p:plain

ちょっと調子に乗って作ってたらバランスが悪くなった…

v1.0.0/issue#1 と同じ次元に v1.0.0/issue#2 とかが存在するような形です。

気分によって変える時はありますが、共通認識を合わせるためにGitHubならWikiに予めブランチ命名規則やコミットメッセージ規則を書いたりしますね。

ちなみにコミットメッセージ規則でよくするのはIssue番号を必ず含めることです。 → ○○を実装 #1 or Implementation ○○ for MainViewController #1 みたいな感じ
基本的に私はターミナルに日本語が出てくるのを極度に嫌う癖があるので後者で書きます。他にも理由はあるのですが…

おまけ

Git経験半年ぐらいにえらっそうに書いたQiita記事があるのでもしよかったら「いいね!」押してくれると嬉しいです。

qiita.com

この記事を書いた頃は rebase 機能をうまく使いこなせていなかったのですが、自学してrebaseを使うようにしてなんとか習得できました。

まだGitは奥深いですのでえらっそうなことは言えません。許してください:;(∩´﹏`∩);:

まとめ

今回言いたいことは 学校で習わないとしても自分で勉強してみようぜ? っていうことです。
エンジニアとして生きていくからには常に勉強勉強の積み重ねだし、これらに関してはマイナスはないと思うし、いつかは役に立つと思う。
SubversionおじさんはGitおじさんになろうな!
半年もあればある程度Gitなんてある程度使いこなせるようになると思う。

ぶっちゃけ新卒の新人研修でやって慣れようぜ!っていうことなんだろうけど、Xcodeでプロジェクト作った時にGitプロジェクトとして作るか選ぶところがあるのだが、
そこを直すので時間を無駄にした経験がある。(同期の人)

f:id:nanashinodonbee:20170216234026p:plain

ここにチェックを入れたあとにプロジェクトトップディレクトリで git init してしまうと作成したXcodeプロジェクトが見事にサブモジュールとして認識されてしまう。
といった事故が起こり兼ねない。さすがにGitもまともに触ったことのないド素人さんをいきなりプロジェクトにアサインするマネージャ様はいらっしゃらないかと思いますが…

Xcodeに限らずPyCharmとかAndroidStudioとかPhpStormとかでも起こりそう。

勉強できそうなサイト

サルでもわかるGit入門 〜バージョン管理を使いこなそう〜 | どこでもプロジェクト管理バックログ

git入門 (全22回) - プログラミングならドットインストール

初心者の初心者による初心者のためのGit入門 - Qiita

Git Tutorial - Try Git

私はドットインストールさんにお世話になりました。

書籍等

エンジニアのためのGitの教科書 実践で使える! バージョン管理とチーム開発手法 (WEB Engineer’s Books)

エンジニアのためのGitの教科書 実践で使える! バージョン管理とチーム開発手法 (WEB Engineer’s Books)

GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)

GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)

15時間でわかるGit集中講座

15時間でわかるGit集中講座

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

入る学科間違えたと気付いた時にはもう遅かった

地獄を生きていくこのサバイバル高専生活果たしてどう生きていく