これさえ読めば明日から「gitを用いたチーム開発」ができる
非エンジニアでかつチーム開発をしてみたい人向けに自分の勉強がてらその方法をまとめていきます。非エンジニアにも読めるよう平易な内容になっているはずです。
GitHubを用いた開発の基本的な概念を解説
ブランチ:簡単にいえば作業ディレクトリを複製し異なる作業を同時に進めることができる機能です。作業が完了したらマスターのブランチに差分を反映します。
以下の図のような感じです。
プルリクエスト:編集リクエストのようなものです。「こんな修正してみたけど良ければ修正してください。」って感じです。
以下のようなフローで開発していくことになります。
-
自分が担当する実装用の、branchを作成する
-
変更点をコミット
-
そのbranchを元にPull Requestを作成する
-
レビュアーはPull Reqeustを確認し、問題なければ元のブランチに反映(マージ)する
イシュー:製品の課題や修正点などをGitHubに集約させるための仕組みです。
バージョン管理ではなくパッチ管理??
gitはバージョン管理ツールと言われることが多いですが、(特に初心者が)実務で扱う場合パッチ(=修正内容)を管理していると考えたほうが良いです。
すなわち以下のようなフローを頭の中でイメージしながら勧めていきます。
図①
修正内容Aを作る
修正内容Bを作る
修正内容Cを作る
第一版
↓ 第一版に修正内容Aを加える
第二版
↓ 第二版に修正内容Bを加える
第三版
↓ 第三版に修正内容Cを加える
第四版
※参考 gitでの開発の流れ
①まずは以下のようにgitのリポジトリを作成し、初期状態をつくってコミットしておきます。
$ mkdir gitsample && cd $_ $ git init
$ touch .keep
$ git add .keep
$ git commit .keep -m "initial commit"
これで図①における第一版ができたことになります。
②次に修正内容Aを作ります。修正内容Aはspike/Aというブランチを作成しそちらで作業します。
$ git branch spike/A //spike/Aの作成
$ git checkout spike/A //spikeAへ移動
Switched to branch 'spike/A'
ここで適当な作業をして修正内容Aを作ります。
$ touch A
$ git add A
$ git commit -a -m "commit A"
③全く同様な流れで修正内容B,修正内容Cをそれぞれspike/B,spike/Cで作成します。
ここまで来るとmaster,spike/A,spike/B,spike/Cの4つのブランチが作成されているということになります。
④作成した修正内容ををそれぞれmasterに取り込んでいきます。
$ git merge spike/A
Updating a998f39..00d05bf
Fast-forward
A | 0
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 A
B,Cに関しても同様にmasterに取り込んでいきます。
GitHubでの開発の流れ
①gitの時と同様にgitのリポジトリを作成しコミットした上でGitHubのリポジトリにpushします。
$ mkdir gitsample && cd $_
$ git init
$ touch .keep
$ git add .keep
$ git commit .keep -m "initial commit"
$ git remote add origin git@github.com:※githubのリポジトリ名※.git
$ git push -u origin master
②同様に修正内容Aを作成しGitHubにpushします。
$ git branch spike/A
$ git checkout spike/A
$ touch A
$ git add A
$ git commit -a -m "commit A"
$ git push origin spike/A
Counting objects: 3, done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 237 bytes | 0 bytes/s, done.
Total 2 (delta 0), reused 0 (delta 0)
To git@github.com:※githubのリポジトリ名※.git
* [new branch] spike/A -> spike/A
$ git checkout master
Switched to branch 'master'
同様に修正内容B、Cに関してもGItHubにpushしていきます。
③「プルリクエスト」と「マージ」の2つのアクションによって修正内容を版管理に加えていきます。
GitHub上の該当レポジトリの対象ブランチにてプルリクエストを作成します。
このようにして作成されたプルリクエストを管理者がマージしていきます。
他のブランチに関しても同様の流れです。
こうして作業を終えるとNetworkでみると以下のようになっています。
終わりに
最低限チーム開発ができるまでにはなったかと思います。gitについては色々な手法や思想があるのでそちらも順次まとめていければと思っています。
突然ですがブログを始めます
なんとなくブログを始めることにしました。
これまではアウトプットのツールとして主にTwitter,Facebook,Qiitaを使ってきましたが今回ブログ媒体での発信活動を始めようと思った理由が幾つかあるのでそれを書きます。
質の良い発信をしない人間は職を失う
前々から感じていましたが、ちょっと前にこんな記事はバズりました。
内容的には、その人の能力や考え方を判断するのに学歴というのが一定のシグナリング効果を持っていたけど、AIがSNSを解析するようになったら今後はその価値が薄れていくよって感じです。SNSなどでの発信内容のほうがその人の能力や人となりを表すからですね。
まあ学歴うんぬんはおいておいて、オンラインでの発信や活動内容がその人を判断する重要な指標だということに関しては完全同意です。
まずそもそも継続的に発信しようという姿勢自体が、その人の学習意欲の高さを表していると考えます。短期的なリターンが見込めない学習ができない人が非常に多いです。大学受験や仕事上での緊急の必要性がなければほとんどの人は勉強しようとは思わないのではないでしょうか。
ですがこれからの時代は積極的に学習しないと価値のある仕事ができない時代になっていきます。どんな分野の仕事でも新しい技術の存在を前提に問題解決を行う必要がある以上、技術に関する基本的な理解がなければ問題解決どころか議論もできないでしょう。
これまでの「勘と経験」に頼った仕事に価値はなく、技術を用いてデータに基づいた仕事が価値を持っていくと考えます。
オンラインの発信内容や活動内容からその人の全てがわかるとは言えませんが、その人の志向性や思考力など仕事をする上で重要な能力は判断可能です。物事に対して筋の良い視点を持っているか、論理的に物事を考えているか、視野は広いかなどは判断可能ですしAIでもある程度はできます。
またエンジニアやデザイナーであればその人のアウトプットの質とその人のスキルの高さの相関性は非常に高いかと思います。
先程のデータドリブンな仕事の文脈にも関係しますが今後の就活・転職にはその人のはオンラインの活動が重要な指標になってくるのは間違いないでしょう。
全く発信しない人もしくは低レベルな発信をしてる人はスクリーニングのコストが高すぎて検討の土俵にも上がらないなんて事態が起こるのも遠くはありません。
また自分はアウトプットすることで知識を習得していく(読んだりするだけじゃすぐ忘れる)タイプなので知識の体系化をしたいというのもブログを開設する理由です。
更新頻度は不定期ですが幅広く主にキャリア、技術、読んだ本などを中心に発信してまいります。