4
6

More than 5 years have passed since last update.

自主勉強継続するためにGitHub使ってタスク管理をやった話

Last updated at Posted at 2019-02-26

自主学習を継続したい!!!!!!

 優秀なプログラマーは自分で最新の情報を仕入れて、プライベートでもコード書いているっていうよね。かっこいいなあ。私も優秀なプログラマーになりたいなー。とふわっと考えて、作りたいもの練って見るんだけど、凡人プログラマー未満の癖にやけに壮大なことを考えるせいで、大体アイデアだけで飽きる。時々、環境作ろうとはするものの、どうせならやったことない言語で描こうとして、完璧な環境構築しようとした結果、HelloWorldで満足してしまう。なんとか、継続できないかと悩んだ苦肉の策の話です。

目次

・初めに
・GitHubにプロジェクトを作る
・やりたいことをissueに書き出す
・ひとまずdevelopブランチを切る
・僅かにでも進捗得たらコミット
・issue単位でpush&pullrequest
・まとめ

初めに

 タグはほぼ詐欺です。私がたまたまチョイスしたのがReact、redux、ついでに言うと、firebaseでホームページを作ろうとしていただけです。環境構築方法については、他の方が非常にわかりやすくまとめているのでそちらを参考にしてください。
React + redux + typescript
React + Redux + Firebase
 今回、タスク管理のために、社内で行なっているアジャイル開発のノウハウを取り入れてみました。ベンチャー企業の行う理想的なアジャイル開発とは異なるため、「こんなのアジャイルじゃない!!」と言う方も多々いると思いますがご容赦ください。また、ここで紹介する方法は、3日坊主の方や、やりたいことが壮大になっちゃうんだけどすぐに飽きちゃうという、多少ぐうたらな人向けに書いています。タスク管理なんてできて当然と言う方は、私はぐうの音も出ないため戻った方が効率的です。ただし、gitについての知識はある前提になります。

GitHubにプロジェクトを作る

 はいタイトルにあるようにGitHubを使います。アカウント無い人は作成してください。で、とりあえずプロジェクトを作成します。ここまではまあ調べてください。
そしたらcloneしましょう

git clone https://github.com/xxxxx/xxxxxxxx.git

 作成したら使用する言語を決めて、ローカル環境で一番最初の作業 だけやったら、buildできることだけ確認してpushしてしまいましょう。私は初回はmasterにpushしてしまいました。直接が嫌な方はbranch切ってやってください。
スクリーンショット 2019-02-26 23.15.36.png

私はReactを使いたかったので、

create-react-app

コマンドで環境構築した時点でpushしてしまいました。

やりたいことをissueに書き出す

 はい。面倒臭がりな私ですが、無駄に凝り性なので、やりたいことをissueに書きます。私の粒度は下記のような感じでした
スクリーンショット 2019-02-26 23.19.54.png

で、issueの中に実際にやることを書きます
スクリーンショット 2019-02-26 23.22.15.png

スクリーンショット 2019-02-26 23.21.28.png

書いてみると、割とやること多いんですよね。そこでアジャイルの思想が出てくるのですが、基本的に完成版をイメージしてはいけません。あくまでも直近でやるべきことから書いていきます。私の場合は環境構築で挫折することが多い人間なので、環境構築ステップを一通り洗った時点で一度issueの洗い出しをやめました。

issue作成のポイントをまとめると
・作るものを決める
・作成のためのステップを出来るだけ細かくissueにする
・issueは作りすぎない

といった感じになります。issueをたくさん作りすぎると、こんなにたくさんできないやんけとなって、挫折するので、機能を実現できる最小単位で作るのがベストです。

ひとまずdevelopブランチを切る

 gitなら作業はmasterからブランチ切るっしょ。と言うことで、ひとまずdevelopに切ります。

git checkout -b develop

 今回は作業者が私だけなのでdevelopとmasterブランチしかありませんが、複数人で作業する場合は都度branchを切ってください。ただ、今回はソロでのお勉強なので2つあれば十分だと思います。そうしたら、issueの中で最も重要だと思うものを1つ選択して、実装に取り掛かります。

僅かにでも進捗得たらコミット

 スキあらばcommitしましょう。buildが通ればcommit。UIの文言変わったらcommit。Qiitaで参考にしたコードコピペしたらcommitくらいの感じで。私は変更箇所が100行超えないように心がけています。
 人によっては、commitの単位も機能単位にした方が良いと言う方もいると思います。それはおっしゃる通りですが、勉強を継続するには、commitは細かいに越したことは無いと思います(異論は認める)。例えば、reactのbootstrapを導入した時は、以下のレベルでcommitしました。(下記は、react-bootstrapのサンプルをコピっただけ)
スクリーンショット 2019-02-26 23.39.52.png

issue単位でpush&pullrequest

 動く単位でcommitを繰り返したら、リモートにpushしましょう

git push origin develop

そしたら、pullrequestを作成しましょう。(GitHubのbranchの横にあります。)
スクリーンショット 2019-02-26 23.52.34.png

developからmasterに向けてのpullrequestを作成します。(私はpackage.lock.jsonでconflict起きちゃいましたが)
ここで、pullrequestに関連するissueを本文に追加しておくとタスク管理がかなり楽になります。
スクリーンショット 2019-02-26 23.56.08.png

pullrequestを作成したら、スカッシュマージしてしまいましょう。(赤いのはレビュー通らないとマージできない設定入れているからです。通常は緑)
スクリーンショット 2019-02-27 0.01.34.png

スカッシュマージは、▼から選べます。基本的にスカッシュを推奨します。スカッシュマージは、pullrequestでマージする全てのcommitをpullrequestのタイトルcommit1つにまとめてくれるため、historyがすっきりします。また、コミット内容が確認したければ、githubのinsight > networkから、commitを辿ることで細かい修正も確認できます。
スクリーンショット 2019-02-27 0.07.12.png

スクリーンショット 2019-02-27 0.03.26.png

またpullrequestにissueの番号を入れておくことで、issueの方にも関連が持てます。(pullrequestで#3を説明部分に記載した時)
スクリーンショット 2019-02-27 0.12.40.png

明示的にissueが完了したことがわかるので、issueはcloseしちゃいましょう
スクリーンショット 2019-02-27 0.14.42.png

あとは、developにブランチを切るところからの繰り返し

まとめ

 タスク管理ツールなんていくらでもあるので適材適所だとは思いますが、今回はgithubだけで管理してみました。長い目で機能を考えると大抵挫折するので、アジャイルに細々としたリリースを心がけ、なおかつ直近にできるタスクをissue化して実装を繰り返していった方が、個人での実装なら良いのでは無いかと。
 まあ、本来のissueの使い方では無いと思いますが、私はこんな使い方をしてみましたと言う共有でした。

もっと便利に運用できるぜってコメントがあればぜひご教授ください。(本来の使い方じゃ無いぜ。とか、よくみたら変なcommit入っているやんけとかの意見もあると思いますが、勉強中の身ゆえ許してください)

# 補足
こんなふわっとしたやり方じゃダメでしょって人は、もっと丁寧に書いてくれた人がいました
https://qiita.com/suzuki-hoge/items/3a568dff36fd981082ba
ただ、個人の勉強レベルで期限決めたりテンプレ作ったりはその時点でめんどくさくなっちゃうので、これくらいなら一人でも継続できそうだなってレベルで今回の記事は書きました。

4
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
4
6