Git-クイックガイド

バージョン管理システム

Version Control System (VCS) は、ソフトウェア開発者が協力して作業の完全な履歴を維持するのに役立つソフトウェアです。

以下にVCSの機能を示します-

開発者が同時に作業できるようにします。
互いの変更を上書きすることはできません。
すべてのバージョンの履歴を維持します。

以下はVCSの種類です-

一元化されたバージョン管理システム（CVCS）。
分散/分散バージョン管理システム（DVCS）。

この章では、分散バージョン管理システム、特にGitにのみ焦点を当てます。Gitは分散バージョン管理システムに分類されます。

分散バージョン管理システム

一元化されたバージョン管理システム（CVCS）は、中央サーバーを使用してすべてのファイルを保存し、チームのコラボレーションを可能にします。ただし、CVCSの主な欠点は、単一障害点、つまり中央サーバーの障害です。残念ながら、中央サーバーが1時間ダウンした場合、その時間中は誰も共同作業を行うことができません。また、最悪の場合でも、中央サーバーのディスクが破損し、適切なバックアップが作成されていないと、プロジェクトの履歴全体が失われます。ここでは、分散バージョン管理システム（DVCS）が登場します。

DVCSクライアントは、ディレクトリの最新のスナップショットをチェックアウトするだけでなく、リポジトリを完全にミラーリングします。サーバーがダウンした場合、任意のクライアントのリポジトリをサーバーにコピーして復元できます。すべてのチェックアウトは、リポジトリの完全バックアップです。Gitは中央サーバーに依存していないため、オフラインのときに多くの操作を実行できます。オフラインのときに、変更をコミットしたり、ブランチを作成したり、ログを表示したり、その他の操作を実行したりできます。ネットワーク接続が必要なのは、変更を公開して最新の変更を取得する場合のみです。

Gitの利点

無料でオープンソース

GitはGPLのオープンソースライセンスの下でリリースされています。インターネット経由で無料で入手できます。Gitを使用すると、1ペニーを支払うことなく不動産プロジェクトを管理できます。オープンソースであるため、ソースコードをダウンロードしたり、要件に応じて変更を加えたりすることができます。

速くて小さい

ほとんどの操作はローカルで実行されるため、速度の点で大きなメリットがあります。Gitは中央サーバーに依存していません。そのため、操作のたびにリモートサーバーと対話する必要はありません。Gitのコア部分はCで記述されており、他の高級言語に関連する実行時のオーバーヘッドを回避します。Gitはリポジトリ全体をミラーリングしますが、クライアント側のデータのサイズは小さいです。これは、クライアント側でデータを圧縮および保存する際のGitの効率を示しています。

暗黙的なバックアップ

データのコピーが複数ある場合、データが失われる可能性は非常にまれです。クライアント側に存在するデータはリポジトリをミラーリングするため、クラッシュやディスクの破損が発生した場合に使用できます。

セキュリティ

Gitは、セキュアハッシュ関数（SHA1）と呼ばれる一般的な暗号化ハッシュ関数を使用して、データベース内のオブジェクトに名前を付けて識別します。すべてのファイルとコミットはチェックサムされ、チェックアウト時にチェックサムによって取得されます。これは、Gitを知らずに、Gitデータベースからファイル、日付、コミットメッセージおよびその他のデータを変更することは不可能であることを意味します。

強力なハードウェアは必要ありません

CVCSの場合、中央サーバーはチーム全体の要求を処理するのに十分強力である必要があります。小規模なチームの場合、これは問題ではありませんが、チームのサイズが大きくなると、サーバーのハードウェアの制限がパフォーマンスのボトルネックになる可能性があります。DVCSの場合、開発者は、変更をプッシュまたはプルする必要がない限り、サーバーと対話しません。すべての手間のかかる作業はクライアント側で行われるため、サーバーハードウェアは非常にシンプルになります。

より簡単な分岐

CVCSは安価なコピーメカニズムを使用しています。新しいブランチを作成すると、すべてのコードが新しいブランチにコピーされるため、時間がかかり、効率的ではありません。また、CVCSでのブランチの削除とマージは、複雑で時間がかかります。しかし、Gitを使用したブランチ管理は非常に簡単です。ブランチの作成、削除、マージには数秒しかかかりません。

DVCSの用語

ローカルリポジトリ

すべてのVCSツールは、作業コピーとしてプライベートワークプレイスを提供します。開発者はプライベートワークプレイスに変更を加え、コミット後、これらの変更はリポジトリの一部になります。Gitは、リポジトリ全体のプライベートコピーを提供することで、さらに一歩進んでいます。ユーザーは、ファイルの追加、ファイルの削除、ファイルの名前変更、ファイルの移動、変更のコミットなど、このリポジトリを使用して多くの操作を実行できます。

作業ディレクトリとステージング領域またはインデックス

作業ディレクトリは、ファイルがチェックアウトされる場所です。他のCVCSでは、開発者は通常、変更を加え、変更をリポジトリに直接コミットします。しかし、Gitは別の戦略を使用しています。Gitは、変更されたすべてのファイルを追跡するわけではありません。操作をコミットするたびに、Gitはステージング領域に存在するファイルを探します。ステージング領域に存在するファイルのみがコミットの対象と見なされ、すべての変更されたファイルは考慮されません。

Gitの基本的なワークフローを見てみましょう。

Step 1 −作業ディレクトリからファイルを変更します。

Step 2 −これらのファイルをステージング領域に追加します。

Step 3−ステージング領域からファイルを移動するコミット操作を実行します。プッシュ操作後、変更をGitリポジトリに永続的に保存します。

「sort.c」と「search.c」という2つのファイルを変更し、操作ごとに2つの異なるコミットが必要だとします。ステージング領域に1つのファイルを追加して、コミットすることができます。最初のコミットの後、別のファイルに対して同じ手順を繰り返します。

# First commit
[bash]$ git add sort.c # adds file to the staging area [bash]$ git commit –m “Added sort operation”

# Second commit
[bash]$ git add search.c # adds file to the staging area [bash]$ git commit –m “Added search operation”

ブロブ

Blobは Binary Large Obジェクト。ファイルの各バージョンはblobで表されます。BLOBはファイルデータを保持しますが、ファイルに関するメタデータは含まれていません。これはバイナリファイルであり、Gitデータベースでは、そのファイルのSHA1ハッシュとして名前が付けられています。Gitでは、ファイルは名前でアドレス指定されません。すべてがコンテンツアドレスです。

木

ツリーは、ディレクトリを表すオブジェクトです。ブロブと他のサブディレクトリを保持します。ツリーは、次の名前も付けられたblobとツリーへの参照を格納するバイナリファイルです。SHA1 ツリーオブジェクトのハッシュ。

コミット

Commitは、リポジトリの現在の状態を保持します。コミットの名前もSHA1ハッシュ。コミットオブジェクトは、リンクリストのノードと見なすことができます。すべてのコミットオブジェクトには、親コミットオブジェクトへのポインタがあります。特定のコミットから、親ポインターを見てコミットの履歴を表示することにより、さかのぼることができます。コミットに複数の親コミットがある場合、その特定のコミットは2つのブランチをマージすることによって作成されています。

ブランチ

ブランチは、別の開発ラインを作成するために使用されます。デフォルトでは、Gitにはマスターブランチがあります。これはSubversionのトランクと同じです。通常、ブランチは新しい機能に取り組むために作成されます。機能が完了すると、マスターブランチにマージされ、ブランチが削除されます。すべてのブランチは、ブランチ内の最新のコミットを指すHEADによって参照されます。コミットを行うたびに、HEADは最新のコミットで更新されます。

タグは、リポジトリ内の特定のバージョンに意味のある名前を割り当てます。タグはブランチに非常に似ていますが、違いはタグが不変であるということです。つまり、タグはブランチであり、誰も変更するつもりはありません。特定のコミット用にタグが作成されると、新しいコミットを作成しても、タグは更新されません。通常、開発者は製品リリースのタグを作成します。

クローン

クローン操作により、リポジトリのインスタンスが作成されます。クローン操作は、作業コピーをチェックアウトするだけでなく、リポジトリ全体をミラーリングします。ユーザーは、このローカルリポジトリを使用して多くの操作を実行できます。ネットワークが関与するのは、リポジトリインスタンスが同期されているときだけです。

引く

プル操作は、変更をリモートリポジトリインスタンスからローカルインスタンスにコピーします。プル操作は、2つのリポジトリインスタンス間の同期に使用されます。これは、Subversionの更新操作と同じです。

