はじめに支店
バージョン管理システムの多くのコピーがサポート枝の形で、枝には、例えば、あなたが行う、プロジェクトに類似している
プロジェクトのコードがよく書かれている、そして今、新たな機能を必要とする、あなたは非常に書かれたにすることはできません良いプロジェクト
の変更を加えるが、書き込みコードにプロジェクト全体をコピーする必要があり、かつ分岐が、この実現することにある
機能を、ブランチの名前は。名前からコピーしたコードの多くで
利用枝は、上記の開発作業のメインラインから分離することができます開発のメインラインの影響を避ける。する
が、多くの分岐バージョン管理システムは非効率的である、彼らは完全にソースコードディレクトリのコピーを作成している
、大規模なプロジェクトのために、これは時間の無駄である、とGitのブランチでは非常に効率的な分岐モデルがありますGitは明るいスポットです。
支店の場所
以下れるディレクトリのGit、ことを想起
二のブランチに関連しているが、分岐が提出されたオブジェクトのハッシュ値へのポインタの変数の名前と実際類似しており、メインブランチは、例えば以下のため、デフォルトのマスターでありますイメージは、
現在のHEADブランチがされているものであるGitのディレクトリに保存
各ブランチのオブジェクト提出し、最終的な提出のレフリーハッシュ値内に保存します
枝を使用
-
ブランチの作成：gitのブランチブランチ名が
新しいポインタを作成することが移動し、そしてもちろん、このポインタが現在存在するオブジェクトに提出され、これは、ブランチであることができ
、あなたが見つけることであるが、ポインタ、HEADポイント、またはマスター、いないの作成これは、自動的に新しいブランチに切り替わります
-
枝の切り替え：
| gitのチェックアウト支店名 | スイッチングブランチ |
| gitのチェックアウト | パラメータはありません何、それはブランチのリストを表示することですでした |
| gitのチェックアウト-b支店名 | 前の手順は、我々はトラブルのため、このコマンドが実行され、新しいブランチを作成し、切り替える必要があり、新しいブランチとは切り替え |
支店は、ノートにポイントを切り替える：
①：分岐が3ヶ所に変更されます切り替え：ステージング領域、HEADを、作業ディレクトリ
切り替えるにはHEADブランチ名の変更
ステージング領域は、スイッチの枝のように、最終的なステージング領域の外観になり
作業ディレクトリの変更枝の最終バージョンを切り替えることが
あるため、現在のブランチの状態が提出されることを保証するために枝を切り替えがされた上記の理由から、のように
すべてのgitの状態の実装で表示状態に提出されました。
3本の遷移枝から、ここで述べました状況：
①：ファイルの新しいブランチ上で何が、あなたがそれを追跡していない、の痕跡が存在しない場合には
別のブランチにメインラインまたはスイッチにスイッチバックが、その後、新しいファイルには、メインラインに行くに追跡されますか
他の支店実は、この文書では、コードのメインラインの汚染につながるメインラインや他の支店、に属していない
か、他のブランチ。そして、あなたがそれに従わなかったため、この新しいファイルには、なぜ、あなたはメインラインまたはそれの他の支店に行く従いますそれは、ブランチを切り替えて、作業ディレクトリは、それを削除しないであろう、経営のgitの範囲ではありません
②：あなたは新しいトラックを持っていること 建設文書は、しかし、提出しなかったし、枝を切り替える。すでに確かにステージングエリアになります追跡、
新しい枝がまた新しいブランチにもたらされるだろうステージング領域のファイルに切り替え、作業ディレクトリ新しいファイルは新しいにもたらされるだろう
。新しいブランチを汚染するブランチ、
③：既に書類を提出され、アップグレードになりましスイッチ分岐したかった、あなたが追跡し、提出する必要はありません変更されたファイルを変更する必要が
gitのよう変更前のファイルが前にこのブランチに提出されているので、あなたのスイッチを提供するつもりされていない場合、あなたは切り替え前にコミットできるようにする必要がありますように、私たちはあなたへの切り替えを余儀なくされていないので、改訂された文書は、変更後のこのブランチに属している必要があります考慮するGIT 。
- 削除ブランチ（あなた自身を削除することはできません、別のディレクトリに切り替える必要があり）
| git branch -d 分支名 | 这个是删除已经合并的分支,如果分支没有合并,删除就会报错 |
| git branch -D 分支名 | 这个是强制删除分支,没有合并的分支也可以删除掉 |
| git log --oneline --decorate --graph --all | 这个是可以看整个项目得完整历史,因为切换到主线上,很多主线后面的分支的提交看不了,这个代码就可以看了 |
- 其他
| git branch -v | 以查看每一个分支的最后一次提交 |
| git branch 分支名 提交对象的hash值 | 新建一个分支并且使分支指向对应的提交对象 ,利用这个可以实现版本的回退,比如你的提交对象的hash值是第一个版本的,那么就回退到第一个版本 |
| git config --global alias.别名 “命令” | 这个是当git的命令很长的时候,我们可以给他配一个别名,注意:alias.后面直接加别名,不能空格,后面的命令是写git后面的命令,不用加git,命令要用""括起来,例如:git config --global alias.st status,配置后直接敲git st 和git status一样 |
| git reflog | 就是在版本库里面看所有的提交,包括删除的 |
- 一个使用例子
现在是主分支上面已经有两个稳定的代码就是Jane1.txt和jane2.txt,现在主分支
master指向jane2.txt,
然后你需要修改一个bug,所以创建了一个jing1的分支,在jing1分支上面打了代码jing1.txt和jing.txt,如下图:
然后现在你需要立即解决另外一个bug,所以你需要返回到主分支上面
再新建一个分支urgent,在里面打了jane3.txt和修改了jane1.txt,将这个紧急bug
修改好后测试没问题,应该合并到主分支上,如下图
这里因为urgent和master是在同一条线上的,就是master分支要合并的分支是在master的前面,这样子git就会简单地将HEAD指针向前移动,指向urgent最后的提交对象上面,这样合并不需要处理分歧,也叫做快进
现在处理完了urgent的问题,又回到jing1分支继续写代码,修改了jane1.txt的代码
完成后你又要将jing1分支和master合并,
这时合并就出现了问题了,因为jing1的jane1.txt代码在urgent分支修改过,在jing1分支也修改过,合并的时候就会出现分歧,
而且对于合并过urgent分支的master主分支来说,jing1分支就是过时的,因为master
已经升级过了,
这时jing1和master合并也叫典型合并,需要处理冲突,合并后会提示需要处理的
是哪一个文件代码,你对它进行修改,add,commit后就可以了
上面的逻辑代码如下:
镜风@▒龵 MINGW64 /g/git/workspace/1 (master)
$ git log --oneline --decorate --graph --all
* b238c63 (jing1) jing1.txt comitt for jing1
* a2e2d45 (HEAD -> master) jane2
* 7942d53 jane1
镜风@▒龵 MINGW64 /g/git/workspace/1 (master)
$ git checkout jing1
Switched to branch 'jing1'
镜风@▒龵 MINGW64 /g/git/workspace/1 (jing1)
$ git ls-files -s
100644 eeaa10d7dbd999222fb0557b3b8d7c1bd2c465d4 0 jane1.txt
100644 32b22f6bd6e40627e9502847ec7cf36a3bc87420 0 jane2.txt
100644 d82550eebd096160ee791e84cc4053c6214bf183 0 jing1.txt
镜风@▒龵 MINGW64 /g/git/workspace/1 (jing1)
$ git checkout master
Switched to branch 'master'
镜风@▒龵 MINGW64 /g/git/workspace/1 (master)
$ git checkout -b urgent
Switched to a new branch 'urgent'
镜风@▒龵 MINGW64 /g/git/workspace/1 (urgent)
$ git ls-files -s
100644 eeaa10d7dbd999222fb0557b3b8d7c1bd2c465d4 0 jane1.txt
100644 32b22f6bd6e40627e9502847ec7cf36a3bc87420 0 jane2.txt
镜风@▒龵 MINGW64 /g/git/workspace/1 (urgent)
$ vim jane1.txt
镜风@▒龵 MINGW64 /g/git/workspace/1 (urgent)
$ echo "jane3.txt" > jane3.txt
镜风@▒龵 MINGW64 /g/git/workspace/1 (urgent)
$ git add ./
warning: LF will be replaced by CRLF in jane1.txt.
The file will have its original line endings in your working directory
warning: LF will be replaced by CRLF in jane3.txt.
The file will have its original line endings in your working directory
镜风@▒龵 MINGW64 /g/git/workspace/1 (urgent)
$ git commit -m "jane1.txt的修改和jane3.txt增加 to urgent"
[urgent 114582a] jane1.txt的修改和jane3.txt增加 to urgent
2 files changed, 2 insertions(+)
create mode 100644 jane3.txt
镜风@▒龵 MINGW64 /g/git/workspace/1 (urgent)
$ git checkout master
Switched to branch 'master'
镜风@▒龵 MINGW64 /g/git/workspace/1 (master)
$ git merge urgent
Updating a2e2d45..114582a
Fast-forward
jane1.txt | 1 +
jane3.txt | 1 +
2 files changed, 2 insertions(+)
create mode 100644 jane3.txt
镜风@▒龵 MINGW64 /g/git/workspace/1 (master)
$ git checkout jing1
Switched to branch 'jing1'
镜风@▒龵 MINGW64 /g/git/workspace/1 (jing1)
$ ll
total 4
-rw-r--r-- 1 镜风 197121 7 3月 2 21:35 jane1.txt
-rw-r--r-- 1 镜风 197121 6 3月 2 14:04 jane2.txt
-rw-r--r-- 1 镜风 197121 30 3月 2 21:35 jing.txt
-rw-r--r-- 1 镜风 197121 8 3月 2 21:35 jing1.txt
镜风@▒龵 MINGW64 /g/git/workspace/1 (jing1)
$ vim jane1.txt
镜风@▒龵 MINGW64 /g/git/workspace/1 (jing1)
$ git commit -a -m "修改了jane1.txt to jing1分支"
[jing1 be620f2] 修改了jane1.txt to jing1分支
1 file changed, 1 insertion(+)
镜风@▒龵 MINGW64 /g/git/workspace/1 (jing1)
$ git checkout master
Switched to branch 'master'
镜风@▒龵 MINGW64 /g/git/workspace/1 (master)
$ git merge jing1
Auto-merging jane1.txt
CONFLICT (content): Merge conflict in jane1.txt
Automatic merge failed; fix conflicts and then commit the result.
镜风@▒龵 MINGW64 /g/git/workspace/1 (master|MERGING)
$ vim jane1.txt
镜风@▒龵 MINGW64 /g/git/workspace/1 (master|MERGING)
$ git add ./
镜风@▒龵 MINGW64 /g/git/workspace/1 (master|MERGING)
$ git status
On branch master
All conflicts fixed but you are still merging.
(use "git commit" to conclude merge)
Changes to be committed:
modified: jane1.txt
new file: jing.txt
new file: jing1.txt
镜风@▒龵 MINGW64 /g/git/workspace/1 (master|MERGING)
$ git commit -m "master合并jing1"
[master 37ea712] master合并jing1
镜风@▒龵 MINGW64 /g/git/workspace/1 (master)
$ git log --oneline --decorate --graph --all
* 37ea712 (HEAD -> master) master合并jing1
|\
| * be620f2 (jing1) 修改了jane1.txt to jing1分支
| * 22c6705 jing.txt的修改 to jing1
| * 83c7ef7 commit for jing.txt to jing1
| * b238c63 jing1.txt comitt for jing1
* | 114582a (urgent) jane1.txt的修改和jane3.txt增加 to urgent
|/
* a2e2d45 jane2
* 7942d53 jane1
典型合并后需要修改的代码的样子
分支模式
一般的に長い枝と枝の特性に分け
絵の上には非常に明確である、最上位の母校は、会社全体を組み合わせ、安定したコードである
枝を開発することをすべてのプログラマ自身のコードではなく、直接変更時の上記の枝を開発するが、変更、追加のブランチを作成していきMODIFY
masterブランチを、ここで枝を開発し、長期的な分岐が比較的安定しているされている
すべてのプログラマを分岐するトピックブランチを、以下のトピックブランチを作成した機能やバグです
自然の枝
実際には、枝先にgitのフォルダを導入されたオブジェクト、変数へのポインタコミットされた
枝の保存されたフォルダ、参考文献内で、
このように3つの分岐を保存することで、ここでは各ブランチはファイルであり、保存されている
最終的なオブジェクトを提出するために、各ブランチのためのハッシュ値を
ディレクトリに、現在のブランチHEADに保存されているHEADファイル、あるポイント
たびに新しいコミットオブジェクト提出したときに、HEADが前方に移動します枝を指し示しながら、変更されますHREAD
