更新履歴
2024-09-05
- masterをmainブランチにし、masterに対する言及をしました。
- httpsかsshか、についてはいろんな見方があることを追記
- 「PRの作成タンを押したら終わりではない」の項目を追加
はじめに
株式会社シンシアでは、実務未経験のエンジニアの方や学生エンジニアインターンを採用し一緒に働いています。
※ シンシアにおける働き方の様子はこちら
この記事は
- プログラミングを学び出したばかりの人
- エンジニアとして働きだしてGitHubを使い慣れていない人
という人向けに、共通してやってほしいなと思って、いつも言っていることを一般向けに書いたものです。
ぜひ読んで見ていただけると嬉しいです。
※ Githubとはなにか、具体的なGitの操作に関してはこの記事では割愛させていただきます。
git cloneするとき
Githubでは、https, sshによるgit cloneができます。
基本的に、httpsでgit cloneすると毎回パスワードを聞かれて面倒です。
実務でやるときは、いちいちパスワードを聞かれるのが面倒なので
- sshの設定
- httpsでパスワードを保存する設定
なお、個人的には複数のgithubアカウントを使ったり、GitLabなど他のGitサービスを併用する場合もあるので、sshが楽だなという気持ちです。
ssh接続でgit cloneするためには、
なお、鍵の作り方はこれを参考にするとよいです。
ブランチを切る時
作業を始めるまえに、gitでは作業ブランチを切って作業するのが一般的です。
ブランチを切る前に
ブランチを切る前に、必ず切る元のブランチを最新にしてください。
※ 基本的には、チームの方針に従ってください。この記事が必ずしも正解じゃない場合があります。
※ おそらくブランチを切る元は、main(古いプロジェクトだとmaster)かdevelopブランチです。（詳しくはチームの人に聞いて下さい）
以上です。
ブランチ名は適当ではよくない
チームのルールや連携しているツールにもよりますがgit flowやgithub flowで運用しているチームが多いです。
feature/*****とかでブランチを切るのが一般的です。
コミットをする時
ブランチ名を切る時と同じように、コミットメッセージも適当ではいけません。
1行で完結にかけばいいと思うので、下記の記事を参考にしてください
PRを作成するとき
通常の開発ではプロジェクト管理ツールを使っています。
プロジェクト管理ツールについては下記を読んでください。
プロジェクト管理ツールを使う時、チケットというものがあって、PRのマージとともにチケットをクローズしてほしいものです。とても便利なので良いです。
- github projectsを使っている場合
close #34のようにかけばOKです
- JIRAを使っている場合
- backlogを使っている場合
いまのところ知りません。どなたかコメントとかで教えていただけますとm(_ _)m
PRの作成タンを押したら終わりではない
※ この作業はPRの作成ボタンを押す前に行うのを推奨しますが、PRを押したあとにも確認をしたほうがいいです。
PR作成ボタンを押したら終わりではありません。
- 意図しないファイルがGitに上がっていないか
- そもそも修正漏れ・変なところがないか
をセルフレビューする週間をつけましょう
ちょっと脇道
PRを出すときに、レビューする方が見やすいように、PRの説明文を書いたほうがいいです。
※ PRは偉い人に見てもらって許可をもらうためのフローではなく、あくまでもコードを複数人でチェックしてコードの品質向上・バグの軽減を目的とした行為です。効率的にレビューするための工夫が必要です。
PRを作るときにテンプレートを用意しておくと良いと思います。
コンフリクトが発生したら
PRをマージする時
マージには3種類のマージ方法があります。
チームの方針に従いましょう。