押す

プッシュ操作は、変更をローカルリポジトリインスタンスからリモートインスタンスにコピーします。これは、変更をGitリポジトリに永続的に保存するために使用されます。これは、Subversionのcommit操作と同じです。

頭

HEADはポインターであり、常にブランチ内の最新のコミットを指します。コミットを行うたびに、HEADは最新のコミットで更新されます。枝の頭はに保存されます.git/refs/heads/ ディレクトリ。

[CentOS]$ ls -1 .git/refs/heads/ master [CentOS]$ cat .git/refs/heads/master
570837e7d58fa4bccd86cb575d884502188b0c49

リビジョン

リビジョンは、ソースコードのバージョンを表します。Gitのリビジョンは、コミットによって表されます。これらのコミットは、SHA1 安全なハッシュ。

URL

URLはGitリポジトリの場所を表します。GitURLは設定ファイルに保存されます。

[tom@CentOS tom_repo]$ pwd /home/tom/tom_repo [tom@CentOS tom_repo]$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = [email protected]:project.git
fetch = +refs/heads/*:refs/remotes/origin/*

Gitを使用する前に、いくつかの基本的な構成変更をインストールして実行する必要があります。以下は、UbuntuおよびCentosLinuxにGitクライアントをインストールする手順です。

Gitクライアントのインストール

DebianベースのGNU / Linuxディストリビューションを使用している場合は、 apt-get コマンドは必要なことをします。

[ubuntu ~]$ sudo apt-get install git-core [sudo] password for ubuntu: [ubuntu ~]$ git --version
git version 1.8.1.2

また、RPMベースのGNU / Linuxディストリビューションを使用している場合は、 yum 与えられたコマンド。

[CentOS ~]$
su -
Password:

[CentOS ~]# yum -y install git-core

[CentOS ~]# git --version
git version 1.7.1

Git環境をカスタマイズする

Gitは、構成変数を設定できるgit構成ツールを提供します。Gitはすべてのグローバル構成をに保存します.gitconfigファイル。ホームディレクトリにあります。これらの構成値をグローバルとして設定するには、--global オプション、および省略した場合 --global オプションの場合、構成は現在のGitリポジトリに固有です。

システム全体の構成をセットアップすることもできます。Gitはこれらの値をに保存します/etc/gitconfigファイル。システム上のすべてのユーザーとリポジトリの構成が含まれています。これらの値を設定するには、ルート権限があり、--system オプション。

上記のコードをコンパイルして実行すると、次の結果が得られます。

ユーザー名の設定

この情報は、コミットごとにGitによって使用されます。

[jerry@CentOS project]$ git config --global user.name "Jerry Mouse"

メールIDの設定

この情報は、コミットごとにGitによって使用されます。

[jerry@CentOS project]$ git config --global user.email "[email protected]"

プルのためのマージコミットを避ける

リモートリポジトリから最新の変更をプルします。これらの変更が異なる場合、デフォルトでGitはマージコミットを作成します。以下の設定でこれを回避できます。

jerry@CentOS project]$ git config --global branch.autosetuprebase always

色の強調表示

次のコマンドは、コンソールでGitの色の強調表示を有効にします。

[jerry@CentOS project]$ git config --global color.ui true [jerry@CentOS project]$ git config --global color.status auto

[jerry@CentOS project]$ git config --global color.branch auto

デフォルトのエディタを設定する

デフォルトでは、Gitはシステムのデフォルトエディターを使用します。これは、VISUALまたはEDITOR環境変数から取得されます。gitconfigを使用して別のものを構成できます。

[jerry@CentOS project]$ git config --global core.editor vim

デフォルトのマージツールの設定

Gitは、競合する変更を作業ツリーに統合するためのデフォルトのマージツールを提供していません。以下の設定を有効にすることで、デフォルトのマージツールを設定できます。

[jerry@CentOS project]$ git config --global merge.tool vimdiff

Git設定の一覧表示

ローカルリポジトリのGit設定を確認するには、 git config –list 以下のコマンド。

[jerry@CentOS ~]$ git config --list

上記のコマンドは次の結果を生成します。

user.name=Jerry Mouse
[email protected]
push.default=nothing
branch.autosetuprebase=always
color.ui=true
color.status=auto
color.branch=auto
core.editor=vim
merge.tool=vimdiff

この章では、Gitのライフサイクルについて説明します。後の章では、各操作のGitコマンドについて説明します。

一般的なワークフローは次のとおりです-

Gitリポジトリを作業コピーとして複製します。
ファイルを追加/編集することにより、作業コピーを変更します。
必要に応じて、他の開発者の変更を加えて作業コピーも更新します。
コミットする前に変更を確認します。
変更をコミットします。すべて問題がなければ、変更をリポジトリにプッシュします。
コミットした後、何かがおかしいことに気付いた場合は、最後のコミットを修正して、変更をリポジトリにプッシュします。

以下に示すのは、ワークフローの図解です。

この章では、リモートGitリポジトリを作成する方法を説明します。これ以降、これをGitサーバーと呼びます。チームのコラボレーションを可能にするには、Gitサーバーが必要です。

新しいユーザーを作成する

# add new group
[root@CentOS ~]# groupadd dev

# add new user
[root@CentOS ~]# useradd -G devs -d /home/gituser -m -s /bin/bash gituser

# change password
[root@CentOS ~]# passwd gituser

上記のコマンドは次の結果を生成します。

Changing password for user gituser.
New password:
Retype new password:
passwd: all authentication token updated successfully.

ベアリポジトリを作成する

を使用して新しいリポジトリを初期化しましょう init コマンドに続いて --bareオプション。作業ディレクトリなしでリポジトリを初期化します。慣例により、ベアリポジトリには次の名前を付ける必要があります.git。

[gituser@CentOS ~]$ pwd /home/gituser [gituser@CentOS ~]$ mkdir project.git

[gituser@CentOS ~]$ cd project.git/ [gituser@CentOS project.git]$ ls

[gituser@CentOS project.git]$ git --bare init Initialized empty Git repository in /home/gituser-m/project.git/ [gituser@CentOS project.git]$ ls
branches config description HEAD hooks info objects refs

公開/秘密RSAキーペアを生成する

Gitサーバーを構成するプロセスを見ていきましょう。 ssh-keygen ユーティリティは、ユーザー認証に使用する公開/秘密RSAキーペアを生成します。

ターミナルを開き、次のコマンドを入力して、入力ごとにEnterキーを押します。正常に完了すると、.ssh ホームディレクトリ内のディレクトリ。

tom@CentOS ~]$ pwd /home/tom [tom@CentOS ~]$ ssh-keygen

上記のコマンドは次の結果を生成します。

Generating public/private rsa key pair.
Enter file in which to save the key (/home/tom/.ssh/id_rsa): Press Enter Only
Created directory '/home/tom/.ssh'.
Enter passphrase (empty for no passphrase): ---------------> Press Enter Only
Enter same passphrase again: ------------------------------> Press Enter Only
Your identification has been saved in /home/tom/.ssh/id_rsa.
Your public key has been saved in /home/tom/.ssh/id_rsa.pub.
The key fingerprint is:
df:93:8c:a1:b8:b7:67:69:3a:1f:65:e8:0e:e9:25:a1 tom@CentOS
The key's randomart image is:
+--[ RSA 2048]----+
| |
| |
| |
|
.
|
| Soo |
| o*B. |
| E = *.= |
| oo==. . |
| ..+Oo
|
+-----------------+

ssh-keygen は2つの鍵を生成しました。最初の鍵は秘密（つまりid_rsa）で、2番目の鍵は公開（つまりid_rsa.pub）です。

Note: 秘密鍵を他の人と共有しないでください。

authorized_keysへのキーの追加

プロジェクトに取り組んでいる2人の開発者、つまりトムとジェリーがいるとします。両方のユーザーが公開鍵を生成しました。これらのキーを認証に使用する方法を見てみましょう。

トムは、を使用して公開鍵をサーバーに追加しました ssh-copy-id 以下に示すコマンド-

[tom@CentOS ~]$ pwd /home/tom [tom@CentOS ~]$ ssh-copy-id -i ~/.ssh/id_rsa.pub [email protected]

上記のコマンドは次の結果を生成します。

[email protected]'s password:
Now try logging into the machine, with "ssh '[email protected]'", and check in:
.ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.

同様に、ジェリーはssh-copy-idコマンドを使用してサーバーに公開鍵を追加しました。

[jerry@CentOS ~]$ pwd /home/jerry [jerry@CentOS ~]$ ssh-copy-id -i ~/.ssh/id_rsa [email protected]

上記のコマンドは次の結果を生成します。

[email protected]'s password:
Now try logging into the machine, with "ssh '[email protected]'", and check in:
.ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.

変更をリポジトリにプッシュする

サーバー上にベアリポジトリを作成し、2人のユーザーにアクセスを許可しました。今後、トムとジェリーは、リポジトリをリモートとして追加することで、変更をリポジトリにプッシュできます。

Gitinitコマンドは .git リポジトリから構成を読み取るたびにリポジトリに関するメタデータを格納するディレクトリ .git/config ファイル。

トムは新しいディレクトリを作成し、READMEファイルを追加して、最初のコミットとして変更をコミットします。コミット後、彼はを実行してコミットメッセージを確認しますgit log コマンド。

[tom@CentOS ~]$ pwd /home/tom [tom@CentOS ~]$ mkdir tom_repo

[tom@CentOS ~]$ cd tom_repo/ [tom@CentOS tom_repo]$ git init
Initialized empty Git repository in /home/tom/tom_repo/.git/

[tom@CentOS tom_repo]$ echo 'TODO: Add contents for README' > README [tom@CentOS tom_repo]$ git status -s
?? README

[tom@CentOS tom_repo]$ git add . [tom@CentOS tom_repo]$ git status -s
A README

[tom@CentOS tom_repo]$ git commit -m 'Initial commit'

上記のコマンドは次の結果を生成します。

[master (root-commit) 19ae206] Initial commit
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 README

トムはgitlogコマンドを実行してログメッセージを確認します。

[tom@CentOS tom_repo]$ git log

上記のコマンドは次の結果を生成します。

commit 19ae20683fc460db7d127cf201a1429523b0e319
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 07:32:56 2013 +0530

Initial commit

トムは自分の変更をローカルリポジトリにコミットしました。次に、変更をリモートリポジトリにプッシュします。ただし、その前に、リポジトリをリモートとして追加する必要があります。これは1回限りの操作です。この後、彼は変更をリモートリポジトリに安全にプッシュできます。

Note−デフォルトでは、Gitは一致するブランチにのみプッシュします。ローカル側に存在するすべてのブランチについて、同じ名前のブランチがすでに存在する場合、リモート側が更新されます。チュートリアルでは、変更をプッシュするたびにorigin master ブランチ、要件に応じて適切なブランチ名を使用します。

[tom@CentOS tom_repo]$ git remote add origin [email protected]:project.git [tom@CentOS tom_repo]$ git push origin master

上記のコマンドは次の結果を生成します。

Counting objects: 3, done.
Writing objects: 100% (3/3), 242 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To [email protected]:project.git
* [new branch]
master −> master

これで、変更がリモートリポジトリに正常にコミットされました。

Gitサーバーにベアリポジトリがあり、トムも最初のバージョンをプッシュしました。これで、ジェリーは自分の変更を表示できます。クローン操作は、リモートリポジトリのインスタンスを作成します。

ジェリーはホームディレクトリに新しいディレクトリを作成し、クローン操作を実行します。

[jerry@CentOS ~]$ mkdir jerry_repo [jerry@CentOS ~]$ cd jerry_repo/

[jerry@CentOS jerry_repo]$ git clone [email protected]:project.git

上記のコマンドは次の結果を生成します。

Initialized empty Git repository in /home/jerry/jerry_repo/project/.git/
remote: Counting objects: 3, done.
Receiving objects: 100% (3/3), 241 bytes, done.
remote: Total 3 (delta 0), reused 0 (delta 0)

Jerryは、ディレクトリを新しいローカルリポジトリに変更し、そのディレクトリの内容を一覧表示します。

[jerry@CentOS jerry_repo]$ cd project/

[jerry@CentOS jerry_repo]$ ls
README

Jerryはリポジトリのクローンを作成し、基本的な文字列操作を実装することにしました。そこで彼はstring.cファイルを作成します。内容を追加すると、string.cは次のようになります-

#include <stdio.h>

int my_strlen(char *s)
{
   char *p = s;

   while (*p)
      ++p;

   return (p - s);
}

int main(void)
{
   int i;
   char *s[] = 
   {
      "Git tutorials",
      "Tutorials Point"
   };

   for (i = 0; i < 2; ++i)
      
   printf("string lenght of %s = %d\n", s[i], my_strlen(s[i]));

   return 0;
}

彼は自分のコードをコンパイルしてテストし、すべてが正常に機能しています。これで、これらの変更をリポジトリに安全に追加できます。

Git追加操作は、ステージング領域にファイルを追加します。

[jerry@CentOS project]$ git status -s
?? string
?? string.c

[jerry@CentOS project]$ git add string.c

Gitはファイル名の前に疑問符を表示しています。明らかに、これらのファイルはGitの一部ではないため、Gitはこれらのファイルをどう処理するかを知りません。そのため、Gitはファイル名の前に疑問符を表示しています。

ジェリーはファイルをスタッシュエリアに追加しました。gitstatusコマンドはステージングエリアに存在するファイルを表示します。

[jerry@CentOS project]$ git status -s
A string.c
?? string

変更をコミットするために、彼はgitcommitコマンドに続いて-mオプションを使用しました。–mオプションを省略した場合。Gitは、複数行のコミットメッセージを書き込むことができるテキストエディターを開きます。

[jerry@CentOS project]$ git commit -m 'Implemented my_strlen function'

上記のコマンドは次の結果を生成します-

[master cbe1249] Implemented my_strlen function
1 files changed, 24 insertions(+), 0 deletions(-)
create mode 100644 string.c

ログの詳細を表示するためにコミットした後、彼はgitlogコマンドを実行します。すべてのコミットの情報が、コミットID、コミット作成者、コミット日、およびSHA-1 コミットのハッシュ。

[jerry@CentOS project]$ git log

上記のコマンドは次の結果を生成します-

commit cbe1249b140dad24b2c35b15cc7e26a6f02d2277
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 08:05:26 2013 +0530

Implemented my_strlen function


commit 19ae20683fc460db7d127cf201a1429523b0e319
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 07:32:56 2013 +0530

Initial commit

コミットの詳細を表示した後、ジェリーは文字列の長さを負にすることはできないことに気付きました。そのため、my_strlen関数の戻り値の型を変更することにしました。

ジェリーは git log ログの詳細を表示するコマンド。

[jerry@CentOS project]$ git log

上記のコマンドは次の結果を生成します。

commit cbe1249b140dad24b2c35b15cc7e26a6f02d2277
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 08:05:26 2013 +0530

Implemented my_strlen function

ジェリーは git showコミットの詳細を表示するコマンド。gitshowコマンドはSHA-1 パラメータとしてのコミットID。

[jerry@CentOS project]$ git show cbe1249b140dad24b2c35b15cc7e26a6f02d2277

上記のコマンドは次の結果を生成します-

commit cbe1249b140dad24b2c35b15cc7e26a6f02d2277
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 08:05:26 2013 +0530

Implemented my_strlen function


diff --git a/string.c b/string.c
new file mode 100644
index 0000000..187afb9
--- /dev/null
+++ b/string.c
@@ -0,0 +1,24 @@
+#include <stdio.h>
+
+int my_strlen(char *s)
+{
   +
   char *p = s;
   +
   +
   while (*p)
   + ++p;
   + return (p -s );
   +
}
+

彼は関数の戻り値の型をintからsize_tに変更します。コードをテストした後、彼はを実行して変更を確認しますgit diff コマンド。

[jerry@CentOS project]$ git diff

上記のコマンドは次の結果を生成します-

diff --git a/string.c b/string.c
index 187afb9..7da2992 100644
--- a/string.c
+++ b/string.c
@@ -1,6 +1,6 @@
#include <stdio.h>

-int my_strlen(char *s)
+size_t my_strlen(char *s)
{
   char *p = s;
   @@ -18,7 +18,7 @@ int main(void)
};
for (i = 0; i < 2; ++i)
{
   - printf("string lenght of %s = %d\n", s[i], my_strlen(s[i]));
   + printf("string lenght of %s = %lu\n", s[i], my_strlen(s[i]));
   return 0;
}

Gitの差分ショー '+' 新しく追加された行の前に署名し、 '−' 削除された行の場合。

ジェリーはすでに変更をコミットしており、最後のコミットを修正したいと考えています。この場合、git amend操作が役立ちます。修正操作は、コミットメッセージを含む最後のコミットを変更します。新しいコミットIDを作成します。

操作を修正する前に、彼はコミットログをチェックします。

[jerry@CentOS project]$ git log

上記のコマンドは次の結果を生成します。

commit cbe1249b140dad24b2c35b15cc7e26a6f02d2277
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 08:05:26 2013 +0530

Implemented my_strlen function


commit 19ae20683fc460db7d127cf201a1429523b0e319
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 07:32:56 2013 +0530

Initial commit

Jerryは--amend操作を使用して新しい変更をコミットし、コミットログを表示します。

[jerry@CentOS project]$ git status -s M string.c ?? string [jerry@CentOS project]$ git add string.c

[jerry@CentOS project]$ git status -s M string.c ?? string [jerry@CentOS project]$ git commit --amend -m 'Changed return type of my_strlen to size_t'
[master d1e19d3] Changed return type of my_strlen to size_t
1 files changed, 24 insertions(+), 0 deletions(-)
create mode 100644 string.c

これで、gitログに新しいコミットIDの新しいコミットメッセージが表示されます-

[jerry@CentOS project]$ git log

上記のコマンドは次の結果を生成します。

commit d1e19d316224cddc437e3ed34ec3c931ad803958
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 08:05:26 2013 +0530

Changed return type of my_strlen to size_t


commit 19ae20683fc460db7d127cf201a1429523b0e319
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 07:32:56 2013 +0530

Initial commit

ジェリーは、修正操作を使用して最後のコミットを変更し、変更をプッシュする準備ができました。プッシュ操作は、データをGitリポジトリに永続的に保存します。プッシュ操作が成功すると、他の開発者はJerryの変更を確認できます。

彼はgitlogコマンドを実行して、コミットの詳細を表示します。

[jerry@CentOS project]$ git log

上記のコマンドは、次の結果を生成します。

commit d1e19d316224cddc437e3ed34ec3c931ad803958
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 08:05:26 2013 +0530

Changed return type of my_strlen to size_t

プッシュ操作の前に、彼は自分の変更を確認したいので、 git show 彼の変更を確認するコマンド。

[jerry@CentOS project]$ git show d1e19d316224cddc437e3ed34ec3c931ad803958

上記のコマンドは、次の結果を生成します。

commit d1e19d316224cddc437e3ed34ec3c931ad803958
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 08:05:26 2013 +0530

Changed return type of my_strlen to size_t

diff --git a/string.c b/string.c
new file mode 100644
index 0000000..7da2992
--- /dev/null
+++ b/string.c
@@ -0,0 +1,24 @@
+#include <stdio.h>
+
+size_t my_strlen(char *s)
+
{
   +
   char *p = s;
   +
   +
   while (*p)
   + ++p;
   + return (p -s );
   +
}
+
+int main(void)
+
{
   + int i;
   + char *s[] = 
   {
      + "Git tutorials",
      + "Tutorials Point"
      +
   };
   +
   +
   +
   for (i = 0; i < 2; ++i)
   printf("string lenght of %s = %lu\n", s[i], my_strlen(s[i]));
   +
   +
   return 0;
   +
}

ジェリーは彼の変更に満足しており、彼は彼の変更をプッシュする準備ができています。

[jerry@CentOS project]$ git push origin master

上記のコマンドは、次の結果を生成します。

Counting objects: 4, done.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 517 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To [email protected]:project.git
19ae206..d1e19d3 master −> master

Jerryの変更はリポジトリに正常にプッシュされました。現在、他の開発者は、クローンまたは更新操作を実行することにより、彼の変更を表示できます。

既存の機能を変更する

トムはクローン操作を実行し、新しいファイルstring.cを見つけます。彼は、誰がこのファイルをリポジトリに追加したのか、どのような目的で追加したのかを知りたいので、git log コマンド。

[tom@CentOS ~]$ git clone [email protected]:project.git

上記のコマンドは次の結果を生成します-

Initialized empty Git repository in /home/tom/project/.git/
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (4/4), done.
Receiving objects: 100% (6/6), 726 bytes, done.
remote: Total 6 (delta 0), reused 0 (delta 0)

クローン操作は、現在の作業ディレクトリ内に新しいディレクトリを作成します。彼はディレクトリを新しく作成されたディレクトリに変更し、git log コマンド。

[tom@CentOS ~]$ cd project/

[tom@CentOS project]$ git log

上記のコマンドは次の結果を生成します-

commit d1e19d316224cddc437e3ed34ec3c931ad803958
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 08:05:26 2013 +0530

Changed return type of my_strlen to size_t


commit 19ae20683fc460db7d127cf201a1429523b0e319
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 07:32:56 2013 +0530

Initial commit

ログを観察した後、彼はファイルstring.cが基本的な文字列操作を実装するためにJerryによって追加されたことに気付きました。彼はジェリーのコードに興味があります。そこで彼はテキストエディタでstring.cを開き、すぐにバグを見つけました。my_strlen関数では、Jerryは定数ポインターを使用していません。そこで、彼はジェリーのコードを変更することにしました。変更後のコードは次のようになります-

[tom@CentOS project]$ git diff

上記のコマンドは次の結果を生成します-

diff --git a/string.c b/string.c
index 7da2992..32489eb 100644
--- a/string.c
+++ b/string.c
@@ -1,8 +1,8 @@
#include <stdio.h>
-size_t my_strlen(char *s)
+size_t my_strlen(const char *s)
{
   - char *p = s;
   + const char *p = s;
   while (*p)
   ++p;
}

テスト後、彼は変更をコミットします。

[tom@CentOS project]$ git status -s M string.c ?? string [tom@CentOS project]$ git add string.c

[tom@CentOS project]$ git commit -m 'Changed char pointer to const char pointer' [master cea2c00] Changed char pointer to const char pointer 1 files changed, 2 insertions(+), 2 deletions(-) [tom@CentOS project]$ git log

上記のコマンドは次の結果を生成します-

commit cea2c000f53ba99508c5959e3e12fff493b
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 08:32:07 2013 +0530

Changed char pointer to const char pointer


commit d1e19d316224cddc437e3ed34ec3c931ad803958
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 08:05:26 2013 +0530

Changed return type of my_strlen to size_t


commit 19ae20683fc460db7d127cf201a1429523b0e319
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 07:32:56 2013 +0530
Initial commit

トムはgitpushコマンドを使用して変更をプッシュします。

[tom@CentOS project]$ git push origin master

上記のコマンドは次の結果を生成します-

Counting objects: 5, done.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 336 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
To [email protected]:project.git
d1e19d3..cea2c00 master −> master

新しい機能の追加

その間、ジェリーは実装することを決定します string compare機能。そこで彼はstring.cを変更します。変更後、ファイルは次のようになります-

[jerry@CentOS project]$ git diff

上記のコマンドは次の結果を生成します-

index 7da2992..bc864ed 100644
--- a/string.c
+++ b/string.c
30Git Tutorials
@@ -9,9 +9,20 @@ size_t my_strlen(char *s)
return (p -s );
}
+char *my_strcpy(char *t, char *s)
+
{
   +
   char *p = t;
   +
   + while (*t++ = *s++)
   + ;
   +
   +
   return p;
   +
}
+
int main(void)
{
   int i; 
   +
   char p1[32];
   char *s[] = 
   {
      "Git tutorials",
      "Tutorials Point"
      @@ -20,5 +31,7 @@ int main(void)
      for (i = 0; i < 2; ++i)
      printf("string lenght of %s = %lu\n", s[i], my_strlen(s[i]));
      +
      printf("%s\n", my_strcpy(p1, "Hello, World !!!"));
      +
      return 0;
   }
}

テスト後、彼は自分の変更をプッシュする準備ができています。

[jerry@CentOS project]$ git status -s M string.c ?? string [jerry@CentOS project]$ git add string.c

[jerry@CentOS project]$ git commit -m "Added my_strcpy function"
[master e944e5a] Added my_strcpy function
1 files changed, 13 insertions(+), 0 deletions(-)

プッシュ操作の前に、彼はログメッセージを表示してコミットを確認します。

[jerry@CentOS project]$ git log

上記のコマンドは次の結果を生成します-

commit e944e5aab74b26e7447d3281b225309e4e59efcd
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 08:41:42 2013 +0530

Added my_strcpy function


commit d1e19d316224cddc437e3ed34ec3c931ad803958
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 08:05:26 2013 +0530

Changed return type of my_strlen to size_t


commit 19ae20683fc460db7d127cf201a1429523b0e319
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 07:32:56 2013 +0530

Initial commit

ジェリーは変更に満足しており、変更をプッシュしたいと考えています。

[jerry@CentOS project]$ git push origin master

上記のコマンドは次の結果を生成します-

To [email protected]:project.git
! [rejected]
master −> master (non-fast-forward)
error: failed to push some refs to '[email protected]:project.git'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes before pushing again. See the 'Note about
fast-forwards' section of 'git push --help' for details.

しかし、Gitはジェリーが彼の変更をプッシュすることを許可していません。Gitは、リモートリポジトリとJerryのローカルリポジトリが同期していないことを識別したためです。このため、彼はプロジェクトの履歴を失う可能性があります。この混乱を避けるために、Gitはこの操作に失敗しました。現在、ジェリーは最初にローカルリポジトリを更新する必要があり、その後でのみ、自分の変更をプッシュできます。

コミットされていない変更を元に戻す

ジェリーが誤ってローカルリポジトリのファイルを変更したとしましょう。しかし、彼は自分の変更を元に戻したいと思っています。この状況に対処するために、git checkoutコマンド。このコマンドを使用して、ファイルの内容を元に戻すことができます。

[jerry@CentOS src]$ pwd
/home/jerry/jerry_repo/project/src

[jerry@CentOS src]$ git status -s M string_operations.c [jerry@CentOS src]$ git checkout string_operations.c

[jerry@CentOS src]$ git status –s

さらに、 git checkoutローカルリポジトリから削除されたファイルを取得するコマンド。トムがローカルリポジトリからファイルを削除し、このファイルを元に戻したいとしましょう。同じコマンドを使用してこれを実現できます。

[tom@CentOS src]$ pwd
/home/tom/top_repo/project/src

[tom@CentOS src]$ ls -1 Makefile string_operations.c [tom@CentOS src]$ rm string_operations.c

[tom@CentOS src]$ ls -1 Makefile [tom@CentOS src]$ git status -s
D string_operations.c

Gitは手紙を見せています Dファイル名の前。これは、ファイルがローカルリポジトリから削除されたことを示します。

[tom@CentOS src]$ git checkout string_operations.c [tom@CentOS src]$ ls -1
Makefile
string_operations.c

[tom@CentOS src]$ git status -s

Note −コミットする前にこれらすべての操作を実行できます。

ステージング領域から変更を削除する

追加操作を実行すると、ファイルがローカルリポジトリから表示領域に移動することを確認しました。ユーザーが誤ってファイルを変更してステージング領域に追加した場合、ユーザーはを使用して変更を元に戻すことができます。git checkout コマンド。

Gitには、常に最新のコミットを指すHEADポインターが1つあります。ステージングされた領域からの変更を元に戻したい場合は、git checkoutコマンドを使用できますが、checkoutコマンドでは、追加のパラメーター、つまりHEADポインターを指定する必要があります。追加のコミットポインターパラメーターは、git checkoutコマンドに、作業ツリーをリセットし、段階的な変更を削除するように指示します。

トムがローカルリポジトリからファイルを変更するとします。このファイルのステータスを表示すると、ファイルが変更されたが、ステージング領域に追加されていないことが示されます。

tom@CentOS src]$ pwd
/home/tom/top_repo/project/src
# Unmodified file

[tom@CentOS src]$ git status -s # Modify file and view it’s status. [tom@CentOS src]$ git status -s
M string_operations.c

[tom@CentOS src]$ git add string_operations.c

Gitステータスは、ファイルがステージング領域に存在することを示します。ここで、git checkoutコマンドを使用してファイルを元に戻し、元に戻されたファイルのステータスを表示します。

[tom@CentOS src]$ git checkout HEAD -- string_operations.c

[tom@CentOS src]$ git status -s

GitリセットでHEADポインターを移動する

いくつかの変更を行った後、これらの変更を削除することを決定できます。Git resetコマンドは、変更をリセットまたは元に戻すために使用されます。3種類のリセット操作が可能です。

次の図は、Gitリセットコマンドの図解を示しています。

柔らかい

各ブランチには、最新のコミットを指すHEADポインターがあります。--softオプションの後にコミットIDを指定してGitresetコマンドを使用すると、何も破壊せずにHEADポインターのみがリセットされます。

.git/refs/heads/masterファイルには、HEADポインタのコミットIDが格納されます。を使用して確認できますgit log -1 コマンド。

[jerry@CentOS project]$ cat .git/refs/heads/master
577647211ed44fe2ae479427a0668a4f12ed71a1

次に、上記のコミットIDと一致する最新のコミットIDを表示します。

[jerry@CentOS project]$ git log -2

上記のコマンドは次の結果を生成します。

commit 577647211ed44fe2ae479427a0668a4f12ed71a1
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 10:21:20 2013 +0530

Removed executable binary


commit 29af9d45947dc044e33d69b9141d8d2dad37cc62
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 10:16:25 2013 +0530

Added compiled binary

HEADポインタをリセットしましょう。

[jerry@CentOS project]$ git reset --soft HEAD~

ここで、HEADポインタを1つ戻します。内容を確認しましょう.git/refs/heads/master file。

[jerry@CentOS project]$ cat .git/refs/heads/master
29af9d45947dc044e33d69b9141d8d2dad37cc62

ファイルからのコミットIDが変更されたので、コミットメッセージを表示して確認します。

jerry@CentOS project]$ git log -2

上記のコマンドは次の結果を生成します。

commit 29af9d45947dc044e33d69b9141d8d2dad37cc62
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 10:16:25 2013 +0530

Added compiled binary


commit 94f7b26005f856f1a1b733ad438e97a0cd509c1a
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 10:08:01 2013 +0530

Added Makefile and renamed strings.c to string_operations.c

混合

--mixedオプションを使用したGitリセットは、まだコミットされていないステージング領域からの変更を元に戻します。ステージング領域からの変更のみを元に戻します。ファイルの作業コピーに加えられた実際の変更は影響を受けません。デフォルトのGitリセットは、gitreset--mixedと同等です。

ハード

Git resetコマンドで--hardオプションを使用すると、ステージング領域がクリアされます。HEADポインタを特定のコミットIDの最新のコミットにリセットし、ローカルファイルの変更も削除します。

コミットIDを確認しましょう。

[jerry@CentOS src]$ pwd /home/jerry/jerry_repo/project/src [jerry@CentOS src]$ git log -1

上記のコマンドは次の結果を生成します。

commit 577647211ed44fe2ae479427a0668a4f12ed71a1
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 10:21:20 2013 +0530

Removed executable binary

Jerryは、ファイルの先頭に1行のコメントを追加して、ファイルを変更しました。

[jerry@CentOS src]$ head -2 string_operations.c
/* This line be removed by git reset operation */
#include <stdio.h>

