refirio.org

基本メモ

Git初心者への説明用メモ。 以下から同じ内容をスライドショーなどで見ることができる。 Gitの基本 - Qiita https://qiita.com/refirio/items/938ebf399029d9c62b3f ■バージョン管理システムとは ・作業内容を記録していくことができる。 ・過去の作業内容を簡単に把握できたり、特定の日時の状態に戻したりができる。 フォルダを丸ごとコピーし、日付を付けて置いておく…というのもバージョン管理の一つ。 ただしその方法だと、細かな変更内容を把握するのは難しい。 また、コピーでの管理は以下のような状態になりがち。複数人での管理となると、さらに煩雑になる。 Gitでバージョン管理することにより、いつでも過去の状態を参照できるようになる。 ホスティングサービスを介することで、複数人での作業にも対応できる。 なお、GitはLinux（サーバ用のOS）のコア部分のソースコードを管理するために、Linuxの作者によって開発されたもの。 そのため、画像などコード以外の管理をしようとすると、使えないわけでは無いが使い勝手はイマイチ。 （例えば「差分を把握しづらい」「巨大な1ファイルを扱えないことがある」など。） ■Gitの特徴 以下の特徴を持つバージョン管理システム。 ・分散型 ... 一度サーバからソースコードを取得すればオフラインで作業でき、任意のタイミングでサーバに反映できる。 ・高速 ... SVNなど他のバージョン管理システムよりも、高速に動作する。 ・賢いマージ ... 他のバージョン管理システムよりも、作業内容を賢くまとめてくれる。 ■リポジトリ ソースコードは「リポジトリ」と呼ばれる場所で管理する。 リポジトリは基本的に、ホスティングサービス上で作成するといい。 ■ホスティングサービス リポジトリを管理してくれる場所。 一人で作業する場合は無くてもいいが、バックアップのためにも使用することを推奨。複数人で作業する場合は必須。 有名どころだと、以下のようなものがある。 ・GitHub 一番メジャーだと思われる。オープンソースで公開する場合に最適。非公開リポジトリを作りたい場合は有料。 …だったが、2020年に非公開リポジトリもチーム利用も無料になった。 https://github.com/ https://github.com/pricing https://www.publickey1.jp/blog/20/githubactionscicd.html ・Bitbucket 無料で非公開リポジトリを作れる。1リポジトリに5ユーザ以上参加させたい場合は有料。 https://bitbucket.org/ https://bitbucket.org/product/pricing ■Git操作 ・コマンドで操作する。 ・Sourcetreeなどグラフィカルなソフトウェアで操作する。 の2つがある。 WindowsやMacで使うなら、グラフィカルなソフトウェアを使うといい。 ■Bitbucketでのアカウント作成 ※Bitbucketを使用する場合のアカウント作成手順 ※すでにアカウントを作成している場合は不要 Bitbucket https://bitbucket.org/ 「Get it free → アカウントを作成」からアカウントを作成する。 （メールアドレスは、原則 terraport.jp のアドレスを使用する。） アカウントを作成したら、引き続きアプリパスワード （SourcetreeからBitbucketにアクセスする際に使用するパスワード）を作成する。 設定の「アプリ パスワード」ページを開く https://bitbucket.org/account/settings/app-passwords/ 「アプリパスワードの作成」ボタンをクリック。 「詳細」の「Label」に「Sourcetree」と入力。 「権限」はすべての項目にチェックを入れておけばいい。（もしくは必要に応じて取捨選択する。） 「作成」ボタンをクリック。 「新しいアプリパスワード」が表示されるので控えておく。 （このパスワードは再表示できないので注意。） ■SourcetreeでのGit操作 あらかじめ、作業用フォルダ内に「git-test」フォルダを作っておく。 内容はカラにしておく。 ブラウザで以下のページにアクセスする。（アクセスできない場合、管理者に連絡して権限を付与してもらう。） https://bitbucket.org/terraportinc/git-test 「Clone」ボタンを押すと「Clone this repository」の画面が開く。 「SSH」を「HTTP」に変更すると以下のようなコードが表示されるので、「https」以降の部分をコピーしておく。 引き続き、Sourcetreeで作業。 上部にある「＋」をクリック。 メニューから「CLONE」をクリック。 元のパス/URL: リポジトリのURLを入力。 保存先のパス: 保存したい場所を入力。「元のパス/URL」を入力すると自動入力されるが、今回は「git-test」フォルダの場所を指定する。 名前: 案件を判別できる名前。Sourcetreeでの表示に使われるだけなので日本語も可。 「クローン」ボタンを押すとクローンされる。 実際にファイルを配置して、コミットやプッシュを試す。 ※クローン時に認証できない場合、先に「ツール → オプション → 認証」でアカウントを追加すると解決することがある。 ■作業の記録 ※ローカル環境で実際に操作をしてもらいつつ説明。 「何かしらの作業を行い、コミットして変更内容を記録する」というのが基本の流れ。 ファイルの状態には以下の3つがある。 ・作業中のファイル。 ・次にコミットされる（＝ステージングエリアにある）ファイル。 ・コミットされたファイル。 作業中のファイルをステージングエリアに移動させ、それらのファイルに対してコミットを行う。 ステージングエリアがあることにより、一部のファイルのみコミット対象にすることができる。 これにより、あとで振り返ったときに解りやすいコミット履歴にできる。 例えば「DEV-104 サービス紹介ページの改修」という課題があったとして、 というひとまとめのコミットにしてもいいが、 のようにしておくと、「写真と文章を追加で更新したい」という場合に作業箇所が解りやすくなる可能性がある。 ■クローン リポジトリの内容をローカルにコピーすること。 Gitではサーバ上だけでなくローカルにもリポジトリの複製を持ち、定期的に同期させる。 ■コミットとプッシュとプル ・コミット ... ローカルのリポジトリに作業を記録する。 ・プッシュ ... コミット内容をサーバのリポジトリに記録する。 ・プル ... サーバのリポジトリの内容をローカルのリポジトリに反映する。（他の人の変更内容を取り込む。） ■ファイルの状態 ・作業フォルダ ... 作業中のファイル。 ・ステージングエリア ... 次にコミットされるファイル。 ・リポジトリ ... コミットされたファイル。 の3つがある。 作業フォルダにあるファイルをステージングエリアに移動させ、 それに対してコメントとともにリポジトリに移動させる。（＝コミット。） ステージングエリアがあることにより、一部のファイルのみコミット対象にすることができる。 ここまでできれば、最低限だがGitを使うことができる。 ■ブランチとマージ ブランチを作れば、いくつもの作業を同時に進めることができる。 作業が完了したら、もとの場所にマージ（統合）することができる。 複数人で作業するときに、特に力を発揮する。 ■デフォルトブランチ 最初にコミットすると作成される、デフォルトのブランチ名は自動的に「master」となる。 「master ブランチは本番環境（成果物）と同一」という運用をされることが多い。 ただし「master」という名前は差別用語になりうるので、「main」という名前にしようという動きがある。 実際GitHubのデフォルトブランチは「main」に変更された。他のサービスもその流れになっている。 ■コンフリクト マージの際、作業内容が競合したことをいう。 Sourcetreeの場合、競合しているファイルを右クリックし、「競合を解決」から解決方法を選択できる。 主に以下の対応がある。 ・マージする方の作業が正しいとみなす。（「自分の変更内容で解決」としてコミット。） ・マージされる方の作業が正しいとみなす。（「相手の変更内容で解決」としてコミット。） ・手動で調整する。（「解決とマーク」としてコミット。） なお競合が発生した箇所は、自動で以下のように書き換えられる。 手動で調整して解決する場合、「<<<<<<< HEAD」などの情報は不要なので削除する。（「自分の変更内容で解決」などとした場合はGitが調整してくれる。） ■ブランチモデル gitでは自由にブランチを作成できるが、何のルールも無く作成すると混乱のもとになる。 有名どころのルールとして以下がある。 ・GitHubフロー ... 小規模開発向け。 mainブランチから開発用ブランチを作成し、作業が完了したらmainブランチに戻す。 ・Gitフロー ... 中規模〜大規模開発向け。 main、develop、feature、release、hotfix という5種類のブランチを使い分ける。 ・GitLabフロー ... mainブランチから開発用ブランチを作成し、作業が完了したらmainブランチに戻す。 またproductionやstagingなど、環境に応じたブランチを持つ。 mainブランチは本番環境とイコールではなく、開発の中心ブランチとなる。 ・トランクベース開発 ... 開発者は短命なfeatureブランチを作って作業する。 プログラムが動く状態を保ちながら、小さな修正をすぐmainブランチにマージし、本番環境にも反映する。 大きな機能開発の場合、機能のON/OFFをフラグで管理する。 これにより、大規模なマージ地獄から抜けられる。 自動テストが整備されていることが前提となる。 【図解】git-flow、GitHub Flowを開発現場で使い始めるためにこれだけは覚えておこう：こっそり始めるGit／GitHub超入門（終） - ＠IT https://www.atmarkit.co.jp/ait/articles/1708/01/news015.html git flowとgithub flowとは？その違いは？ - Qiita https://qiita.com/mint__/items/bfc58589b5b1e0a1856a Gitlab-flowの説明 - Qiita https://qiita.com/tlta-bkhn/items/f2950aaf00bfb6a8c30d GitLab flowから学ぶワークフローの実践 | POSTD https://postd.cc/gitlab-flow/ アプリ開発にはGitlab flowが合うと思います - Shoichi Matsuda's diary https://shoma2da.hatenablog.com/entry/2015/11/04/233534 Git の最新アップデートから考える開発手法の潮流 - Speaker Deck https://speakerdeck.com/yuukiyo/trends-in-development-methodology-from-the-latest-git-updates DevOps 技術: トランクベース開発 | DevOps の能力 | Google Cloud https://cloud.google.com/architecture/devops/devops-tech-trunk-based-development?hl=ja もうリリースは怖くない ― 大きな変更を安全に本番適用するTips - Cybozu Inside Out | サイボウズエンジニアのブログ https://blog.cybozu.io/entry/2021/07/28/080000 これらのブランチモデルをベースに、独自のブランチモデルで運用しているところもある。 元々はGitフローが大規模案件での定番だったが、本来これはパッケージ製品のソフトウェアを作るために考えられたもの。 頻繁に更新されるWebアプリケーション開発には向かない、とも言われている。 最近のWebアプリケーション開発ではトランクベース開発の採用が増えてきているように思うが、現状テラポートでは採用されていないので深くは触れない。 ■コミットの粒度とメッセージ あとで見直しやすいように、ということを意識してコミットするといい。 「コミットの際に課題番号も書く」など、独自のルールが設けられることも多い。 ■.gitignore バージョン管理対象外にするファイルを指定できる。 Thumbs.db や .DS_Store は管理対象外にしておく。 その他環境依存の設定ファイルや、巨大すぎる動画ファイルやライブラリも省いておくと管理しやすくなる。 ■課題管理・Wiki 大抵のホスティングサービスには用意されている。 うまく使うと便利。この部分は、BacklogやRedmineなど他のサービスやツールを使うこともある。