はじめに
なんか当たりの強いタイトルで申し訳ないですが、そんなつもりはありません。
もしよろしければ暇な時にGitという存在及び add, commit, push, clone, pull, merge 程度の操作を学生に教えて下さいませんでしょうか？？？
特に専門学校の教員の皆様よろしくお願いいたします。お時間ないようであれば私で良ければ行きます。(交通費出してくださいｗ)
今やGitはプログラマだけに限らずデザイナーのみなさんもぜひ使っていただきたいバージョン管理ツールです。
GitHubなどでは画像の差分(以下、diff)も表示できるようになったのですごいなぁって思います。（一部のみ？）
なぜこのエントリーを書こうとしたか
@学生Git遣いの皆さん
— 小泉ひやかし🌻 (@nnsnodnb) 2017年2月16日
「情報系の学校でてるなら新卒みんなある程度はGitの使い方わかるでしょ〜」っていう考え持っているようでしたらそれは違います。
情報系の大学・専門学校を卒業していてもDropboxでソースコードを管理するとかGitという言葉すら知らない人山ほどいます。
— 小泉ひやかし🌻 (@nnsnodnb) 2017年2月16日
卒業研究のソースコードをGitHubにプッシュしてそれをボスに投げつけることはよくありません
— 小泉ひやかし🌻 (@nnsnodnb) 2017年2月16日
一番年下の僕が上は4つ上までGitの使い方を教えていたり、上は16歳上(当時僕は20歳: 現在も)の人生の先輩方にソースコードレビューしてたりしたhogehoge...
— 小泉ひやかし🌻 (@nnsnodnb) 2017年2月16日
母校よ。お金はいらないから制御情報工学科と経営情報学科(一部の変態)たちにGitというものを教えてあげたいから時間くれ！
— 小泉ひやかし🌻 (@nnsnodnb) 2017年2月16日
今伸びてるツイートに補足情報を付け加えると僕が学生時代(昨年度)にGitっていうものがあってだなということをクラスの人に話したことがあってみんな「は？」って顔してた。100%情報系学科の数人にGitの話しても誰も理解してくれなかった。
— 小泉ひやかし🌻 (@nnsnodnb) 2017年2月16日
DropboxをGitリモートにするのは全然いいと思うけどプロジェクトディレクトリに.gitフォルダが一切ないのが条件ね。
— 小泉ひやかし🌻 (@nnsnodnb) 2017年2月16日
はじまりはツイートなんですが...
2つ目のツイートが思った以上に伸びてしまったのでちょっと仕事終わったついでにまだ寝るまでの時間が余っているので書こうと思います。
現状について
あくまでも私の経験からの現状についてです。
学生時代
登場人物は学生時代に 私の研究室のボス 、 高専時代の同学科各位 、 高専時代の某研究会の後輩たち
私の研究室のボス
- 「Gitってなんや。教えてくれ」
- 「Gitサーバ建ててそれでプログラム管理しよう」→結局僕しかやってないじゃん！！ｗ
高専時代の同学科各位
- 「は？なにそれ」→論外。まぁ学科時代が文系だから仕方ない。情報系にも傾いてる変態各位にも伝わらない
高専時代の某研究会の後輩たち
- 「Git使ってみたいんですけど難しそうで...」→いや、難しそうなのはわかる。やってみようぜ！！
社会人
社会人って言ってもまだ今年新卒1年目なのでデカイ口は叩けませんが...
登場人物: 同じ新卒各位 、 中途採用の人生の先輩方各位 、 手伝っている某Z社のエンジニア各位様
同じ新卒各位
- A氏「Git使ったことあります！」→「ごめんなさいリポジトリぶっ壊しました」
- B氏、C氏「Gitってなに？」
全員、情報系の専門学校卒でした...
中途採用の人生の先輩方各位
- Gitを使ったことがある、使える: 50%
- Gitを使ったことはないが、知っている: 50%
先輩方の前職的なこともあるのでこんなものなのかなぁといった印象を受けました。
手伝っている某Z社のエンジニア各位
今では見事にGitHubに移行してエンジニア各位がGitの本領を発揮させているように感じます！！
私のGitの使い方
完全個人開発
- リリース前
基本的に機能要件が結構エグくなってくるまで master 一本でコミットしていくことが多いです。
機能要件がエグくなってきたらそれっぽく develop から feature/○ (○は機能名とか)ブランチを作ってコミットしていく感じです。
- リリース後
master から develop を生やして feature/○ (○は機能名とか)とか何となく作って、 develop に向けてPull Request(以下、PR)を作成。
でバージョンアップデートのマイルストーンに記述しておいた機能要件を満たしたら master に develop からPRを作成。
あとはCIを通して自動ビルド等
結局同じような開発になるんですわ。
複数人同時開発
現場とプロジェクトによってまちまちですが、私はプロジェクトリーダーをやっていた(いる)案件では、
master → develop → release/v1.0.0 → test-release/v1.0.0 → v1.0.0/issue#1 or feature/issue#1
PRはそれぞれ親ブランチに作成していく形。
ちょっと調子に乗って作ってたらバランスが悪くなった...
v1.0.0/issue#1 と同じ次元に v1.0.0/issue#2 とかが存在するような形です。
気分によって変える時はありますが、共通認識を合わせるためにGitHubならWikiに予めブランチ命名規則やコミットメッセージ規則を書いたりしますね。
ちなみにコミットメッセージ規則でよくするのはIssue番号を必ず含めることです。 → ○○を実装 #1 or Implementation ○○ for MainViewController #1 みたいな感じ
基本的に私はターミナルに日本語が出てくるのを極度に嫌う癖があるので後者で書きます。他にも理由はあるのですが...
おまけ
Git経験半年ぐらいにえらっそうに書いたQiita記事があるのでもしよかったら「いいね！」押してくれると嬉しいです。
この記事を書いた頃は rebase 機能をうまく使いこなせていなかったのですが、自学してrebaseを使うようにしてなんとか習得できました。
まだGitは奥深いですのでえらっそうなことは言えません。許してください:;(∩´﹏`∩);:
まとめ
今回言いたいことは 学校で習わないとしても自分で勉強してみようぜ？ っていうことです。
エンジニアとして生きていくからには常に勉強勉強の積み重ねだし、これらに関してはマイナスはないと思うし、いつかは役に立つと思う。
SubversionおじさんはGitおじさんになろうな！
半年もあればある程度Gitなんてある程度使いこなせるようになると思う。
ぶっちゃけ新卒の新人研修でやって慣れようぜ！っていうことなんだろうけど、Xcodeでプロジェクト作った時にGitプロジェクトとして作るか選ぶところがあるのだが、
そこを直すので時間を無駄にした経験がある。(同期の人)
ここにチェックを入れたあとにプロジェクトトップディレクトリで git init してしまうと作成したXcodeプロジェクトが見事にサブモジュールとして認識されてしまう。
といった事故が起こり兼ねない。さすがにGitもまともに触ったことのないド素人さんをいきなりプロジェクトにアサインするマネージャ様はいらっしゃらないかと思いますが...
Xcodeに限らずPyCharmとかAndroidStudioとかPhpStormとかでも起こりそう。
勉強できそうなサイト
サル先生のGit入門〜バージョン管理を使いこなそう〜【プロジェクト管理ツールBacklog】
git入門 (全22回) - プログラミングならドットインストール
初心者の初心者による初心者のためのGit入門 - Qiita
私はドットインストールさんにお世話になりました。
