{"meta":{"title":"Git について","intro":"バージョン コントロール システム Git と、それが GitHub とどのように連携するかについて説明します。","product":"概要","breadcrumbs":[{"href":"/ja/get-started","title":"概要"},{"href":"/ja/get-started/using-git","title":"Git の使用"},{"href":"/ja/get-started/using-git/about-git","title":"Git について"}],"documentType":"article"},"body":"# Git について\n\nバージョン コントロール システム Git と、それが GitHub とどのように連携するかについて説明します。\n\n## バージョン管理と Git について\n\nバージョン管理システム (VCS) は、人々とチームが一緒にプロジェクトで共同作業を行う際の変更履歴を追跡します。 開発者がプロジェクトに変更を加えると、そのプロジェクトの以前のバージョンはいつでも復元できます。\n\n開発者は、プロジェクトの履歴を確認することで、次のことを知ることができます。\n\n* どのような変更が行われたのか?\n* 誰が変更したのか?\n* いつ変更されたのか?\n* なぜ変更が必要だったのか?\n\nVCS により、各共同作成者にプロジェクトの統一された一貫性のあるビューが用意され、既に進行中の作業が表示されます。 誰が変更したか、どのようにプロジェクトの開発に協力したかという透明性のある変更履歴を見ることで、チーム メンバーは独立して作業しながら、足並みを揃えることができます。\n\n分散バージョン管理システムでは、すべての開発者がプロジェクトとプロジェクト履歴の完全なコピーを持ちます。 かつて一般的だった集中型バージョン管理システムとは異なり、DVCS は中央リポジトリへの常時接続を必要としません。 Git は、最も一般的な分散型バージョン管理システムです。 Git は、open sourceと商用ソフトウェア開発の両方で一般的に使用され、個人、チーム、企業にとって大きな利点があります。\n\n* Git を使うと、開発者は自分の変更、決定、あらゆるプロジェクトの進行のタイムライン全体を 1 か所で見ることができます。 開発者はプロジェクトの履歴にアクセスした時点から、必要なすべてのコンテキストが揃い、理解して共同作業を始めることができます。\n\n* 開発者はあらゆるタイム ゾーンで作業します。 Git のような DVCS を使うと、ソース コードの整合性を維持しながら、いつでもコラボレーションを行うことができます。 ブランチを使うと、開発者は運用コードに対する変更を安全に提案することができます。\n\n* Git を使っている企業は、チーム間のコミュニケーションの壁を取り払い、最高の仕事をすることに集中させることができます。 さらに、Git を使うことで、ビジネス全体でエキスパートを集めて、大きなプロジェクトで共同作業をすることが可能になります。\n\n## リポジトリについて\n\nリポジトリ (Git プロジェクト) には、プロジェクトに関連付けられたファイルやフォルダーのコレクション全体と、各ファイルのリビジョン履歴が含まれます。 ファイルの履歴は、コミットと呼ばれる時間的なスナップショットとして表示されます。 コミットは、ブランチという複数の開発ラインで構成されています。 Git は DVCS であるため、リポジトリは自己完結した単位であり、リポジトリのコピーを持っている人は誰でもコードベースとその履歴全体にアクセスできます。 Git リポジトリでは、コマンドラインや他の使いやすいインターフェイスを使うことで、履歴とのやりとり、リポジトリのクローン、ブランチの作成、コミット、マージ、コードのバージョン間での変更点の比較なども可能です。\n\nGit を使うと、GitHub などのプラットフォームを通じて、プロジェクトの透過性とコラボレーションの機会をさらに広げることもできます。 パブリック リポジトリは、チームが連携して可能な限り最高の最終製品を構築するのに役立ちます。\n\n## GitHub のしくみ\n\nGitHub は、Git リポジトリをホストしています。また、コマンド ライン機能、issue (スレッド形式のディスカッション)、pull request、コード レビュー、または GitHub Marketplace にある無料および有料アプリのコレクションの使用によって、より優れたコードをリリースするためのツールを開発者に提供しています。 GitHub は、GitHub フローのようなコラボレーション レイヤー、1 億人の開発者コミュニティ、何百もの統合があるエコシステムを備えているため、ソフトウェアの構築方法が変わります。\n\nGitHub は、コラボレーションを開発プロセスに直接組み込んでいます。 作業はリポジトリにまとめられ、開発者は要件や方向性の概要を示し、チーム メンバーに期待することを設定できます。 その後、GitHub フローを使って、開発者は更新作業を行うブランチを作成し、変更をコミットして保存し、変更を提案および議論する pull request を開き、全員が合意したら pull request をマージするだけです。 詳しくは、「[GitHub フロー](/ja/get-started/using-github/github-flow)」をご覧ください。\n\nGitHub のプランとコストについては、[GitHub Pricing](https://github.com/pricing) を参照してください。 GitHub Enterprise が他のオプションと比較する方法については、「[他の DevOps ソリューションとのGitHubの比較](https://github.com/resources/articles/devops-tools-comparison)を参照してください。\n\n## GitHub とコマンド ライン\n\n### Git の基本的なコマンド\n\nGit の利用では、開発者は特定のコマンドを使って、コードのコピー、作成、変更、結合を行います。 これらのコマンドは、コマンド ラインから直接実行することも、GitHub Desktop のようなアプリケーションを使うこともできます。 以下は、Git を使うための一般的なコマンドです。\n\n* `git init` は、まったく新しい Git リポジトリを初期化し、既存のディレクトリの追跡を開始します。 既存のディレクトリの中に、バージョン管理に必要な内部データ構造を格納する非表示のサブフォルダーを追加します。\n\n* `git clone` は、既にリモートで存在するプロジェクトのローカル コピーを作成します。 このクローンには、プロジェクトのすべてのファイル、履歴、ブランチが含まれます。\n\n* `git add` は変更をステージングします。 Git は開発者のコードベースへの変更を追跡しますが、プロジェクトの履歴に含めるためには、変更をステージしてスナップショットを作成する必要があります。 このコマンドは、その 2 段階のプロセスの最初の部分であるステージングを実行します。 ステージされた変更は、次のスナップショットの一部となり、プロジェクトの履歴の一部となります。 ステージングとコミットを別々に行うことで、開発者はコーディングや作業の方法を変えることなく、プロジェクトの履歴を完全に管理することができます。\n\n* `git commit` はスナップショットをプロジェクトの履歴に保存し、変更追跡プロセスを完了させます。 簡単に言えば、コミットは写真を撮るような機能です。\n  `git add` でステージされたものは、`git commit` でスナップショットの一部となります。\n\n* `git status` は、未追跡、変更、ステージされた変更の状態を表示します。\n\n* `git branch` は、ローカルで作業しているブランチを表示します。\n\n* ```\n            `git merge` は、開発ラインを合わせてマージします。 通常、このコマンドは 2 つの異なるブランチで行われた変更を結合するために使われます。 たとえば、開発者が機能ブランチの変更をメイン ブランチにまとめてデプロイしたい場合、マージすることになります。\n  ```\n\n* `git pull` は、リモートリポジトリの更新を基にローカルの開発ラインを最新の状態にします。 開発者がこのコマンドを使うのは、チーム メイトがリモートのブランチにコミットし、その変更を自分のローカル環境に反映させたい場合です。\n\n* `git push` は、ローカルで行われたブランチへのコミットでリモート リポジトリを更新します。\n\n詳細については、[Git コマンドの完全なリファレンス ガイド](https://git-scm.com/docs)を参照してください。\n\n### 例: 既存のリポジトリに寄与する\n\n```bash\n# download a repository on GitHub to our machine\n# Replace `owner/repo` with the owner and name of the repository to clone\ngit clone https://github.com/owner/repo.git\n\n# change into the `repo` directory\ncd repo\n\n# create a new branch to store any new changes\ngit branch my-branch\n\n# switch to that branch (line of development)\ngit checkout my-branch\n\n# make changes, for example, edit `file1.md` and `file2.md` using the text editor\n\n# stage the changed files\ngit add file1.md file2.md\n\n# take a snapshot of the staging area (anything that's been added)\ngit commit -m \"my snapshot\"\n\n# push changes to github\ngit push --set-upstream origin my-branch\n```\n\n### 例: 新しいリポジトリを開始し、それを GitHub に公開する\n\nまず、GitHub に新しいリポジトリを作成する必要があります。 詳しくは、「[Hello World](/ja/get-started/start-your-journey/hello-world)」をご覧ください。 README、.gitignore、またはライセンス ファイル付きでリポジトリを初期化**しないでください**。 この空のリポジトリはあなたのコードを待っています。\n\n```bash\n# create a new directory, and initialize it with git-specific functions\ngit init my-repo\n\n# change into the `my-repo` directory\ncd my-repo\n\n# create the first file in the project\ntouch README.md\n\n# git isn't aware of the file, stage it\ngit add README.md\n\n# take a snapshot of the staging area\ngit commit -m \"add README to initial commit\"\n\n# provide the path for the repository you created on github\ngit remote add origin https://github.com/YOUR-USERNAME/YOUR-REPOSITORY-NAME.git\n\n# push changes to github\ngit push --set-upstream origin main\n```\n\n### 例: GitHub の既存のブランチに貢献する\n\nこの例では、マシン上に `repo` というプロジェクトが既にあり、ローカルで最後に変更が加えられてから新しいブランチが GitHub にプッシュされたと仮定しています。\n\n```bash\n# change into the `repo` directory\ncd repo\n\n# update all remote tracking branches, and the currently checked out branch\ngit pull\n\n# change into the existing branch called `feature-a`\ngit checkout feature-a\n\n# make changes, for example, edit `file1.md` using the text editor\n\n# stage the changed file\ngit add file1.md\n\n# take a snapshot of the staging area\ngit commit -m \"edit file1\"\n\n# push changes to github\ngit push\n```\n\n## 共同開発のモデル\n\nGitHub で共同作業を行うには、主に 2 つの方法があります。\n\n1. 共有リポジトリ\n2. フォークとプル\n\n共有リポジトリでは、個人とチームは、読み取り、書き込み、または管理者アクセス権を持つ共同作成者として明示的に指定されます。 この単純なアクセス許可構造と保護されたブランチなどの機能が組み合わされ、チームへの GitHub の採用を促進するのに役立ちます。\n\nopen source プロジェクトの場合、または誰もが投稿できるプロジェクトの場合、個々のアクセス許可を管理することは困難な場合がありますが、フォークとプル モデルを使用すると、プロジェクトを表示できるすべてのユーザーが投稿できます。 フォークとは、開発者の個人アカウントで行ったプロジェクトのコピーのことです。 すべての開発者は自分のフォークを完全にコントロールすることができ、修正や新しい機能を自由に実装できます。 フォークで完了した作業は、個別に保持されるか、pull request を介して元のプロジェクトに戻されて提示されます。 そこで、メンテナンス管理者はマージされる前に、提案された変更を確認できます。 詳しくは、「[プロジェクトに貢献する](/ja/get-started/exploring-projects-on-github/contributing-to-a-project)」をご覧ください。"}