1はじめに
私の最後の投稿で、私は
分散gitバージョン管理システムと比較した相違点
古典的な一元化されたハード通貨。 目標は主に経験を一般化することでした
個々のコマンドの構文の微妙な点に言及せずにシステムを操作します。
これと同じトピックは、Gitの操作を直接紹介するものとして考えられました。
チュートリアルと一般化されたヘルプの中間、まだ推奨されています
上記の概要をお読みください。 意図的に回避された技術
gitの詳細、SLEに共通の用語のみが使用され、
上記のコマンドのリストに限定されます。
2ローカルリポジトリの操作
分散システムの能力は、すべてのローカル開発者が利用できます。
任意の個人用スキームを編成できるリポジトリ
開発。 gitには、適切な作業を行うためのいくつかの基本的なコマンドがあります。
多くの補助。
2.1基本的なコマンド
基本的なコマンドは、開発中になしでは実行できないコマンドです。
2.1.1 git init-リポジトリの作成
git initコマンドは、ディレクトリ内にディレクトリとして空のリポジトリを作成します
.git、コミットの履歴に関するすべての情報が将来保存される場所、
タグ-プロジェクト開発の進捗：
mkdir project-dir
cd project-dir
git init
リポジトリを作成する別の方法は、git cloneコマンドを使用することですが、これについては後で詳しく説明します。
2.1.2 git addおよびgit rm-インデックス作成の変更
次に知っておくべきことは、git addコマンドです。 これにより、インデックスに変更を加えることができます-一時ストレージ-その後、コミットに含まれます。 例
使用：
git add EDITEDFILE-変更されたファイルのインデックス作成、または通知
新しいものを作成します。
git add。 -新しいファイルを含め、インデックスにすべての変更を加えます。
インデックスとプロジェクトツリーから同時に、git rmコマンドを使用してファイルを削除できます。
git rm FILE1 FILE2-個別のファイル
git rm Documentation / \ *。txtは、gitドキュメントから削除する良い例です。
フォルダのすべてのtxtファイルはすぐに削除されます。
インデックス全体をリセットするか、インデックスから特定のファイルへの変更を削除できます。
git resetコマンド：
git reset-インデックス全体をリセットします。
git reset-EDITEDFILE-インデックスから特定のファイルを削除します。
git resetコマンドはインデックスをリセットするためだけに使用されるわけではありません。
彼女はもっと注目されます。
2.1.3 git status-プロジェクトのステータス、変更されたファイルと追加されていないファイル、インデックス付きファイル
git statusコマンドはおそらく最も一般的に使用されます
チームのコミットとインデックス作成。 すべての変更に関する情報が表示され、
最後の作業コミットと比較してツリーに追加されたプロジェクトディレクトリ
枝 個別に入力されたインデックスとインデックスなし
ファイル。 それを使用することは非常に簡単です：
git status
さらに、gitステータスは、未解決のマージ競合があるファイルを示し、
gitによって無視されるファイル。
2.1.4 git commit-コミット
コミットはすべてのバージョン管理システムの基本概念であるため、
可能な限り簡単かつ高速である必要があります。 最も単純な形式で、十分な
インデックスタイプの後：
git commit
インデックスが空でない場合、それに基づいてコミットがコミットされ、その後コミットされます
ユーザーは、コマンドを呼び出して行った変更についてコメントするよう求められます
編集（たとえば、Ubuntuでは、通常、単純なnanoテキストエディターが呼び出されますが、
私-emacs）。 保存して、ベール！ コミットの準備ができました。
git commitでの作業を簡単にするいくつかのキーがあります。
git commit -a-ファイルへの変更のインデックスを自動的にコミットします
プロジェクト。 新しいファイルは索引付けされません ！ 同じファイルを削除する
考慮されます。
git commit -m "commit comment"-コマンドラインから直接コミットにコメントする
テキストエディタの代わりに。
git commit FILENAME-変更に基づいてコミットをインデックス化し、作成します
単一ファイル。
2.1.5 git reset-特定のコミット、ロールバックの変更、「ハード」または「ソフト」に戻る
インデックスの操作（上記を参照）に加えて、git resetでは状態をリセットできます
履歴のコミット前のプロジェクト。 gitでは、このアクションは2つにすることができます
タイプ：「ソフト」（ソフトリセット）および「ハード」（ハードリセット）。
「ソフト」（「--soft」キーを使用）カットでは、インデックスとツリー全体がそのまま残ります。
プロジェクトのファイルとディレクトリは、指定されたコミットで動作するように戻ります。 その他
つまり、コミットされたばかりのコミットでエラーが見つかった場合、または
それにコメントすると、状況を簡単に修正できます：
- git commit ...-不正なコミット。
- git reset --soft HEAD ^-すでにコミットされたコミットに取り組みます。
すべてのプロジェクトステータスとインデックスファイルを保存する
- 間違ったファイルを編集
- ANOTHERWRONGFILEを編集
- 追加します。
6.1。 git commit -c ORIG_HEAD-最後のコミットに戻ると、提供されます
彼のメッセージを編集します。 メッセージが変更されない場合、
キーケース-cを変更するだけです：
6.2。 git commit -C ORIG_HEAD
HEAD ^の指定に注意してください。「先祖に連絡する」という意味です。
最後のコミット。」 このような相対アドレス指定の構文について、さらに詳しく説明します。
「ハッシュ、タグ、相対アドレス指定」セクションの下位になります。 したがって、
HEAD-最後のコミットへのリンク。 ソフトカット後のORIG_HEADのリンク
元のコミットを示します。
当然、コミットの深さをより深くすることができますが、
ハードカット（--hard switch）-使用するコマンド
注意。 Gitのリセット--hardは、プロジェクトツリーとインデックスを状態に戻します。
指定されたコミットに対応し、後続のコミットの変更を削除します。
git add。
git commit -m "死に至る"
git reset --hard HEAD〜1-他の誰もこの恥ずべきコミットを見ることはありません。
git reset --hard HEAD〜3-または、最後の3つのコミット。 誰も。 決して。
コマンドが分岐点に達すると、コミットは削除されません。
リモートリポジトリから最近の変更をマージまたはデフレートするため
rezetの例は、関連するセクションで説明します。
2.1.6 git revert-過去に行われた変更を別のコミットで破棄する
個人が行った変更を破棄したい状況があるかもしれません
コミットします。 Gitの復帰により、新しいコミットが作成され、変更が元に戻されます。
git revert config-modify-tag-タグでマークされたコミットをキャンセルします。
git revert 12abacd-ハッシュを使用してコミットをキャンセルします。
チームを使用するには、プロジェクトの状態が次と変わらないことが必要です。
最後のコミットによってコミットされた状態。
2.1.7 git log-コミットに関する一般的なさまざまな情報、個々のファイルおよびさまざまな深さの履歴への没入
時々、コミットの履歴に関する情報、変更されたコミットを取得する必要があります
別のファイル。 特定の期間などにコミットします。 これらのために
目標はgit logコマンドを使用します。
すべてへのクイックリファレンスを提供する最も単純なユースケース
現在アクティブなブランチに触れたコミット（ブランチとブランチについて）
詳細については、以下の「ブランチとマージ」セクションをご覧ください。
git log
コミットからのファイルのパッチの形式で、それぞれに関する詳細情報を取得します
-p（または-u）スイッチを追加することにより：
git log -p
変更されたファイルの数など、ファイル変更の統計
行、削除されたファイルは--statスイッチで呼び出されます：
git log --stat
キーは、ファイルの作成、名前変更、アクセス権に関する情報を管理します
-概要：
git log --summary
単一のファイルの履歴を調べるには、パラメーターの形式で示すだけで十分です。
彼の名前（ところで、私の古いバージョンのgitでは、このメソッドは機能しませんが、
「README」の前に「-」を必ず追加してください）。
git log README
または、gitバージョンが最新でない場合：
git log-README
構文の最新バージョンのみを以下に示します。 たぶん
特定の瞬間から始まる時間を示します（「週」、「日」、「時間」、「s」
など）：
git log --since = "1日2時間" README
git log --since = "2 hours" README
git log --since = "2 hours" dir /-別のフォルダーに関する変更。
タグで構築できます：
git log v1 ...-v1タグで始まるすべてのコミット。
git log v1 ... README-で始まるREADMEファイルへの変更を含むすべてのコミット
タグv1。
git log v1..v2 README-で始まるREADMEファイルへの変更を含むすべてのコミット
v1タグとv2タグで終わる。
タグの作成、リスト、割り当ては、適切な
以下のセクション。
--prettyスイッチは、コマンド出力の形式に興味深いオプションを提供します。
git log --pretty = oneline-各コミットにハッシュで構成される行を出力します
（ここでは、各コミットの一意の識別子。これについては後で詳しく説明します）。
git log --pretty = short-コミットに関する簡潔な情報のみ
著者とコメント
git log --pretty = full / fuller-コミットに関するより完全な情報、名前付き
作成者、コメント、作成日、コミットの紹介
原則として、出力形式は独立して決定できます。
git log --pretty = format： 'FORMAT'
形式の定義は、Git Community Bookのgit logセクションにあります。
または助けます。 キーを使用して、コミットの美しいASCIIグラフが表示されます
-グラフ。
2.1.8 git diff-プロジェクトツリー間の違い。 コミット; インデックスの状態とコミット。
git logコマンドのサブセットの一種はgit diffコマンドです。
プロジェクト内のオブジェクト間の変更の定義：ツリー（ファイルと
ディレクトリ）：
git diff-インデックスに加えられていない変更を表示します。
git diff --cached-インデックスに加えられた変更。
git diff HEAD-最後のコミットと比較したプロジェクトの変更
git diff HEAD ^-最後から2番目のコミット
ブランチの「ヘッド」を比較できます。
git diff master..experimental
まあ、またはいずれかのアクティブなブランチ：
git diff Experimental
2.1.9 git show-別のコミットによる変更を表示
gitコマンドを使用して、履歴のコミットによって行われた変更を確認できます
表示：
git show COMMIT_TAG
2.1.10 git blameとgit annotate-ファイルの変更を追跡するのに役立つヘルパーコマンド
チームで働くとき、特定の人を書いた人を正確に見つける必要があることがよくあります。
コード。 次に関する行ごとの情報を表示するgit blameコマンドを使用すると便利です。
行に触れた最後のコミット、著者名、コミットハッシュ：
git blame README
表示する特定の行を指定することもできます。
git blame -L 2、+ 3 README-2行目から始まる3行で情報を表示します。
git annotateコマンドも同様に機能し、文字列と
それらに影響を与えたコミット：
git annotate README
2.1.11 git grep-プロジェクト、過去のプロジェクトステータスで単語を検索
git grepは、一般に、有名なUnixの機能を単純に複製します。
チーム。 ただし、プロジェクトの過去に単語とその組み合わせを検索できます。
非常に便利です：
git grep tst-プロジェクトで単語tstを検索します。
git grep -c tst-プロジェクト内のtstへの参照の数をカウントします。
git grep tst v1-プロジェクトの古いバージョンを検索します。
このコマンドを使用すると、論理ANDおよびORを使用できます。
git grep -e 'first' --and -e 'another'-最初の行が記載されている行を見つける
言葉、そして秒。
git grep --all-match -e 'first' -e 'second'-それが発生する行を見つける
言葉の一つでしょう。
2.2分岐
ブランチの操作とマージはgitの中心であり、これを実現するのはこれらの機能です
システムとの便利な仕事。
2.2.1 git branch-ブランチの作成、列挙、削除
gitでのブランチの操作は非常に簡単な手順で、すべての必要なメカニズムがあります
1つのチームに集中：
git branch-既存のブランチをリストし、アクティブにマークします。
git branch new-branch-新しいブランチnew-branchを作成します。
git branch -d new-branch-マージされたブランチを削除します
現在の競合の可能性の解決。
git branch -D new-branch- とにかくブランチを削除します 。
git branch -m new-name-branch-ブランチの名前を変更します。
git branch --contains v1.2-先祖が存在するブランチを表示します
特定のコミット。
2.2.2 git checkout-ブランチを切り替え、コミット履歴から個々のファイルを抽出します
git checkoutコマンドを使用すると、最後のコミット間で切り替えることができます（
簡略化された）ブランチ：
他のブランチをチェックアウトする
checkout -b some-other-new-branch-ブランチを作成します。
切り替え。
の最後のコミットと比較して現在のブランチに変更があった場合
ブランチ（HEAD）、チームは負けないように切り替えを拒否します
完了した作業。 -fスイッチを使用すると、この事実を無視できます。
checkout -f some-other-branch
それでも変更を保存する必要がある場合は、-mスイッチを使用します。 それからチーム
切り替える前に、現在のブランチに変更をアップロードしようとし、その後
競合の可能性を解決するには、新しい競合に切り替えます。
checkout -m some-other-branch
ファイルを返す（または単に以前のコミットからファイルを取り出す）には、次の形式のコマンドを使用できます。
git checkout somefile-somefileを最後のコミットの状態に戻す
git checkout HEAD〜2 somefile-somefileをブランチに沿って2つのコミット状態に戻します。
2.2.3 git merge-ブランチをマージします（競合の可能性を解決します）。
gitでの集中システムの通常のプラクティスとは異なり、ブランチのマージ
ほぼ毎日発生します。 当然、便利なインターフェイスがあります
人気のある操作：
git merge new-feature-現在のブランチと新機能のブランチをマージしようとします。
競合が発生した場合、コミットは発生しませんが、問題のあるファイルについては発生します
特別なマークはla svnに配置されます。 ファイル自体は、インデックス内で次のようにマークされます。
「接続されていません」（未結合）。 問題が解決するまで、コミットします
それは不可能です。
たとえば、TROUBLEファイルで競合が発生しました。これはgitステータスで確認できます。
git merge実験-失敗したマージ試行が発生しました。
git status-問題領域を調べます。
トラブルの編集-問題を解決します。
git add。 -変更にインデックスを付け、タグを削除します。
git commit-マージコミットをコミットします。
それだけです、複雑なことは何もありません。 解決プロセス中に、許可について考えが変わった場合
競合、入力するだけ：
git reset --hard HEAD-これにより、両方のブランチが元の状態に戻ります。
マージコミットがコミットされた場合、次のコマンドを使用します。
git reset --hard ORIG_HEAD
2.2.4 git rebase-フラットなコミットラインを構築する
開発者が別のブランチを開発するための追加のブランチを持っているとします
機会とその中でいくつかのコミットを行いました。 同時に
メインブランチでもコミットがコミットされた理由：たとえば、
変更はリモートサーバーからダウンロードされます。 または開発者自身がそれにコミットしました
コミットします。
原則として、通常のgit mergeでできます。 しかし、その後、線はより複雑になります
開発、これは大きすぎるプロジェクトでは望ましくありません。
多くの開発者。
masterとtopicという2つのブランチがあり、それぞれにブランチの瞬間からかなりの数のコミットがあったとします。
git rebaseコマンドはトピックブランチからコミットを取得し、ブランチの最後のコミットに適用します
マスター：
- git-rebaseマスタートピック-何をどこで明示的に示すオプション
添付。
- git-rebase master-現在アクティブなマスターにスーパーインポーズされます
ブランチ。
コマンドを使用した後、ストーリーは線形になります。 発生時に
代替コミットとの競合
チームの作業が停止し、問題のある領域にファイルが表示されます
一致するタグ。 編集後-競合解決-ファイル
インデックスにgit addを追加し、次のオーバーレイを続行する必要があります
git rebase --continueコマンドでコミットします。 代替出力はコマンドになります
git rebase --skip（オーバーレイコミットをスキップして次のコミットに移動）またはgit
rebase --abort（コマンドと行われたすべての変更をキャンセルします）。
-iスイッチ（--interactive）を使用すると、コマンドは対話的に機能します
モード。 ユーザーには、アプリケーションの順序を決定する機会が与えられます
変更は自動的にエディターを呼び出して競合を解決します。
さらに。
2.2.5 git cherry- pick-別のコミットによる変更をプロジェクトツリーに適用する
複雑な開発履歴があり、いくつかの長いブランチがある場合
開発、それは行われた変更を適用する必要があるかもしれません
1つのブランチを別のツリー（現在アクティブ）への個別のコミットとして。
git cherry-pick BUG_FIX_TAG-指定されたコミットによる変更は
ツリーに適用され、自動的にインデックス付けされ、アクティブにコミットされます
ブランチ。
git cherry-pick BUG_FIX_TAG -n-キー「-n」は、変更が必要であることを示します
インデックスを作成してコミットを作成せずに、プロジェクトツリーに適用するだけです。
2.3その他のコマンドと必要な機能
gitでの作業の利便性のために、追加の概念が導入されました：タグ。 さらに
ハッシュの必要性とその適用についてさらに説明します。 示された方法
相対アドレス指定を使用してコミットにアクセスします。
2.3.1ハッシュ-一意のオブジェクト識別
gitでは、ユニークなもの（つまり
最も可能性の高い一意の）40文字のハッシュ。これは決定されます
オブジェクトの内容に基づいたハッシュ関数。 オブジェクトはすべてです：コミット、
ファイル、タグ、ツリー。 ハッシュは、たとえばファイルのコンテンツに対して一意であるため、
そのようなファイルの比較は非常に簡単です-2行を比較するだけです
40文字で。
私たちが最も興味を持っているのは、ハッシュがコミットを識別するという事実です。 これで
ハッシュはSubversionの高度なバージョンです。 いくつかの例
アドレス指定方法としてハッシュを使用する：
git diff f292ef5d2b2f6312bc45ae49c2dc14588eef8da2-現在の差を見つける
プロジェクトのステータスとその番号のコミット...
git diff f292ef5は同じですが、最初の6文字のみを残します。 Git
そのようなコミットが他にない場合、どのようなコミットが関与しているかを理解します
ハッシュの始まり。
git diff f292-時には4文字で十分です。
git log febc32 ... f292-コミットからコミットまでログを読み取ります。
もちろん、ハッシュを使用することは、マシンの場合ほど人にとって便利ではありません。そのため、
他のオブジェクトを導入-タグ。
2.3.2 gitタグ -一意のコミットをマークする方法としてのタグ
タグは、コミットに関連付けられたオブジェクトです。 コミット自体へのリンクの保存、名前
著者自身の名前とコメント。 さらに、開発者は
これらのタグに独自のデジタル署名を残します。
さらに、いわゆる「軽量タグ」（「軽量」
タグ "）、名前とコミットへのリンクのみで構成されます。 これらのタグは通常
履歴ツリーのナビゲーションを簡素化するために使用されます。 それらの作成は非常に簡単です。
git tag stable-1-最後に関連付けられた「軽量」タグを作成します
コミットします。 すでにタグがある場合、別のタグは作成されません。
git tag stable-2 f292ef5-特定のコミットをマークします。
git tag -d stable-2-タグを削除します。
git tag -l-タグをリストします。
git tag -f stable-1.1-最後のコミット用のタグを作成し、置き換えます
存在する場合。
タグを作成した後、コマンドでハッシュの代わりにその名前を使用できます
git diff、git logなど：
git diff stable-1.1 ... stable-1
通常のタグを使用して、
バージョン番号やコメントなどの情報。 言い換えれば、
「そのようなバグを修正した」コミットにコメントを書いてから、タグへのコメントに
「v1.0」という名前は、「安定したバージョン、すぐに使用できる」などです。
git tag -a stable-最後のコミット用に通常のタグを作成します; と呼ばれます
コメント用のテキストエディター。
git tag -a stable -m "production version"-すぐに指定して通常のタグを作成します
引数としてコメントします。
通常のタグのリスト、削除、書き換えコマンドは、
「軽量」タグのコマンド。
2.3.3相対アドレス指定
リビジョンとタグの代わりに、コミットの名前として別のものに依存できます
メカニズム-相対アドレス指定。 たとえば、先祖に直接行くことができます
マスターブランチの最後のコミット：
git diff master ^
「鳥」の後に数字を付けると、複数の先祖に対応できます
コミットのマージ：
git diff HEAD ^ 2-最後の2番目の祖先と比較して変更を見つける
マスターでコミットします。 ここのHEADは、アクティブなブランチの最後のコミットへのポインタです。
同様に、チルダは単にブランチの履歴の深さを示すことができます
ダイビングする必要があります：
git diff master ^^-現在のコミットの「祖父」がもたらしたもの。
git diff master〜2は同じです。
シンボルを組み合わせて、目的のコミットを取得できます。
git diff master〜3 ^〜2
git diff master〜6
2.3.4 .gitignoreファイル -無視するファイルをgitに説明する
時々、プロジェクトディレクトリに、常に保存したくないファイルが含まれている
概要のgit statusをご覧ください。 たとえば、補助テキストファイル
エディター、一時ファイル、その他のゴミ。
ルートまたはより深いツリーを作成することにより、gitステータスを無視できます
（制限が特定のディレクトリのみにある場合）ファイル
.gitignore。 これらのファイルでは、無視されるファイルのパターンを説明できます。
特定の形式。
そのようなファイルの内容の例：
>>>>>>>ファイルの開始
＃.gitignoreファイルにコメントする
＃.gitignore自体を無視
.gitignore
＃すべてのhtmlファイル...
* .html
＃...特定の例外を除く
！special.html
＃オブジェクトとアーカイブは必要ありません
*。[ao]
>>>>>>>>ファイルの終わり
無視できるファイルを指定する方法は他にもあります。
git help gitignore helpから。
3「共に力を発揮する」、またはリモートリポジトリでの作業の基本
当然、ほとんどのプロジェクトにはまだ作業が含まれています
コードを交換する必要がある少なくとも2人の開発者。 次は
連携するために必要なコマンドをリストします-おそらくリモート-。
3.1リモート追跡ブランチ
ここでの新しい概念は、リモートブランチです。 リモートブランチは
リモートサーバー上のブランチ（通常はマスター）。 そのようなものは、次の場合に自動的に作成されます
リモートリポジトリのコピーを作成します。 すべてのリモート関連コマンド
動作し、デフォルトでこの特定のリモートブランチを使用します（通常は
「オリジン」と呼ばれます）。
これらのコマンドを検討してください。
3.2 git clone- （リモート）リポジトリのコピーを作成する
中央リポジトリを使用するには、コピーを作成する必要があります
ローカルにすべての歴史を持つ元のプロジェクト：
git clone / home / username / project myrepo-同じマシンからリポジトリを複製します
myrepoディレクトリに移動します。
git clone ssh：// user @ somehost：port /〜user / repository-リポジトリを複製し、
安全なsshプロトコルを使用します（マシン上で取得する必要があります）
sshアカウント）。
git clone git：// user @ somehost：port /〜user / repository / project.git /-git has
および独自のプロトコル。
3.3 git fetchとgit pull- （リモートブランチから）中央リポジトリから変更をプルします
現在のブランチをリポジトリと同期するには、git fetchと
git pull。
git fetch-リモートブランチの変更をデフォルトリポジトリから取得します。
メインブランチ; クローン作成時に使用されたもの
リポジトリ。 変更により、リモート追跡ブランチが更新されます
git mergeコマンドでローカルブランチとマージするために必要なもの。
git fetch / home / username / project-特定の変更を選択します
リポジトリ。
git remoteコマンドで作成されたアドレスに同義語を使用することもできます。
git remote add username-project / home / username / project
git fetch username-project-定義されたアドレスで変更を取得します
と同義。
当然、たとえばgit diffコマンドを使用して、変更を評価した後、
メインでマージコミットを作成します。
git merge username-project / master
git pullコマンドはすぐに変更を取得し、アクティブなブランチとマージします。
git pull-リモートブランチが作成されたリポジトリから選択
デフォルトで。
git pull username-project-特定のリポジトリから変更を取得します。
原則として、git pullコマンドはすぐに使用されます。
3.4 git push-リモートリポジトリに変更を加えます（リモートブランチ）
実験ブランチで作業を実行した後、メインブランチとマージして、
リモートリポジトリ（リモートブランチ）を更新する必要があります。 このために
git pushコマンドが使用されます：
git push-作成されたリモートブランチに変更を送信します
デフォルトでクローニング。
git push ssh：//yourserver.com/~you/proj.git master：実験的-変更を送信
リモートリポジトリのmasterブランチからExperimentalブランチへ。
git push origin：Experimental-リモートオリジンリポジトリで、experimentalブランチを削除します。
git push origin master：master-オリジンリポジトリのリモートマスターブランチへ（同義語
デフォルトリポジトリ）ローカルマスターブランチのブランチ。
4 git-o-day
このセクションでは、いくつかの普通の
gitの状況で作業することは珍しくありません。
4.1ローカルリポジトリで作業するときの通常のワークフロー
Gitは、配布されているだけでなく、非常に使いやすい
バージョン管理システムだけでなく、ローカルプロジェクトでの作業にも。 見てみましょう
通常のループ-リポジトリの作成から開始-git developer work
自分の個人プロジェクト：
- mkdir git-demo
- cd git-demo
- git init
- git add。
- git commit -m "初期コミット"
- gitブランチの新機能
- git checkoutの新機能
- git add。
- git commit -m「新しい機能を完了しました」
- git checkout master
- git diff HEAD新機能
- git mergeの新機能
- git branch -d new-feature
- git log --since = "1 day"
各アクションを分析しましょう。1-2-
プロジェクトの作業ディレクトリを作成します。 3-ディレクトリにリポジトリを作成します。 4-すべての既存の
プロジェクトファイルのインデックスを作成します（もちろん、そうであった場合）。 5-初期化
コミットを作成します。 6-新しいブランチ、7-ブランチへの切り替え（
git checkout -b new-featureコマンドを使用すると、1ステップで実行できます）。さらに、
コードを直接操作した後、行われた変更のインデックスを作成し（8）、コミットします（9）。
メインブランチに切り替え（10）、アクティブブランチの
最後のコミットと実験的ブランチの最後のコミット（11）の違いを確認します。マージし（12）、
競合がなければ、不要になったブランチを削除します（13）。念のため
、最後の1日に実施した作業を評価します（14）。
なぜそうですか？なぜ線形モデルを放棄するのですか？
プログラマに柔軟性が追加されたという理由だけで、
タスク（ブランチ）を切り替えることができる場合。常に手元にあるのは「純粋な」
マスターブランチです。コミットはより小さく、より正確になります。
4.2リモートリポジトリで作業するときのワークフロー
あなたとあなたのパートナーのいくつかが
、共通のプロジェクトを引き受けるために公開リポジトリを作成したと仮定します。
gitの最も一般的な作業モデルはどのようなものですか？
- git clone http://yourserver.com/~you/proj.git
...しばらく時間が経ったかもしれません。
- git pull
- git diff HEAD ^
- git checkout -b bad-feature
...しばらく動作しています。
- git commit -a -m「悪い機能を作成しました」
- git checkout master
- git pull
- git merge bad-feature
- git commit -a
- git diff HEAD^
… , , - . おっと
- git reset --hard ORIG_HEAD
- git checkout bad-feature
… .
- git -m bad-feature good-feature
- git commit -a -m «Better feature»
- git checkout master
- git pull
- git merge good-feature
- git push
- git branch -d good-feature
そのため、まず最初にcreate（1）リモートリポジトリのコピーを作成します（
デフォルトでは、git pullやgit pushなどのコマンドが機能します）。
最新の更新を「プル」する（2）。何が変わったのかを見る（3）;新しいブランチを作成して、
それに切り替えます（4）。すべての変更にインデックスを付け、同時にそれらから
コミットを作成します（5）。メインブランチに切り替え（6）、更新します（7）。実施
（8）分岐悪い-機能との合併をし、紛争を発見し、解決するために、我々は、コミット行う
合併（9）。
コミット後、変更を追跡し（10）、たとえば
単体テストを実行し、マージ後にプロジェクトがほとんど
のテストに該当することを恐怖で見つけます。
原則として、テストはコミットの前に、
マージの時点で実行できます（ポイント8と9の間）。「ソフト」カットで十分です。
したがって、発生したマージを「ハード」（11）リセットする必要があり、
ブランチは元の状態に戻りました。次に、失敗した
ブランチに切り替え（12）、必要な変更を加えて、ブランチの名前を変更します（13）。コミット
（14）をコミット。メインブランチに移動し（15）、再度更新します（16）。今回
はシームレスにマージし（17）、リモートリポジトリに変更をドロップし
（18）、不要になったブランチを削除します（19）。私たちはラップトップを閉じ、服を着
て、朝に帰宅します。
5結論
このトピックでは、
パブリックリポジトリの管理、テキストエディターまたはIDEとの統合、
LinuxおよびWindowsでのSSHの使用など、いくつかの重要な問題に対処していません。コメント、特に
git-o-dayセクションへの追加を歓迎します。
UPD：リモートリポジトリの操作に関する注意。管理、パブリックリポジトリの作成、アクセス制御、暗号化された接続の使用などでgitを使用する場合、特定の質問が発生する可能性があります。さらに、このノートでは、それらはいかなる方法でもカバーされていません。たとえば、既製のリモートリポジトリの操作については上記で説明しています。その展開は、いかなる方法でもカバーされていません。
これらすべてを今、別のトピックで収集しています。これを1週間半でここに投げます。