なぜ必要なのか
旅行サイトで友人が日ごとの訪問先を決めます。開発者はオフラインでも別々の実験を進めたいと考えています。ローカル履歴とGit対応ホスティングを優先し、既存のSVNツール維持を優先するならSubversionが合います。
どう解決するのか
新しい訪問先をローカルブランチにコミットしても、リモートにはまだありません。接続後にpushし、同僚がfetchします。両方の履歴を確認し、pushが拒否されたら履歴を調整します。
旅行の訪問先がローカル履歴から共有ブランチへ移動旅行サイト · 手順の例
手元で記録、準備ができたら共有
01 / 開発者の端末
編集:博物館への訪問を追加
git commit ↓ ローカルに記録
main · 元の日程
museum-stop
新コミット:博物館への訪問
ローカルコミットはオフラインでも可能02 / git push →接続 + 権限
共有リポジトリ
push前:新しい訪問先なし
push成功後
museum-stop
03 / git fetch ↓
同僚がブランチを取得
commit ≠ push。拒否されたら履歴を調整します。ホスティングとレビューは別の選択です。
どんな考え方なのか
Gitは分散バージョン管理です。commitはローカルに記録し、pushは別のリポジトリと共有します。GitHubなどのホスティングはGitに協業機能を加えます。競合の解決には判断が必要です。
出典
さらに詳しく
任意の参考資料 · 概要の読了時間には含みません
01選択・比較
履歴の場所、オフライン作業、協業、ファイルの性質、既存ツールを比較します。Gitはローカルリポジトリにコミットとブランチを持ちます。Mercurialも分散作業に対応し、既存のhg運用維持が移行より有利な場合があります。SVNは中央にコミットし、P4はバイナリ素材の排他的編集を管理する既存チームに合う場合があります。
02応用例
旅行サイトは別ブランチで博物館への訪問を試します。ローカルコミットはエディターを閉じても残りますが、push成功までは共有リポジトリにありません。同僚はfetchしてから確認・統合します。Gitホスティングは別の選択です。このカタログのホストはGitと組み合わせるもので、全バージョン管理のサーバーとして交換できるわけではありません。
03実装の参考・注意点
コミット前にgit statusと対象ブランチを確認します。push前にリモートと権限を確認し、分岐した履歴は同僚の変更を強制的に上書きせず調整します。Gitのクローンだけではホストの課題・レビュー・設定をすべて保存できません。移行時は別途エクスポートを試します。
04根拠
比較のまとめ
続けて読む
原稿・修正提案 ↗自分のプロジェクトに活かす
これからプロジェクトを始めますか?説明を入力して最初のプロンプトを準備しましょう。
自分に合うプロンプトを作る →すでに外部AIと会話中なら、この記事のリンクと自分のプロジェクトに合う理由、重視する利点や制約を伝えましょう。合意した要件にどう適用するか依頼してください。
この記事のリンク: Git
この選択を話し合う
コメントは全言語で共有。投稿にはGitHubログインが必要です。