これまでのGitシリーズでは次の内容を解説してきました。
- Gitとは
- GitとGitHubの違い
- 基本コマンド
- ブランチ
- merge
- コンフリクト
- GitHub Flow
これらを理解すれば Gitの基本操作 はほぼ身についています。
しかし実際の開発では
どうGitを使うかという 運用ルール（ベストプラクティス） が非常に重要になります。
この記事では、実務でよく使われる Gitのベストプラクティス を紹介します。
小さくコミットする
Gitで最も重要なルールの1つが
小さくコミットすることです。
悪い例
UI変更
API追加
バグ修正
リファクタリングこれらを 1つのcommitにまとめることです。
良い例
add login UI
add login API
fix login validation bugつまり
1コミット = 1変更が理想です。
これにより
- 履歴が分かりやすくなる
- バグの原因を追いやすくなる
というメリットがあります。
分かりやすいコミットメッセージを書く
コミットメッセージは
変更内容の説明です。
悪い例
fix
update
changeこれでは履歴を見ても何を変更したのか分かりません。
良い例
add login form
fix header layout bug
update API request logicコミットメッセージを書くときのポイント
動詞から始める
変更内容を具体的に書く
短く簡潔に書くmainブランチを直接編集しない
実務では
main = 本番コードとして扱います。
そのため
mainを直接編集することは基本的にありません。
代わりに
featureブランチを作ります。
例
feature-login
feature-payment
fix-headerこのブランチで開発を行い、最終的に Pull Request でmainに統合します。
ブランチは短命にする
ブランチは長期間残すと問題が起きます。
例えば
2週間前のブランチをmergeすると
コンフリクトが発生しやすくなります。
そのため
小さな機能ごとにブランチを作り
早くmergeすることが重要です。
作業前にpullする
チーム開発では
他の開発者もコードを変更しています。
そのため作業前には
git pullを行います。
これにより
最新コードを取得できます。
push前に確認する
pushする前に次のコマンドを確認します。
git statusこれにより
- 変更内容
- ステージング状態
を確認できます。
また
git diffを使うと変更内容の詳細を見ることができます。
不要なファイルをGitに入れない
Gitでは
機密情報を絶対にpushしてはいけません。
例
.env
APIキー
パスワードこれを防ぐために
.gitignoreを使います。
例
node_modules
.env
distPull Requestを活用する
GitHubでは
Pull Requestを使ってコードレビューを行います。
Pull Requestのメリット
- コードレビュー
- バグ防止
- 開発の透明性
チーム開発では必須のプロセスです。
Git履歴を整理する
Git履歴が汚くなることがあります。
例
fix
fix
fixこの場合
rebase
squashを使って整理することもあります。
ただし初心者は
基本操作を優先しましょう。
Gitの基本開発フロー
GitHub Flowを使った基本フロー
git pull
↓
git switch -c feature-login
↓
開発
↓
git add
↓
git commit
↓
git push
↓
Pull Request
↓
mergeこれが現在のWeb開発で最も一般的なGitの使い方です。
Gitを上達するコツ
Gitを上達するためのポイント
小さくcommit
頻繁にpull
安全にbranchこの3つを意識するだけで、Gitの運用はかなり改善されます。
まとめ
この記事では Gitのベストプラクティス を解説しました。
重要なポイント
小さくcommit
分かりやすいメッセージ
branch開発
Pull RequestGitを正しく使うことで
安全で効率的な開発が可能になります。
Gitシリーズまとめ
このシリーズでは次の内容を解説しました。
Gitとは
GitとGitHubの違い
基本コマンド
add / commit
branch
checkout
push
pull
merge
コンフリクト
GitHub Flow
ベストプラクティスこれらを理解すれば Gitの基礎はほぼマスターです。
コメント