はじめに
半年ほど前からプログラミングを勉強しはじめ、
幸運にも勤務先で簡単な開発に携われることになり
その際、複数人でGithub上でバージョン管理するため
教えてもらった便利な機能等を自分用にまとめていこうと思います。
あと初めてなのでまとめ方とかは下手くそなのと情報はこれから知っていくことがほとんどなのでそのあたりはご愛嬌。
対象
あくまで私自身が初心者なので、自分用のメモ帳および得た知識を固めるためのアウトプット的な部分が大きいのですが
同じようにこれからやっていくぞといった方のちょっとした手助けになればいいなと思いつつまとめていきます。
Githubとは
開発者のためのプラットフォーム
GitHubは、ユーザのみなさんからヒントを得て作成された開発プラットフォームです。オープンソースプロジェクトやビジネスユースまで、GitHub上にソースコードをホスティングすることで数百万人もの他の開発者と一緒にコードのレビューを行ったり、プロジェクトの管理をしながら、ソフトウェアの開発を行うことができます。(Githubより抜粋)
つまるところ大勢の開発者が利用していて、Github上でそれぞれの携わっているプロジェクトのソースコードを保存・管理したり他のソースコードを参考にしたりしながら開発を進めていきましょうねってことだと理解しています。
まあこの辺りは目的から逸れるので簡単にしておきます。
ブランチ
ブランチを切るときにprefixを付ける
これは現場によるのかもしれませんが、何らかの作業時にブランチを切る際、ブランチ名にadd
とかfix
とかfeature
とか、大まかな目的のprefixを記入して、その後に実際にする作業の内容をブランチ名として設定しておくとパッと見で判断できるので便利でした。
ざっくりadd/add_user_id_columns_to_users
みたいな感じ。
プルリクエスト
PR作成時に対応するissueと関連付ける
issueに対してプルリクエストを作成する際、descriptionに対応するissueの番号を記入しておくと
そのissueの情報が勝手に紐付いてくれて便利でした。
#1928
<= こんな感じに書いておくとマウスオーバーした際に情報が参照できる。
PRがマージされたタイミングで自動的にissueをクローズする
PR作成時のコミットメッセージにfix #1928
のようにfix/fixed/fixes + issueの番号
を記入しておくと
そのPRがマージされたタイミングで対応するissueが自動的にクローズされるので手間が省ける。
見た目を改変するPRの際は手っ取り早く写真を見せた方が良さそう
もちろんコードの差分を見てレビューしてもらうのですがそれだけではパッとわかりにくいこともあると思うので
変更前と変更後の写真をPRのdescriptionに貼っつけとくと良さそうでした。
markdown使えるのでテーブル作って
変更前 | 変更後 |
---|---|
変更前の写真 | 変更後の写真 |
こんな感じで並べとくとわかりやすいなって思いました。
必要/不必要は場合によると思うのでその辺りは時と場合による感じで。
おわりに
一人で勉強しているときはとりあえずコード書いていたのですが、実際に現場で作業するとなるとgithub等でのレビューフローにも慣れないとなと思ったのでまとめてみました。
まだそれほど知識も溜まっていないので少ない中でもある程度必須かなと思う部分を抜粋してます。
今後も出来るだけ追記して行きたいですね。