彼はgitstatusコマンドを使用してそれを確認しました。

[jerry@CentOS src]$ git status -s
M string_operations.c

Jerryは、変更されたファイルをステージング領域に追加し、gitstatusコマンドで確認します。

[jerry@CentOS src]$ git add string_operations.c [jerry@CentOS src]$ git status

上記のコマンドは次の結果を生成します。

# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
#
modified: string_operations.c
#

Gitステータスは、ファイルがステージング領域に存在することを示しています。ここで、-hardオプションを使用してHEADをリセットします。

[jerry@CentOS src]$ git reset --hard 577647211ed44fe2ae479427a0668a4f12ed71a1

HEAD is now at 5776472 Removed executable binary

Git resetコマンドが成功しました。これにより、ファイルがステージング領域から元に戻され、ファイルに加えられたローカルの変更がすべて削除されます。

[jerry@CentOS src]$ git status -s

Gitステータスは、ファイルがステージング領域から戻されたことを示しています。

[jerry@CentOS src]$ head -2 string_operations.c
#include <stdio.h>

headコマンドは、リセット操作によってローカルの変更も削除されたことも示しています。

タグ操作により、リポジトリ内の特定のバージョンに意味のある名前を付けることができます。トムとジェリーがプロジェクトコードにタグを付けて、後で簡単にアクセスできるようにしたとします。

