Gitデバイスについて少し（簡略化）。
Git-分散VCS。 これは、サーバー上の1つのリポジトリで作業しているのではなく、全員がリポジトリのローカルコピーを持っていることを意味します。 したがって、チェックアウトやコミットなどの操作はローカルリポジトリで実行されます。 互いに（またはサーバー上のものと）、リポジトリは特別に設計されたプル（フェッチ）およびプッシュコマンドと同期されます。
これは便利です。 これにより、サーバーへの接続が現在ない場合でも、好きなだけコミットできます。
Gitの重要な利点は、ブランチのわかりやすい作業と便利なマージメカニズムです。 SVNでは、通常1つのトランクブランチで作業しました（gitでは、デフォルトで作業するブランチはマスターと呼ばれます）。 同じブランチが本番環境に殺到しました。 ここでの主な不便な点は、何らかの変更を行うか、新しい機能を開発する場合、最後までタスクが完了するまで座ってコミットしないこと、または（同僚の助けが必要な場合）未完了のままコミットすることです機能性はそのままで、トランクを生産の充填に適さないようにします。 これは、新しい機能が1日以上実行された場合に特に不快であり、この時点で作業中のシステムの何かを緊急に修復する必要があります。
もちろん、SVNにはブランチがありますが、それらは明らかに別のブランチ用に作られているため、それらをトランクにマージするのにはあまり適していません。 gitでは、マージ操作はエレガントで便利です。これにより、ワークフローをより最適なものに大幅に変更できます。
gitとのもう1つの違いは、変更を保存するのではなく、常にプロジェクトの現在の状態を保存することです。
主なものについて。
- マスターはそのブランチであり、常に（！）いつでも本番環境への展開の準備ができている必要があります。
- そのため、マスターですぐに新機能やバグ修正を行うことはありません。これにはブランチを使用します。
- 記事1 2 3 4 、そしておそらくGit bookを勉強するのも有用でしょう。 記事No. 2 では 、 オレガンザは非常に重要な原則を策定しました。1つの機能-1つのブランチです。 1つのバグ修正（2回のコミットよりも長い場合）-1つのブランチ。 1つの実験-1つのブランチ。 実験内の1つの機能は、ブランチからブランチです。
- コミットについては常に賢明なコメントを書いてください。
- 機能（バグ修正）の作成、テスト、および実稼働の準備が整ったら、ブランチをmasterにマージします。
マスターに直接コミットできるのはいつですか？ 私たちの小さな変更が間違いなく問題を解決し、新しい問題を作成しないと確信している場合のみ。 後でバグ修正のためにバグ修正を行う必要がないことが確実な場合。 同時に、変更は最小限にする必要があります。
したがって、適切なルールは、別のブランチを作成することです（非常に単純な場合を除く）。
カスタマイズ。
$ git config --global user.name "First Last"
$ git config --global user.email "email@example.com"
$ git config --global color.diff "auto"
$ git config --global color.status "auto"
$ git config --global color.branch "auto"
さらに、シェルエイリアスは、記事2で説明されているように構成できます。
標準ワークフロー。
手順1.はじめに-リポジトリのクローンを作成します。
プロジェクトが置かれているgitosisがすでにあり、設定済みであると想定しています。
git clone gitosis@git.yourserver.com:yourproject.git
このステップは1回行われます。
結果は、ハードドライブ上のプロジェクトを含むyourprojectフォルダーになります。 cloneコマンドは次のことを行います：リモートリポジトリを新しいフォルダー（この場合はプロジェクト）に複製し、リモートリポジトリのすべてのブランチのローカルリポジトリにリモートトラッキングブランチを作成し、現在アクティブなリモートブランチのローカルコピーを作成して、そこからチェックアウトします。
ステップ2a 新しいコードまたはバグ修正を書く。
1. git branch-現在リポジトリにあるブランチを確認します。 クローン作成後すぐに、リモートリポジトリで現在アクティブなブランチが1つだけ表示されます（この例では、リモートリポジトリがサーバー上にあり、誰もブランチを切り替えないため、これがデフォルトマスターです）。 リポジトリに他のブランチがある場合、-aスイッチを追加することでそれらを見ることができます（アクティブなブランチはアスタリスクで示されます）：
$ git branch -a
* master
origin/HEAD
origin/master
origin/feature
2.機能featureを実装するとします。 branchコマンドを使用して、ローカルに新しいブランチを作成します。 checkoutコマンドはブランチを切り替えることができます：
$ git branch feature
$ git checkout feature
Switched to branch "feature"
または、同じですが、短いだけです：
$ git checkout -b feature
Switched to a new branch "feature"
3. gitには、インデックスなどがあります。 たとえば、commitコマンドは、現在インデックスにあるファイルのみをリポジトリに追加します。 したがって、操作中に、リポジトリインデックスにファイルを追加（git add）または削除（git rm）することを忘れないでください。 SVNとは異なり、ファイルを変更した場合、git addコマンドで再度インデックスに追加する必要があることに注意してください。
例：
$ git add file1 file2
$ $ git commit -m "adding file1 & file2"
Created initial commit 8985f44: adding file1 & file2
2 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 file1
create mode 100644 file2
ここには便利な機能があります：git addコマンド。 追跡されていないすべてのファイルをインデックスに（再帰的に）追加します。commitコマンドの-aスイッチを使用すると、すべての変更された（ただし新規ではない）ファイルを自動的に追加できます。
インデックスの現在の状態は、git statusコマンドで表示できます：
$ git status
# On branch feature
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: file1
# new file: file2
#
リポジトリ内のコミットは、git logコマンドによって確認されます。
4.新しい機能を一緒に開発したい場合、他の人が作業できるようにブランチをサーバーに公開する必要があります。 方法は次のとおりです（その前に、このブランチのすべての変更をコミットする必要があります）。
$ git push origin feature:refs/heads/feature
Counting objects: 4, done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 273 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
To gitosis@git.yourserver.com:yourproject.git
* [new branch] feature -> feature
（gitの新しいバージョンでは、単純にgit push origin機能を使用できます：feature）
pushコマンドは、そこに作成した後、ローカルフィーチャーブランチからリモートフィーチャーブランチにリモートリポジトリ（オリジン）への変更を送信します（ブランチを作成するには、refs / heads / featureが必要です）。 将来、git push origin機能を使用できるようになります（デフォルトでは、git pushはすべてのブランチから変更を公開します）。
しかし、この公開方法では、ブランチのローカルバージョンと公開されたブランチとの接続は確立されません。 つまり 誰かがこのリモートブランチに変更をコミットし、git pullを実行すると、エラーが発生します：
$ git pull
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 2 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (2/2), done.
From gitosis@git.yourproject.com:yourproject
d23a39c..b0a86e0 feature -> origin/feature
You asked me to pull without telling me which branch you
want to merge with, and 'branch.feature.merge' in
your configuration file does not tell me either. Please
name which branch you want to merge on the command line and
try again (eg 'git pull <repository> <refspec>').
See git-pull(1) for details on the refspec.
If you often merge with the same branch, you may want to
configure the following variables in your configuration
file:
branch.feature.remote = <nickname>
branch.feature.merge = <remote-ref>
remote.<nickname>.url = <url>
remote.<nickname>.fetch = <refspec>
See git-config(1) for details.
つまり gitは、彼がどのブランチからmerzhitしたかを知りません。 したがって、毎回これを手で示すことができます。
git pull origin feature
または、構成に登録します。
git config branch.feature.remote origin
git config branch.feature.merge refs/heads/feature
さらに、William Morganのスクリプトを使用して、他のすべての代わりにgit publish-branch機能を実行できます。
ステップ2b ブランチで作業に参加する方法。
リポジトリをすでにクローンしていることを前提としています。
ここでの主なことは、リモートブランチを正しく接続することです。 これは、git checkoutコマンドの--trackスイッチを使用して実行できます。 以下のコマンドは、ローカル機能ブランチを作成し、それをリモートの起点/機能ブランチに接続し、その後このブランチに切り替えます。
$ git checkout --track -b feature origin/feature
Branch feature set up to track remote branch refs/remotes/origin/feature.
Switched to a new branch "feature"
これはこの段階では重要です。なぜなら、pullコマンドだけがリモートブランチをマスターに保持し、これは必要なものではないからです。
次に、手順2aで説明した方法と同様に作業して、各ブランチのリポジトリをgit pullコマンドとgit pushコマンドで同期します。
ステップ2c。 現在のブランチに変更があるときに別のブランチに切り替えて、それらを早期にコミットする方法。
バグ修正などのために、緊急に別のブランチに切り替えることが必要になる場合があります。 しかし、このスレッドでの完全なコミットではまだ十分ではありません。 これにはgit stashコマンドがあります：
$ git status
# On branch feature
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: somefile
#
$ git stash
Saved working directory and index state "WIP on feature: b0a86e0... blabla"
HEAD is now at b0a86e0 blabla
(To restore them type "git stash apply")
$ git status
# On branch feature
nothing to commit (working directory clean)
これで、別のブランチに安全に切り替えてそこで作業できます。
このブランチに戻ったら、git stash applyを実行する必要があります。
$ git stash apply
# On branch feature
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: somefile
#
ステップ3.マージおよびリベース。
次の2つの場合に、これらのコマンドのいずれかを使用する必要があります。
- マスターからブランチに最新の変更をプッシュする必要があります。
- ブランチをマスターにマージします。
一般的なルールは次のとおりです。ブランチで独立して作業し、サーバー上でブランチを公開する予定がない場合は、リベースを使用する方がより有益です。 プッシュコマンドを使用してブランチを公開する場合、リベースを使用できません。そうしないと、同僚の作業が自動的に無効になります。 マージとリベースの違いは、Gitブックのイラストによく示されています： merge and rebase 。 つまり、rebaseはブランチからのコミットをパッチの形で記憶し、現在のブランチを「ブランチがないように」巻き戻し、パッチを適用し、コミットとして発行します。 リベースとは異なり、mergeは2つのブランチを1つにマージします。
例：
変更をマスターから機能作業ブランチにアップロードします。機能ブランチはどこにも公開せず、ローカルでのみ作業します。
$ git checkout feature
Switched to branch "feature"
$ git rebase master
First, rewinding head to replay your work on top of it...
HEAD is now at 89f6a20 file2
Applying feature1
機能ワーキングブランチからマスターへの変更をマージします。機能ブランチはどこにも公開されておらず、同僚は誰もそれに取り組みませんでした。
$ git checkout master
Switched to branch "master"
$ git rebase feature
First, rewinding head to replay your work on top of it...
HEAD is now at 9bfac0a feature1
Applying file2
マスターから機能作業ブランチに変更をアップロードします。機能ブランチはリモートリポジトリに公開されており、同僚も作業しています。
$ git checkout feature
Switched to branch "feature"
$ git merge master
Merge made by recursive.
file2 | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 file2
機能作業ブランチからマスターへの変更をマージします。機能ブランチは、コラボレーションのためにリモートリポジトリに公開されました。
$ git checkout master
Switched to branch "master"
$ git merge feature
Merge made by recursive.
feature1 | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 feature1
ステップ4.ブランチを削除する。
ブランチでの作業を終了し、変更をマスター（または別のブランチ）にマージしたら、ブランチを削除できます。
ローカルブランチを削除するには：
$ git branch -d feature
Deleted branch feature.
リモート追跡ブランチを削除するには：
$ git push origin :feature
- [deleted] feature
それだけです。 SVNからGitに移行する場合、最初はこれで十分です。
このテキストへのあらゆる種類の追加と改善に対してhabrayuzer mironov_antonに感謝します。