エンジニアにわざわざ細かいCSSの修正や文言修正を依頼するのは全体の開発効率を考えるとあまり良いことではないと私は思っています。実装されたものに対して「あ、これちょっと違う...」というとき、ディレクターやデザイナーが自分で修正してちゃんと反映されたらみんながハッピーですよね。
今回は弊社のGit・GitHubの使い方を知らないインターン生などが、さくっと文言修正できるようドキュメント化したいなと思ってふんわりとまとめてみました。あくまで修正ができればいいという目的の記事なため、Git・GitHubの厳密で正確なことについては他のサイトを参考にしてください。ググりましょう。
ターミナルのようなCLI(いわゆる黒い画面)を使わずに進めていくのでそういったものが苦手な方もご安心ください。
【スポンサーリンク】
GitとGitHubって何？
自分的解釈のふんわりした用語解説①
Git…ソースコードのバージョン管理をするためのシステム
GitHub…Gitを利用してソースコードとか色々公開するための便利なサービス
GitとGitHubは別物です。これ最初の頃は私も勘違いしてました。
別にここの違いを詳しく知ったところで特に今回そこまで影響はないのでこれくらいの雑な認識でいいと思います。
コード修正にゼロから挑戦する
1. 開発用ディレクトリを作成する
まず開発用に使うディレクトリ(フォルダ)を持っていない人は適当な場所に作成しましょう。ちなみにおすすめの場所はホームディレクトリ(~/User/ユーザ名(大体は自分の名前かな)/)です。名前は「dev」とかでいいのではないでしょうか。
つまるところ「~/User/xxx(ユーザ名)/dev」というディレクトリができます。
2. リモートリポジトリをCloneする
自分的解釈のふんわりした用語解説②
リモートリポジトリ…ネットワーク上にあるそのプロジェクトのデータ保管場所
Clone(クローン)…手元にデータを持ってくること
今回は既にあるものに対して修正を行っていくという想定なのでリモートリポジトリは存在するかと思います。まずはリモートリポジトリを自分の手元(ローカルリポジトリ)に持ってきましょう。また、目的のリポジトリにアクセスできる前提です。
CLIを使わないのでまずはGitHub Desktopをダウンロードしてください。
ダウンロードして開くと自分のGitHubアカウントでログイン等を求められるのでログインします。
ここまで完了したら「Clone a Repository」を選択。
どのリポジトリをCloneするのか選択できるので自分が修正したいファイルのあるリポジトリを選択します。また、Local Pathは先ほど作った開発用ディレクトリにしておきましょう。最後に「Clone」を押せば完了です。
3. 新しいBranchを切る
自分的解釈のふんわりした用語解説③
Branch(ブランチ)…メインの流れ(コードとか)から分岐した別の流れ的なもの
Master Branch(マスターブランチ)…上で言うところのメインの流れ、本番環境のコード、単にMaster(マスター)とも言う
リモートリポジトリをCloneしたらはいじゃあコードを修正していきましょうとは行かず、Masterから新しくBranchを切る(作成する)必要があります(どうしてかはググるかお近くのエンジニアに聞いてみましょう)。
[Branch]→[New Branch]から新しくBranchを作成します。
Branch名はどんな変更を加えるかわかりやすい名前にしましょう(例. fix-for-labels-XXXとか)。
Current Branchが変更されていればOKです。
4. 目的のファイルを探してコードを修正・保存する
ここまでできたらあとは目的のファイルを開いてAtomなりVScodeなりで修正・保存をします。VimはNo。
文言修正だけなら該当する文言を検索してヒットさせた方が早く見つかります。
5. 変更をCommit&Pushする
自分的解釈のふんわりした用語解説④
Commit(コミット)…自分の行った変更をローカルリポジトリに反映すること
Push(プッシュ)…ローカルで行った変更をリモートリポジトリに反映すること
修正が完了して保存をするとGitHub Desktop上では変更のあったファイルが左カラムに表示されているかと思います(画像では0 changed filesですが)。
「Summary(required)」にはCommit名を、「Description」にはどんな内容なのかを記入してCommitします(Descriptionは省略可能です)。
そして最後にPublish Branch(Push)をすれば完了です。
6. Pull Requestを出す
自分的解釈のふんわりした用語解説⑤
Pull Request(プルリクエスト)…自分の行った変更なんですけどこれ間違ってないですか？もっとこうした方がいいとかありますか？とチームに聞く機能
そのまま[Branch]→[Create Pull Request]をします。
するとGitHubのページが立ち上がってPull Requestを飛ばすことができます。どんな変更を加えたかコメントしましょう。CSSを修正して見た目が変わったときなどはBeforeとAfterのイメージを挿入しておくとレビュワーがうれしいですね。
Pull Requestの良いつくり方はクックパッドさんのこの記事が非常に参考になります。
また、右カラムにある「Reviewers」にレビューしてほしい人を追加することも忘れずに！
7. レビューしてもらう
レビュワーにレビューをしてもらいましょう。一発OKほしい。
8. 修正する
レビューの結果、更に修正が必要になった場合はそのままエディタでもう一度コードを編集・保存をし、GitHub Desktopを通じてCommit&Pushをもう一度しましょう。その後再度レビューお願いしますとレビュワーに依頼すればOKです(再度Pull Requestを出す必要はない)。
9. Mergeする
自分的解釈のふんわりした用語解説⑥
Merge(マージ)…あるBranchを別のBranchと合体させること
(レビュワー全員からApproveされたら)Master(or目的のBranch)に今まで作業していたBranchをMergeします。GitHubのPull RequestのページからMergeすることができます。ここらへんのMergeのルール等は開発チームごとに方針が違うと思うので有識者に聞くと良いと思います。
Mergeが完了したら修正完了です！MasterにMergeされて自動デプロイ設定がされていればそのまま本番環境に反映されますね！
既にリポジトリがローカルにある場合
リポジトリが既にローカルにある場合はMasterからFetch OriginをしてからBranchを切って修正、という流れになります。
最後に
無理してCLIを使わずにGit・GitHubを入門してみると意外と簡単じゃん！となったかと思います(私はなった)。インターネット上にある情報は大体CLIで操作していて初心者お断り感が強かったのでそういうのが苦手な人の参考になればうれしいです。
コアな部分を開発しているエンジニアにわざわざ細かい修正を投げなくてもいいようになるとチーム全体の効率がアップするのでみんながこうして修正できる世界になっていくといいですね。