タグを作成する

を使用して現在のHEADにタグを付けましょう git tagコマンド。トムは-aオプションを使用してタグ名を提供し、-mオプションを使用してタグメッセージを提供します。

tom@CentOS project]$ pwd
/home/tom/top_repo/project

[tom@CentOS project]$ git tag -a 'Release_1_0' -m 'Tagged basic string operation code' HEAD

特定のコミットにタグを付ける場合は、HEADポインターの代わりに適切なCOMMITIDを使用します。トムは次のコマンドを使用して、タグをリモートリポジトリにプッシュします。

[tom@CentOS project]$ git push origin tag Release_1_0

上記のコマンドは次の結果を生成します-

Counting objects: 1, done.
Writing objects: 100% (1/1), 183 bytes, done.
Total 1 (delta 0), reused 0 (delta 0)
To [email protected]:project.git
* [new tag]
Release_1_0 −> Release_1_0

タグを表示

トムはタグを作成しました。これで、Jerryは–lオプションを指定してGit tagコマンドを使用することにより、使用可能なすべてのタグを表示できます。

[jerry@CentOS src]$ pwd /home/jerry/jerry_repo/project/src [jerry@CentOS src]$ git pull
remote: Counting objects: 1, done.
remote: Total 1 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (1/1), done.
From git.server.com:project
* [new tag]
Release_1_0 −> Release_1_0
Current branch master is up to date.

