序章

Gitのようなバージョン管理システムは、最新のソフトウェア開発のベストプラクティスに不可欠です。 バージョン管理により、ソフトウェアをソースレベルで追跡できます。 変更を追跡し、前の段階に戻り、分岐してファイルとディレクトリの代替バージョンを作成できます。

多くのソフトウェアプロジェクトのファイルはGitリポジトリに保持されており、GitHub、GitLab、Bitbucketなどのプラットフォームは、ソフトウェア開発プロジェクトの共有とコラボレーションを促進するのに役立ちます。

Gitをインストールした後、プロジェクトリポジトリを維持するためのコアコマンドに慣れるのに少し時間を費やす必要があります。 このチュートリアルでは、コマンドラインでGitリポジトリを作成してプッシュする最初の手順を説明します。

前提条件

  • 開発環境で利用可能なバージョン管理ツールGit。 Ubuntuで作業している場合は、 Ubuntu20.04へのGitのインストールを参照してください。

ステップ1—ワークスペースを作成する

既存のプロジェクトをGitリポジトリに変換する場合は、手順2に進むことができます。 それ以外の場合は、新しい作業ディレクトリを作成することから始めることができます。

  1. mkdir testing

次に、その作業ディレクトリに移動します。

  1. cd testing

そのディレクトリ内に入ると、Gitの機能を示すためのサンプルファイルを作成する必要があります。 あなたは空のファイルを作成することができます touch 指図：

  1. touch file

すべてのプロジェクトファイルがワークスペースに配置されたら、gitを使用してファイルの追跡を開始する必要があります。 次のステップでは、そのプロセスについて説明します。

ステップ2—既存のプロジェクトをワークスペース環境に変換する

を使用して、既存のディレクトリのGitリポジトリを初期化できます。 git init 指図。

  1. git init



Output
Initialized empty Git repository in /home/sammy/testing/.git/

次に、を使用する必要があります git add 既存のファイルをGitで追跡できるようにするためのコマンド。 ほとんどの場合、Gitは新しいファイルを自動的に追跡することはありません。 git add これは、Gitが以前に追跡していないリポジトリに新しいコンテンツを追加するときに必要な手順です。

  1. git add .

これで、アクティブに追跡されたGitリポジトリができました。 今後、このチュートリアルの各ステップは、既存のGitリポジトリを更新してコミットするための通常のワークフローと一致します。

ステップ3—コミットメッセージを作成する

Gitリポジトリに変更をコミットするたびに、コミットメッセージを提供する必要があります。 コミットメッセージは、行った変更を要約したものです。 コミットメッセージを空にすることはできませんが、任意の長さにすることができます。Githubなどの一部のプラットフォームでは、短いコミットメッセージを読みやすくするものの、非常に長く説明的なコミットメッセージを使用することを好む人もいます。

既存のプロジェクトを初めてGitにインポートする場合は、通常、「初期コミット」のようなメッセージを使用するだけです。 でコミットを作成できます git commit 指図：

  1. git commit -m "Initial Commit" -a



Output
[master (root-commit) 1b830f8] initial commit
 0 files changed
 create mode 100644 file

上記のコマンドには2つの重要なパラメーターがあります。 1つ目は-mです。これは、コミットメッセージ（この場合は「初期コミット」）が続くことを意味します。 次に、-aは、コミットに追加または変更されたすべてのファイルを含める必要があることを示します。 Gitはこれをデフォルトの動作として扱いませんが、将来Gitを使用する場合、ほとんどの場合、将来のコミットにすべての更新されたファイルをデフォルトで含めることができます。

単一のファイルまたはいくつかのファイルをコミットするために、次を使用できます。

  1. git commit -m "Initial Commit" file1 file2

次のステップでは、このコミットをリモートリポジトリにプッシュします。

手順4—変更をリモートサーバーにプッシュする

この時点まで、あなたは自分の環境で独占的に働いてきました。 実際、高度なコマンドライン機能を使用して独自の変更を追跡および元に戻すことで、Gitをこのように使用することでメリットを得ることができます。 ただし、Githubなどのプラットフォームで人気のあるコラボレーション機能を利用するには、変更をリモートサーバーにプッシュする必要があります。

コードをリモートサーバーにプッシュできるようにするための最初のステップは、リポジトリが存在するURLを提供し、それにローカル名を付けることです。 リモートリポジトリを構成し、すべてのリモートのリストを表示するには（複数持つことができます）、 git remote 指図：

  1. git remote add origin ssh://[email protected]/repository.git 

  2. git remote -v



Output
origin	ssh://[email protected]/repository.git (fetch)
origin	ssh://[email protected]/repository.git (push)

最初のコマンドは、「origin」と呼ばれるリモートを追加し、URLをssh：// git @git .domain.tld/repository.gitに設定します。

リモコンには好きな名前を付けることができます。 origin は、コードの信頼できるアップストリームコピーが存在する場所の一般的な規則です。 URLは、実際のリモートリポジトリを指している必要があります。 たとえば、コードをGitHubにプッシュする場合は、GitHubが提供するリポジトリURLを使用する必要があります。

リモートを構成すると、コードをプッシュできるようになります。 次のように入力して、コードをリモートサーバーにプッシュできます。

  1. git push origin main

注： 2021年より前は、Gitリポジトリに作成された最初のブランチの名前は master デフォルトでは。 それ以来、デフォルトのブランチ名を次のように変更する動きがありました。 main より中立的な用語を使用するために。 Github などの多くのGitホスティングプロバイダーがこの変更を行いましたが、Gitのローカルコピーはデフォルトでデフォルトになっている可能性があります master. と呼ばれる存在しないブランチに関するエラーメッセージを受け取った場合 main、押してみてください master 代わりに今のところ。

Output
Counting objects: 4, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 266 bytes, done.
Total 3 (delta 1), reused 1 (delta 0)
To ssh://[email protected]/repository.git
   0e78fdf..e6a8ddc  main -> main

将来、プッシュするコミットが増えると、デフォルトで入力することができます git push、最後のプッシュからブランチ名とリモート名の両方を継承します。

結論

このチュートリアルでは、開始Gitリポジトリを作成してプッシュしました。 コードをコミットしてGitHubなどのリポジトリにプッシュした後、Webインターフェイスでの共同作業により多くの時間を費やすことを選択できますが、コマンドラインでローカルマシンから作業できることが常に重要です。 複数のコミッターがいるプロジェクトを維持または貢献するには、より複雑なGitコマンドが必要になりますが、このチュートリアルで説明したことは、個人的なプロジェクトで作業するのに十分です。

次に、 Gitブランチの使用、またはGithubでプルリクエストを行う方法について学習することをお勧めします。 Gitリファレンスガイドも参照できます。