[jerry@CentOS src]$ git tag -l
Release_1_0

Jerryは、Git showコマンドに続けてタグ名を使用して、タグの詳細を表示します。

[jerry@CentOS src]$ git show Release_1_0

上記のコマンドは次の結果を生成します-

tag Release_1_0
Tagger: Tom Cat <[email protected]>
Date: Wed Sep 11 13:45:54 2013 +0530

Tagged basic string operation code


commit 577647211ed44fe2ae479427a0668a4f12ed71a1
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 10:21:20 2013 +0530

Removed executable binary

diff --git a/src/string_operations b/src/string_operations
deleted file mode 100755
index 654004b..0000000
Binary files a/src/string_operations and /dev/null differ

タグを削除する

トムは次のコマンドを使用して、ローカルリポジトリとリモートリポジトリからタグを削除します。

[tom@CentOS project]$ git tag Release_1_0 [tom@CentOS project]$ git tag -d Release_1_0
Deleted tag 'Release_1_0' (was 0f81ff4)
# Remove tag from remote repository.

[tom@CentOS project]$ git push origin :Release_1_0
To [email protected]:project.git
- [deleted]
Release_1_0

パッチはテキストファイルであり、その内容はGit diffに似ていますが、コードとともに、コミットに関するメタデータも含まれています。例：コミットID、日付、コミットメッセージなど。コミットからパッチを作成し、他の人がそれらをリポジトリに適用できます。

Jerryは、彼のプロジェクトにstrcat関数を実装しています。ジェリーは自分のコードのパスを作成してトムに送信できます。次に、受け取ったパッチを自分のコードに適用できます。

ジェリーはGitを使用しています format-patch最新のコミットのパッチを作成するコマンド。特定のコミット用のパッチを作成する場合は、COMMIT_ID format-patchコマンドを使用します。

[jerry@CentOS project]$ pwd
/home/jerry/jerry_repo/project/src

[jerry@CentOS src]$ git status -s M string_operations.c ?? string_operations [jerry@CentOS src]$ git add string_operations.c

[jerry@CentOS src]$ git commit -m "Added my_strcat function" [master b4c7f09] Added my_strcat function 1 files changed, 13 insertions(+), 0 deletions(-) [jerry@CentOS src]$ git format-patch -1
0001-Added-my_strcat-function.patch

上記のコマンドは .patch現在の作業ディレクトリ内のファイル。トムはこのパッチを使用してファイルを変更できます。Gitはパッチを適用するための2つのコマンドを提供しますgit amそして git apply、それぞれ。 Git apply コミットを作成せずにローカルファイルを変更しますが、 git am ファイルを変更し、コミットも作成します。

パッチを適用してコミットを作成するには、次のコマンドを使用します-

[tom@CentOS src]$ pwd /home/tom/top_repo/project/src [tom@CentOS src]$ git diff

[tom@CentOS src]$ git status –s [tom@CentOS src]$ git apply 0001-Added-my_strcat-function.patch

[tom@CentOS src]$ git status -s
M string_operations.c
?? 0001-Added-my_strcat-function.patch

パッチが正常に適用されました。これで、を使用して変更を表示できます。 git diff コマンド。

[tom@CentOS src]$ git diff

上記のコマンドは次の結果を生成します-

diff --git a/src/string_operations.c b/src/string_operations.c
index 8ab7f42..f282fcf 100644
--- a/src/string_operations.c
+++ b/src/string_operations.c
@@ -1,5 +1,16 @@
#include <stdio.h>
+char *my_strcat(char *t, char *s)
diff --git a/src/string_operations.c b/src/string_operations.c
index 8ab7f42..f282fcf 100644
--- a/src/string_operations.c
+++ b/src/string_operations.c
@@ -1,5 +1,16 @@
#include <stdio.h>
+char *my_strcat(char *t, char *s)
+
{
   +
   char *p = t;
   +
   +
   +
   while (*p)
   ++p;
   +
   while (*p++ = *s++)
   + ;
   + return t;
   +
}
+
size_t my_strlen(const char *s)
{
   const char *p = s;
   @@ -23,6 +34,7 @@ int main(void)
   {

ブランチオペレーションにより、別の開発ラインを作成できます。この操作を使用して、開発プロセスを2つの異なる方向に分岐させることができます。たとえば、6.0バージョンの製品をリリースしましたが、7.0の機能の開発を6.0のバグ修正とは別に維持できるように、ブランチを作成したい場合があります。

ブランチを作成する

Tomは、git branch <branchname>コマンドを使用して新しいブランチを作成します。既存のブランチから新しいブランチを作成できます。特定のコミットまたはタグを開始点として使用できます。特定のコミットIDが指定されていない場合、ブランチはHEADを開始点として作成されます。

[jerry@CentOS src]$ git branch new_branch [jerry@CentOS src]$ git branch
* master
new_branch

新しいブランチが作成されます。トムはgitbranchコマンドを使用して、使用可能なブランチを一覧表示しました。Gitは、現在チェックアウトされているブランチの前にアスタリスクマークを表示します。

ブランチの作成操作の図解を以下に示します-

ブランチを切り替える

Jerryは、gitcheckoutコマンドを使用してブランチを切り替えます。

[jerry@CentOS src]$ git checkout new_branch Switched to branch 'new_branch' [jerry@CentOS src]$ git branch
master
* new_branch

ブランチを作成して切り替えるためのショートカット

上記の例では、2つのコマンドを使用して、それぞれブランチを作成および切り替えています。Gitは提供します–bcheckoutコマンドのオプション。この操作により、新しいブランチが作成され、すぐに新しいブランチに切り替わります。

[jerry@CentOS src]$ git checkout -b test_branch Switched to a new branch 'test_branch' [jerry@CentOS src]$ git branch
master
new_branch
* test_branch

ブランチを削除する

git branchコマンドで–Dオプションを指定すると、ブランチを削除できます。ただし、既存のブランチを削除する前に、他のブランチに切り替えてください。

ジェリーは現在オンです test_branchそして彼はその枝を取り除きたいのです。そこで彼は、以下に示すようにブランチを切り替えてブランチを削除します。

[jerry@CentOS src]$ git branch master new_branch * test_branch [jerry@CentOS src]$ git checkout master
Switched to branch 'master'

[jerry@CentOS src]$ git branch -D test_branch
Deleted branch test_branch (was 5776472).

これで、Gitは2つのブランチのみを表示します。

[jerry@CentOS src]$ git branch
* master
new_branch

ブランチの名前を変更する

Jerryは、文字列操作プロジェクトでワイド文字のサポートを追加することにしました。彼はすでに新しいブランチを作成していますが、ブランチ名が適切ではありません。そこで彼はを使用してブランチ名を変更します–m オプションの後に old branch name そしてその new branch name。

[jerry@CentOS src]$ git branch * master new_branch [jerry@CentOS src]$ git branch -m new_branch wchar_support

これで、gitbranchコマンドに新しいブランチ名が表示されます。

[jerry@CentOS src]$ git branch
* master
wchar_support

2つのブランチをマージする

Jerryは、ワイド文字列の文字列長を返す関数を実装しています。新しいコードは次のように表示されます-

[jerry@CentOS src]$ git branch
master
* wchar_support

[jerry@CentOS src]$ pwd /home/jerry/jerry_repo/project/src [jerry@CentOS src]$ git diff

上記のコマンドは次の結果を生成します-

t a/src/string_operations.c b/src/string_operations.c
index 8ab7f42..8fb4b00 100644
--- a/src/string_operations.c
+++ b/src/string_operations.c
@@ -1,4 +1,14 @@
#include <stdio.h>
+#include <wchar.h>
+
+size_t w_strlen(const wchar_t *s)
+
{
   +
   const wchar_t *p = s;
   +
   +
   while (*p)
   + ++p;
   + return (p - s);
   +
}

テスト後、彼は自分の変更をコミットして新しいブランチにプッシュします。

[jerry@CentOS src]$ git status -s M string_operations.c ?? string_operations [jerry@CentOS src]$ git add string_operations.c

[jerry@CentOS src]$ git commit -m 'Added w_strlen function to return string lenght of wchar_t
string'

[wchar_support 64192f9] Added w_strlen function to return string lenght of wchar_t string
1 files changed, 10 insertions(+), 0 deletions(-)

ジェリーがこれらの変更を新しいブランチにプッシュしていることに注意してください。そのため、彼はブランチ名を使用しました。 wchar_support の代わりに master ブランチ。

[jerry@CentOS src]$ git push origin wchar_support  <−−− Observer branch_name

上記のコマンドは次の結果を生成します。

Counting objects: 7, done.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 507 bytes, done.
Total 4 (delta 1), reused 0 (delta 0)
To [email protected]:project.git
* [new branch]
wchar_support -> wchar_support

変更をコミットすると、新しいブランチは次のように表示されます-

トムはジェリーが自分のプライベートブランチで何をしているのか知りたくて、ログをチェックします。 wchar_support ブランチ。

[tom@CentOS src]$ pwd /home/tom/top_repo/project/src [tom@CentOS src]$ git log origin/wchar_support -2

上記のコマンドは次の結果を生成します。

commit 64192f91d7cc2bcdf3bf946dd33ece63b74184a3
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 16:10:06 2013 +0530

Added w_strlen function to return string lenght of wchar_t string


commit 577647211ed44fe2ae479427a0668a4f12ed71a1
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 10:21:20 2013 +0530

Removed executable binary

トムはコミットメッセージを表示することで、ジェリーがワイド文字のstrlen関数を実装しており、マスターブランチにも同じ機能が必要であることを認識しています。彼は、再実装する代わりに、自分のブランチをマスターブランチとマージしてジェリーのコードを取得することにしました。

[tom@CentOS project]$ git branch * master [tom@CentOS project]$ pwd
/home/tom/top_repo/project

[tom@CentOS project]$ git merge origin/wchar_support
Updating 5776472..64192f9
Fast-forward
src/string_operations.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)

マージ操作後、マスターブランチは次のように表示されます-

さて、ブランチ wchar_supportマスターブランチと統合されました。コミットメッセージを表示するか、string_operation.cファイルに加えられた変更を表示することで確認できます。

[tom@CentOS project]$ cd src/

[tom@CentOS src]$ git log -1

commit 64192f91d7cc2bcdf3bf946dd33ece63b74184a3
Author: Jerry Mouse 
      
        Date: Wed Sep 11 16:10:06 2013 +0530 Added w_strlen function to return string lenght of wchar_t string [tom@CentOS src]$ head -12 string_operations.c

上記のコマンドは次の結果を生成します。

#include <stdio.h>
#include <wchar.h>
size_t w_strlen(const wchar_t *s)
{
   const wchar_t *p = s;

   while (*p)
      ++p;

   return (p - s);
}

テスト後、彼はコードの変更をマスターブランチにプッシュします。

[tom@CentOS src]$ git push origin master
Total 0 (delta 0), reused 0 (delta 0)
To [email protected]:project.git
5776472..64192f9 master −> master

ブランチのリベース

Git rebaseコマンドはブランチマージコマンドですが、違いはコミットの順序を変更することです。

Gitマージコマンドは、他のブランチからのコミットを現在のローカルブランチのHEADの上に配置しようとします。たとえば、ローカルブランチにコミットA-> B-> C-> Dがあり、マージブランチにコミットA-> B-> X-> Yがある場合、gitmergeは現在のローカルブランチをA->のようなものに変換します。 B-> C-> D-> X-> Y

Git rebaseコマンドは、現在のローカルブランチとマージブランチの間の共通の祖先を見つけようとします。次に、現在のローカルブランチのコミットの順序を変更することにより、コミットをローカルブランチにプッシュします。たとえば、ローカルブランチにコミットA-> B-> C-> Dがあり、マージブランチにコミットA-> B-> X-> Yがある場合、Gitリベースは現在のローカルブランチをA-のようなものに変換します。 > B-> X-> Y-> C-> D。

複数の開発者が単一のリモートリポジトリで作業している場合、リモートリポジトリでのコミットの順序を変更することはできません。この状況では、リベース操作を使用して、ローカルコミットをリモートリポジトリコミットの上に配置し、これらの変更をプッシュできます。

wchar_supportブランチで変更を実行します

ジェリーはに取り組んでいます wchar_supportブランチ。彼は関数の名前を変更し、テスト後、変更をコミットします。

[jerry@CentOS src]$ git branch
 master
* wchar_support
[jerry@CentOS src]$ git diff

上記のコマンドは次の結果を生成します-

diff --git a/src/string_operations.c b/src/string_operations.c
index 8fb4b00..01ff4e0 100644
--- a/src/string_operations.c
+++ b/src/string_operations.c
@@ -1,7 +1,7 @@
#include <stdio.h>
#include <wchar.h>
-size_t w_strlen(const wchar_t *s)
+size_t my_wstrlen(const wchar_t *s)
{
   const wchar_t *p = s;

コードを確認した後、彼は変更をコミットします。

[jerry@CentOS src]$ git status -s
M string_operations.c

[jerry@CentOS src]$ git add string_operations.c [jerry@CentOS src]$ git commit -m 'Changed function name'
[wchar_support 3789fe8] Changed function name
1 files changed, 1 insertions(+), 1 deletions(-)

[jerry@CentOS src]$ git push origin wchar_support

上記のコマンドは次の結果を生成します-

Counting objects: 7, done.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 409 bytes, done.
Total 4 (delta 1), reused 0 (delta 0)
To [email protected]:project.git
64192f9..3789fe8 wchar_support -> wchar_support

マスターブランチで変更を実行する

一方、マスターブランチでは、トムも同じ関数の名前を変更し、変更をマスターブランチにプッシュします。

[tom@CentOS src]$ git branch
* master
[tom@CentOS src]$ git diff

上記のコマンドは次の結果を生成します-

diff --git a/src/string_operations.c b/src/string_operations.c
index 8fb4b00..52bec84 100644
--- a/src/string_operations.c
+++ b/src/string_operations.c
@@ -1,7 +1,8 @@
#include <stdio.h>
#include <wchar.h>
-size_t w_strlen(const wchar_t *s)
+/* wide character strlen fucntion */
+size_t my_wc_strlen(const wchar_t *s)
{
   const wchar_t *p = s;

差分を確認した後、彼は変更をコミットします。

[tom@CentOS src]$ git status -s
M string_operations.c

[tom@CentOS src]$ git add string_operations.c [tom@CentOS src]$ git commit -m 'Changed function name from w_strlen to my_wc_strlen'
[master ad4b530] Changed function name from w_strlen to my_wc_strlen
1 files changed, 2 insertions(+), 1 deletions(-)

[tom@CentOS src]$ git push origin master

上記のコマンドは次の結果を生成します-

Counting objects: 7, done.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 470 bytes, done.
Total 4 (delta 1), reused 0 (delta 0)
To [email protected]:project.git
64192f9..ad4b530 master -> master

に wchar_supportブランチでは、ジェリーはワイド文字列のstrchr関数を実装します。テスト後、彼は自分の変更をコミットしてにプッシュしますwchar_support ブランチ。

[jerry@CentOS src]$ git branch
master
* wchar_support
[jerry@CentOS src]$ git diff

上記のコマンドは次の結果を生成します-

diff --git a/src/string_operations.c b/src/string_operations.c
index 01ff4e0..163a779 100644
--- a/src/string_operations.c
+++ b/src/string_operations.c
@@ -1,6 +1,16 @@
#include <stdio.h>
#include <wchar.h>
+wchar_t *my_wstrchr(wchar_t *ws, wchar_t wc)
+
{
   +
   while (*ws) 
   {
      +
      if (*ws == wc)
      +
      return ws;
      +
      ++ws;
      + 
   }
   + return NULL;
   +
}
+
size_t my_wstrlen(const wchar_t *s)
{
   const wchar_t *p = s;

確認した後、彼は変更をコミットします。

[jerry@CentOS src]$ git status -s
M string_operations.c

[jerry@CentOS src]$ git add string_operations.c [jerry@CentOS src]$ git commit -m 'Addded strchr function for wide character string'
[wchar_support 9d201a9] Addded strchr function for wide character string
1 files changed, 10 insertions(+), 0 deletions(-)

[jerry@CentOS src]$ git push origin wchar_support

上記のコマンドは次の結果を生成します-

Counting objects: 7, done.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 516 bytes, done.
Total 4 (delta 1), reused 0 (delta 0)
To [email protected]:project.git
3789fe8..9d201a9 wchar_support -> wchar_support

紛争に取り組む

トムはジェリーが自分のプライベートブランチで何をしているのかを見たいので、最新の変更をプルしようとします。 wchar_support ブランチしますが、Gitは次のエラーメッセージで操作を中止します。

[tom@CentOS src]$ git pull origin wchar_support

上記のコマンドは次の結果を生成します-

remote: Counting objects: 11, done.
63Git Tutorials
remote: Compressing objects: 100% (8/8), done.
remote: Total 8 (delta 2), reused 0 (delta 0)
Unpacking objects: 100% (8/8), done.
From git.server.com:project
* branch
wchar_support -> FETCH_HEAD
Auto-merging src/string_operations.c
CONFLICT (content): Merge conflict in src/string_operations.c
Automatic merge failed; fix conflicts and then commit the result.

競合を解決する

エラーメッセージから、src /string_operations.cに競合があることは明らかです。彼はgitdiffコマンドを実行して、詳細を表示します。

[tom@CentOS src]$ git diff

上記のコマンドは次の結果を生成します-

diff --cc src/string_operations.c
index 52bec84,163a779..0000000
--- a/src/string_operations.c
+++ b/src/string_operations.c
@@@ -1,8 -1,17 +1,22 @@@
#include <stdio.h>
#include <wchar.h>
++<<<<<<< HEAD
+/* wide character strlen fucntion */
+size_t my_wc_strlen(const wchar_t *s)
++=======
+ wchar_t *my_wstrchr(wchar_t *ws, wchar_t wc)
+
{
   +
   +
   while (*ws) 
   {
      if (*ws == wc)
      +
      return ws;
      +
      ++ws;
      + 
   }
   + return NULL;
   +
}
+
+ size_t my_wstrlen(const wchar_t *s)
++>>>>>>>9d201a9c61bc4713f4095175f8954b642dae8f86
{
   const wchar_t *p = s;

トムとジェリーの両方が同じ関数の名前を変更したため、Gitは混乱状態にあり、ユーザーに競合を手動で解決するように求めています。

トムはジェリーが提案した関数名を保持することにしましたが、彼が追加したコメントはそのままにしておきます。競合マーカーを削除すると、gitdiffは次のようになります。

[tom@CentOS src]$ git diff

上記のコマンドは次の結果を生成します。

diff --cc src/string_operations.c
diff --cc src/string_operations.c
index 52bec84,163a779..0000000
--- a/src/string_operations.c
+++ b/src/string_operations.c
@@@ -1,8 -1,17 +1,18 @@@
#include <stdio.h>
#include <wchar.h>
+ wchar_t *my_wstrchr(wchar_t *ws, wchar_t wc)
+
{
   +
   while (*ws) 
   {
      +
      if (*ws == wc)
      +
      return ws;
      +
      ++ws;
      + 
   }
   + return NULL;
   +
}
+
+/* wide character strlen fucntion */
- size_t my_wc_strlen(const wchar_t *s)
+ size_t my_wstrlen(const wchar_t *s)
{
   const wchar_t *p = s;

トムはファイルを変更したので、最初にこれらの変更をコミットする必要があり、その後、変更をプルできます。

[tom@CentOS src]$ git commit -a -m 'Resolved conflict' [master 6b1ac36] Resolved conflict [tom@CentOS src]$ git pull origin wchar_support.

トムは競合を解決しました。プル操作は成功します。

GNU / LinuxおよびMacOSは line-feed (LF)、または行末文字としての改行、Windowsは line-feed and carriage-return (LFCR) 行末文字を表す組み合わせ。

これらの行末の違いによる不要なコミットを回避するには、Gitリポジトリに同じ行末を書き込むようにGitクライアントを構成する必要があります。

Windowsシステムの場合、行末をに変換するようにGitクライアントを構成できます。 CRLF チェックアウト時にフォーマットし、それらをに変換し直します LFコミット操作中のフォーマット。以下の設定で必要になります。

[tom@CentOS project]$ git config --global core.autocrlf true

GNU / LinuxまたはMacOSの場合、行末を変換するようにGitクライアントを構成できます。 CRLF に LF チェックアウト操作の実行中。

[tom@CentOS project]$ git config --global core.autocrlf input

GitHubは、Gitリビジョン管理システムを使用するソフトウェア開発プロジェクト向けのWebベースのホスティングサービスです。また、サービスのWebサイトから直接ダウンロードできる標準のGUIアプリケーション（Windows、Mac、GNU / Linux）もあります。ただし、このセッションでは、CLI部分のみを表示します。

GitHubリポジトリを作成する

移動しますgithub.com。すでにお持ちの場合GitHubアカウントを作成し、そのアカウントを使用してログインするか、新しいアカウントを作成します。github.com Webサイトの手順に従って、新しいリポジトリを作成します。

プッシュ操作

トムは使用することにしました GitHubサーバ。新しいプロジェクトを開始するために、彼は新しいディレクトリとその中に1つのファイルを作成します。

[tom@CentOS]$ mkdir github_repo [tom@CentOS]$ cd github_repo/

[tom@CentOS]$ vi hello.c [tom@CentOS]$ make hello
cc hello.c -o hello

[tom@CentOS]$ ./hello

上記のコマンドは、次の結果を生成します。

Hello, World !!!

コードを確認した後、彼はgit initコマンドを使用してディレクトリを初期化し、変更をローカルにコミットします。

[tom@CentOS]$ git init
Initialized empty Git repository in /home/tom/github_repo/.git/

[tom@CentOS]$ git status -s ?? hello ?? hello.c [tom@CentOS]$ git add hello.c

[tom@CentOS]$ git status -s A hello.c ?? hello [tom@CentOS]$ git commit -m 'Initial commit'

その後、彼は追加します GitHub リモートオリジンとしてのリポジトリURLと、彼の変更をリモートリポジトリにプッシュします。

[tom@CentOS]$ git remote add origin https://github.com/kangralkar/testing_repo.git [tom@CentOS]$ git push -u origin master

プッシュ操作は要求します GitHubユーザー名とパスワード。認証が成功すると、操作は成功します。

上記のコマンドは、次の結果を生成します。

Username for 'https://github.com': kangralkar
Password for 'https://[email protected]': 
Counting objects: 3, done.
Writing objects: 100% (3/3), 214 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/kangralkar/test_repo.git
 * [new branch]      master −> master
 Branch master set up to track remote branch master from origin.

これから、トムは変更をプッシュできます GitHubリポジトリ。彼は、この章で説明されているすべてのコマンドをGitHub リポジトリ。

プル操作

トムはすべての変更を正常にプッシュしました GitHubリポジトリ。現在、他の開発者は、クローン操作を実行するか、ローカルリポジトリを更新することにより、これらの変更を表示できます。

ジェリーはホームディレクトリに新しいディレクトリを作成し、クローンを作成します。 GitHub gitcloneコマンドを使用してリポジトリ。

[jerry@CentOS]$ pwd /home/jerry [jerry@CentOS]$ mkdir jerry_repo

[jerry@CentOS]$ git clone https://github.com/kangralkar/test_repo.git

上記のコマンドは、次の結果を生成します。

Cloning into 'test_repo'...
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 3 (delta 0)
Unpacking objects: 100% (3/3), done.

彼はlsコマンドを実行してディレクトリの内容を確認します。

[jerry@CentOS]$ ls
test_repo

[jerry@CentOS]$ ls test_repo/
hello.c