Gitでの毎日の仕事

私はgitの勉匷ず䜿甚をほずんどどこでも行っおいたせん。 しかし、この間に私は倚くのこずを孊ぶこずができ、私の経隓をコミュニティず共有したいず思いたす。

䞻なアむデアを䌝え、このVCSがプロゞェクトの開発にどのように圹立぀かを瀺したす。 読んだ埌に質問に答えられるこずを願っおいたす


もちろん、基本から始めお、すべおを順番に話そうずしたす。 したがっお、この蚘事は、Gitを始めたばかりの人やGitを䜿いたい人にずっお非垞に圹立ちたす。 より経隓豊富な読者は、自分自身で䜕か新しいものを芋぀けたり、゚ラヌを指摘したり、アドバむスを共有したりするかもしれたせん。



蚈画の代わりに


非垞に頻繁に、䜕かを始めるために、私はたくさんの資料を勉匷したすが、これらは異なる人、異なる䌚瀟、異なるアプロヌチです。 これはすべお、䜕かが私に適しおいるかどうかを分析し理解するのに倚くの時間を必芁ずしたすか 埌に、普遍的な解決策がないこずを理解するこずになるず、バヌゞョン管理システムず開発のためにたったく異なる芁件が生じたす。

したがっお、䞻な手順を匷調したす。


環境



動䜜するには、次のものが必芁です。
  1. Git
  2. コン゜ヌル
  3. 奜きな軞の䞋にすべおを眮く方法を知っおいるモニタヌの反察偎の男

珟圚の環境はDebian + KDE + Git + Bash + GitK + KDiff3です。
コンピュヌタヌにWindowsが芋぀かった堎合、Windows + msysgitgit-bash+ TortoiseGitなどがむンストヌルされおいる可胜性が高いでしょう。

コン゜ヌルを開く堎合、 gitを蚘述しおこれを取埗したす。
gitヘルプ
 usage: git [--version] [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path] [-p|--paginate|--no-pager] [--no-replace-objects] [--bare] [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>] [-c name=value] [--help] <command> [<args>] The most commonly used git commands are: add Add file contents to the index bisect Find by binary search the change that introduced a bug branch List, create, or delete branches checkout Checkout a branch or paths to the working tree clone Clone a repository into a new directory commit Record changes to the repository diff Show changes between commits, commit and working tree, etc fetch Download objects and refs from another repository grep Print lines matching a pattern init Create an empty git repository or reinitialize an existing one log Show commit logs merge Join two or more development histories together mv Move or rename a file, a directory, or a symlink pull Fetch from and merge with another repository or a local branch push Update remote refs along with associated objects rebase Forward-port local commits to the updated upstream head reset Reset current HEAD to the specified state rm Remove files from the working tree and from the index show Show various types of objects status Show the working tree status tag Create, list, delete or verify a tag object signed with GPG See 'git help <command>' for more information on a specific command. 


これで準備完了です。

実隓するこずを恐れないでください



確かに、ほずんどのチヌムはすでにどこかで発芋されおおり、いく぀かの蚘事は読たれおいるので、始めたいず思っおいたすが、間違ったチヌムに参加したり、䜕かを壊すこずを恐れおいたす。 たたは、䜕も研究されおいないかもしれたせん。 次に、これを芚えおおいおください
あなたは䜕でもでき、どんなコマンドでも実行でき、実隓を蚭定し、削陀、倉曎できたす。 䞻なこずはgit pushをしないこずです。
このコマンドのみが、倉曎を別のリポゞトリに転送したす。 この方法でのみ、䜕かを壊すこずができたす。

厳密に蚀えば、倱敗したgit pushも修正できたす。

したがっお、リポゞトリを安党に耇補しお孊習を開始できたす。

リポゞトリの構築



たず、gitリポゞトリずは䜕かを理解する必芁がありたすか 答えは非垞に簡単です。ファむルのコレクションです。 `.git`フォルダヌ。 これは単なるファむルのコレクションであり、それ以䞊のものではないこずを理解するこずが重芁です。 箄20回、私はgithub / gitlabでの承認に関する同僚の問題を芋たした。 これがgitシステムの䞀郚であるず考えお、圌らはgit構成の問題を探しお、いく぀かのgitコマンドを呌び出したした。

そしお、これらが単なるファむルである堎合、䜕らかの方法でそれらにアクセスし、そこから読み取り、そこに曞き蟌むこずができる必芁がありたすか はい 私はそれを「トランスポヌト」ず呌びたす。 これは間違っおいるかもしれたせんが、芚えおおくずずおも䟿利でした。 より正しいオプション「デヌタ転送プロトコル」。 最も䞀般的なオプションは次のずおりです。
  1. ファむル-リポゞトリファむルに盎接アクセスできたす。
  2. SSH-sshを介しおサヌバヌ䞊のファむルにアクセスできたす。
  3. HTTPS-送受信ずしおhttpを䜿甚したす。

さらに倚くのオプションがありたす。 どのトランスポヌトが䜿甚されるかは関係ありたせん。ファむルぞの読み取りアクセスたたは読み取り/曞き蟌みアクセスがあるこずが重芁です。
したがっお、githubを䜿甚しおリポゞトリを耇補できず、ログにヒントがない堎合、トランスポヌトの問題が発生しおいる可胜性がありたす。

特に、このようなクロヌンを䜜成する堎合
 git clone git@github.com:user/repo.git 

URLは「に倉わる」
 git clone ssh://git@github.com:user/repo.git 

぀たり SSHが䜿甚されおいるため、問題を探す必芁がありたす。 原則ずしお、これは正しく蚭定されおいないか、芋぀からないsshキヌです。 「SSH Auth Key git」の方向にグヌグルで怜玢する必芁がありたす。完党に倧人の堎合は、䜕が起こるかを確認しおください。
 ssh -vvv git@github.com 


ヘルプでサポヌトされおいるプロトコルGIT URLSセクション
 git clone --help 


リポゞトリはクロヌン化できたすが、最初に、私たち自身で遊んでみたしょう
  1. 独自のリモヌトリポゞトリを発明したす
  2. 開発者dev1ずdev2に代わっお、そこから2぀のクロヌンを䜜成したしょう



リポゞトリ自䜓に加えお、 䜜業するファむルが保存されるワヌクスペヌスもありたす 。 リポゞトリ自䜓.gitフォルダヌが存圚するのは、このフォルダヌです。 サヌバヌに䜜業ファむルは必芁ないため、裞のリポゞトリのみがそこに保存されたす。

1぀䜜成したしょうこれがメむンのテストリポゞトリになりたす。
 $ mkdir git-habr # ,    $ cd git-habr $ git init --bare origin Initialized empty Git repository in /home/sirex/proj/git-habr/origin/ 


次に、開発者に代わっおクロヌンを䜜成したす。 サヌバヌでの䜜業䞭に存圚しない譊告が1぀だけありたす。リポゞトリがロヌカルで同じパヌティションにあるこずを認識するgitは、リンクを䜜成し、完党なコピヌを䜜成したせん。 たた、調査には完党なコピヌが必芁です。 これを行うには、 --no-hardlinks䜿甚するか、プロトコルを明瀺的に指定したす。
 $ git clone --no-hardlinks origin dev1 Cloning into 'dev1'... warning: You appear to have cloned an empty repository. done. $ git clone --no-hardlinks origin dev2 Cloning into 'dev2'... warning: You appear to have cloned an empty repository. done. 


結論3぀のリポゞトリがありたす。 そこには䜕もありたせんが、圌らは準備ができおいたす。

GITスタヌト




スキャンダル 陰謀 調査


リストをさらに続けるこずができたすが、これはすでに自然な質問をするのに十分です
どのように機胜したすか
このすべおをどのように理解し、蚘憶するこずができたすか


これを行うには、ボンネットの䞋を芋おください。 䞀般的な甚語ですべおを考慮しおください。

ギット。 ほがボンネットの䞋

Gitは、コミットするすべおのファむルの内容を保存したす各ファむルの内容をキャストし、オブゞェクトに保存したす。 ファむルが倉曎されおいない堎合、叀いオブゞェクトが䜿甚されたす。 したがっお、 倉曎されたファむルのみが新しいオブゞェクトの圢でコミットに分類されたす。これにより、倚くのディスク容量が節玄され、任意のコミットにすばやく切り替えるこずができたす。

これにより、これらの面癜いこずがここで機胜する理由を理解できたす。
 $ git init /tmp/test Initialized empty Git repository in /tmp/test/.git/ $ cd /tmp/test $ cp ~/debian.iso . # iso  168  $ du -sh .git #   .git 92K .git $ git add debian.iso $ git commit -m "Added iso" [master (root-commit) 0fcc821] added iso 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 debian.iso $ du -sh .git #  163M .git # .      (   ) $ cp debian.iso debian2.iso $ cp debian.iso debian3.iso $ git add debian2.iso debian3.iso $ git commit -m "Copied iso" [master f700ab5] copied iso 2 files changed, 0 insertions(+), 0 deletions(-) create mode 100644 debian2.iso create mode 100644 debian3.iso $ du -sh .git #  163M .git #   .     ,     . 


はい、明癜な必芁なしに「重い」ファむル、バむナリなどを保存するべきではありたせん。 それらは氞久にそこに残り、リポゞトリのすべおのクロヌンに存圚したす。

各コミットには、耇数の祖先コミットず耇数の子コミットを含めるこずができたす。


このツリヌ、たたはグラフの任意のポむントに移動状態を埩元できたす。 これを行うには、git checkoutを䜿甚したす。
 git checkout <commit> 

2぀以䞊のコミットを1぀にマヌゞするこずは、マヌゞ2぀以䞊の倉曎セットを結合するです。
各分岐は、いく぀かのバリ゚ヌションの倖芳です。

ちなみに、ファむル/フォルダ、プロゞェクトの䞀郚などにタグを䜜成するこずは䞍可胜であるこずに泚意しおください。 条件は完党にのみ埩元されたす。 したがっお、Project1、Project2などを远加せずに、プロゞェクトを別のリポゞトリに保管するこずをお勧めしたす。 ただ根に。


さお、枝ぞ。 䞊に曞いた
Gitにはブランチがありたせん* 小さな泚意事項がありたす

グラフを圢成する倚くのコミットがありたす。 芪コミットから任意の子コミットぞのパスを遞択し、このコミットのプロゞェクトの状態を取埗したす。 「蚘憶」をコミットするには、それぞの名前付きポむンタヌを䜜成できたす。
このような名前付きポむンタヌはブランチです。 タグも同様です。 `HEAD`は同じ原理で動䜜したす-珟圚の䜍眮を瀺したす。 新しいコミットは、珟圚のブランチの継続ですHEADが芋る堎所ず同じです。

ポむンタヌは、タグでない堎合、任意のコミットに自由に移動できたす。 この目的のために、タグはコミットを䞀床だけ蚘憶し、どこにも移動しないようにしたす。 ただし、削陀するこずはできたす。
おそらく、gitで䜜業するずきに初めお理論から知る必芁があるのはこれだけでしょう。 これで、残りの郚分はより理解しやすくなるはずです。

甚語

むンデックス -蚘録された倉曎の領域、぀たり リポゞトリに保存するために準備したすべおのもの。
commit-リポゞトリに送信された倉曎。
HEADは、珟圚のコミットぞのポむンタです。
master-デフォルトのブランチ名。これは特定のコミットぞのポむンタでもありたす
origin-デフォルトでのリモヌトリポゞトリの名前別のものを指定できたす
チェックアりト -リポゞトリから状態を取埗したす。

簡単な線集

垞にあなたの指先にあるべき2぀のこずがありたす
  1. git status
  2. gitk


あなたが䜕か間違ったこずをした、混乱した、䜕が起こっおいるのかわからない-これらの2぀のチヌムがあなたを助けたす。

git statusリポゞトリ䜜業コピヌのステヌタスず珟圚の堎所を衚瀺したす。
gitkは、グラフを衚瀺するグラフィカルナヌティリティです。 キヌずしお、ブランチの名前たたは--allを枡しおすべおを衚瀺したす。

先ほど䜜成したリポゞトリに戻りたしょう。 さらに、1人の開発者がdev1 $で䜜業し、2人目の開発者がdev2 $で䜜業するこずをマヌクしたす。

README.mdを远加したす。
 dev1$ vim README.md dev1$ git add README.md dev1$ git commit -m "Init Project" [master (root-commit) e30cde5] Init Project 1 file changed, 4 insertions(+) create mode 100644 README.md dev1$ git status # On branch master nothing to commit (working directory clean) 


みんなず共有したす。 しかし、空のリポゞトリを耇補したため、デフォルトではgitはコミットを远加する堎所を知りたせん。
圌はこれを教えおくれたす
 dev1$ git push origin No refs in common and none specified; doing nothing. Perhaps you should specify a branch such as 'master'. fatal: The remote end hung up unexpectedly error: failed to push some refs to '/home/sirex/proj/git-habr/origin' dev1$ git push origin master Counting objects: 3, done. Writing objects: 100% (3/3), 239 bytes, done. Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. To /home/sirex/proj/git-habr/origin * [new branch] master -> master 


2番目の開発者は、プルを実行するこずでこれらの倉曎を取埗できたす。
 dev2$ git pull remote: Counting objects: 3, done. remote: Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. From /home/sirex/proj/git-habr/origin * [new branch] master -> origin/master 


さらにいく぀かの倉曎を远加したす。
 dev1(master)$ vim README.md dev1(master)$ git commit -m "Change 1" -a dev1(master)$ vim README.md dev1(master)$ git commit -m "Change 2" -a dev1(master)$ vim README.md dev1(master)$ git commit -m "Change 3" -a 


䜕をしたのか芋おみたしょうgitkを実行
非衚瀺のテキスト

最初のコミットをハむラむトしたした。 䞋から䞊に順番に移動するず、リポゞトリがどのように倉化したかを確認できたす。
 @@ -2,3 +2,4 @@ My New Project -------------- Let's start +Some changes 

 @@ -3,3 +3,5 @@ My New Project Let's start Some changes +Some change 2 + 

 @@ -2,6 +2,5 @@ My New Project -------------- Let's start -Some changes -Some change 2 +Some change 3 



これたで、コミットを最埌に远加したした マスタヌは 。 ただし、README.mdの別のバヌゞョンを远加できたす。 そしお、どこからでもできたす。 たずえば、最埌のコミットが気に入らず、別のオプションを詊しおいたす。 前のポむントでブランチポむンタヌを䜜成したす。 これを行うには、git logたたはgitkを通じおコミットIDを孊習したす。 次に、ブランチを䜜成しお切り替えたす
 dev1(master)$ git branch <branch_name> <commit_id> #    git branch <branch_name> HEAD~1 #     dev1(master)$ git checkout <branch_name> 


GUIが奜きな人には、さらに簡単なオプションがありたす。右マりスボタンで正しいコミットを遞択-> "新しいブランチを䜜成"。
衚瀺されるブランチをクリックするず、このブランチアむテムがチェックアりトされたす。 ブランチに「v2」ずいう名前を付けたした。
テストを倉曎したしょう
 dev1(v2)$ vim README.md dev1(v2)$ git commit -m "Ugly changes" -a [v2 75607a1] Ugly changes 1 file changed, 1 insertion(+), 1 deletion(-) 

次のようになりたす。


これで、どこからでもブランチが䜜成される方法ず、その履歎がどのように倉化するかがわかりたした。

高速巻き戻し

確かに、あなたはすでにfast-forward 、 rebase 、 merge mergeずいう蚀葉に出䌚っおいたす。 これらの抂念に察凊する時が来たした。 私はリベヌスを䜿甚したすが、誰かがマヌゞするだけです。 リベヌスずマヌゞのテヌマはたくさんありたす。 著者はしばしば、自分の方法がより良く、より䟿利であるず玍埗させようずしたす。 私たちは逆に行きたすそれが䜕であり、どのように機胜するかを理解したす。 その埌、どのオプションをどのケヌスで䜿甚するかがすぐに明らかになりたす。

これたでのずころ、1぀のリポゞトリの制限内で、ブランチを䜜成したす。ファむルを䜜成し、リポゞトリに配眮し、新しいポむントからファむルの2぀のバリアントを䜜成し、すべおをマスタヌに結合しようずしたす。
 dev1(v2)$ git checkout master Switched to branch 'master' Your branch is ahead of 'origin/master' by 3 commits. # ,      master   origin 

次の内容でcollider.init.shファむルを䜜成したす。
 #!/bin/sh USER=collider case $1 in *) echo Uknown Action: $1 ;; esac 


新しいブランチで開発を远加、コミット、開始したす。
 dev1(master)$ git add collider.init.sh dev1(master)$ git commit -m "Added collider init script" [master 0c3aa28] Added collider init script 1 file changed, 11 insertions(+) create mode 100755 collider.init.sh dev1(master)$ git checkout -b collider/start #   Switched to a new branch 'collider/start' dev1(collider/start)$ git checkout -b collider/terminate #   Switched to a new branch 'collider/terminate' 

git checkout -b <branch_name>は、珟圚䜍眮ぞのポむンタヌbranch<branch_name>を䜜成し珟圚䜍眮は特別なHEADポむンタヌを䜿甚しお远跡されたす、それに切り替えたす。
たたは単に珟圚の堎所から新しいブランチを䜜成し、すぐにそれを続行したす。

ブランチ名に「/」文字を䜿甚するこずは犁じられおいないこずに泚意しおください。ただし、泚意が必芁です。 「/」たでの名前のフォルダがファむルシステムに䜜成されたす。 フォルダヌず同じ名前のブランチが存圚する堎合、ファむルシステムレベルで競合が発生したす。 devブランチがすでにある堎合、 dev / testを䜜成できたせん。
たた、 dev / testがあれば 、 dev / whateverを䜜成できたすが、 devだけではできたせん。

そのため、2぀のブランチcollider / startずcollider / terminateを䜜成したした。 混乱した gitk-救助にすべお 

ご芧のずおり、ある時点で3぀のポむンタヌブランチがあり、コミットの倉曎は次のずおりです。
 @@ -0,0 +1,11 @@ +#!/bin/sh + + +USER=collider + + +case $1 in + *) + echo Uknown Action: $1 + ;; +esac 

次に、各ブランチで、コラむダヌを起動および砎棄するコヌドを蚘述したす。 アクションのシヌケンスはおよそ次のずおりです。
 dev1(collider/start)$ vim collider.init.sh dev1(collider/start)$ git commit -m "Added Collider Start Function" -a [collider/start d229fa9] Added Collider Start Function 1 file changed, 9 insertions(+) dev1(collider/start)$ git checkout collider/terminate Switched to branch 'collider/terminate' dev1(collider/terminate)$ vim collider.init.sh dev1(collider/terminate)$ git commit -m "Added Collider Terminate Function" -a [collider/terminate 4ea02f5] Added Collider Terminate Function 1 file changed, 9 insertions(+) 

行われた倉曎
コラむダヌ/スタヌト
 @@ -3,8 +3,17 @@ USER=collider +do_start(){ + echo -n "Starting collider..." + sleep 1s + echo "ok" + echo "The answer is 42. Please, come back again after 1 billion years." +} case $1 in + start) + do_start + ;; *) echo Uknown Action: $1 ;; 


コラむダヌ/終了

 @@ -3,8 +3,17 @@ USER=collider +do_terminate() { + echo -n "Safely terminating collider..." + sleep 1s + echo "oops :(" + +} case $1 in + terminate) + do_terminate + ;; *) echo Uknown Action: $1 ;; 



い぀ものように、 gitkで確認しおみたしょう。


開発が完了し、すべおの倉曎をマスタヌに䞎える必芁がありたす䜕もできない叀いコラむダヌがありたす。 䞊蚘のように、2぀のコミットをマヌゞするこずはmergeです。 しかし、 マスタヌブランチがコラむダヌ/スタヌトずどのように異なるのか、そしおそれらの結合合蚈を取埗する方法に぀いお考えたしょうか たずえば、これらのブランチの䞀般的なコミットを取埗し 、 masterのみに関連するコミットを远加しおから、 collider / startのみに関連するコミットを远加できたす。 私たちはどうですか 䞀般的なコミットがあり、 マスタヌコミットのみ-いいえ、 コラむダヌ/スタヌトのみ-がありたす。 ぀たり これらのブランチをマヌゞするには、 master + collider / startからコミットしたす。 しかし、 コラむダヌ/スタヌトはマスタヌ + コラむダヌ/コミットのコミットです 同じこず ぀たり 䜕もしない ブランチのマヌゞ-これはコラむダヌ/スタヌトです
繰り返したすが、文字のみで、理解しやすくなるこずを願っおいたす。
マスタヌ= C1 + C2 + C3
コラむダヌ/スタヌト=マスタヌ+ C4 = C1 + C2 + C3 + C4
master + collider / start = General_commitmaster、collider / start+ Only_ymaster+ Only_ycollider / start=C1 + C2 + C3+NULL+C4= C1 + C2 + C3 + C4

あるブランチが別のブランチに「暪たわっおいる」堎合、すでに別のブランチに入るようになっおおり、マヌゞの結果は2番目のブランチになりたす。 叀いコミットから新しいコミットに履歎を巻き戻すだけです。 この巻き戻し䜕もする必芁のない結合は、早送りず呌ばれたす。
なぜ早送りが良いのですか
  1. マヌゞするずき、䜕もする必芁はありたせん
  2. さらに、自動関連付けが保蚌されたす
  3. 競合は䞍可胜であり、決しお発生したせん
  4. ストヌリヌは関連性がないかのように線圢のたたであり、倧芏暡なプロゞェクトでは理解しやすいこずが倚い
  5. 新しいコミットは衚瀺されたせん


早送りが可胜なものをすばやく芋぀ける方法 これを行うには、組み合わせお1぀の質問に答える必芁がある2぀のブランチのgitkを芋おください。䞊から䞋から䞊ぞだけ移動する堎合、ブランチAからBぞの盎接パスがありたす。 はいの堎合、早送りが行われたす。
理論的には明らかです。実際に詊しおみお、倉曎をマスタヌに枡したす。
 dev1(collider/terminate)$ git checkout master Switched to branch 'master' Your branch is ahead of 'origin/master' by 4 commits. dev1(master)$ git merge collider/start Updating 0c3aa28..d229fa9 Fast-forward #    collider.init.sh | 9 +++++++++ 1 file changed, 9 insertions(+) 

結果ポむンタが先に進みたした


統䞀

次に、倉曎をコラむダヌ/タヌミネヌトから取埗したす 。 しかし、ここたで読んだ人結局読んで、はいは、盎接の道はないこずに気付くでしょう。 早送りを芁求するためにgitを詊しおみたしょう
 dev1(master)$ git merge --ff-only collider/terminate fatal: Not possible to fast-forward, aborting. 

予想されるこずです。 マヌゞするだけです
 dev1(master)$ git merge collider/terminate Auto-merging collider.init.sh CONFLICT (content): Merge conflict in collider.init.sh Automatic merge failed; fix conflicts and then commit the result. 

葛藀があるこずも嬉しいです。 通垞、この時点で、䞀郚の人は迷子になり、Googleで䜕をすべきかを尋ねたす。
開始するには
同じ行で倉曎が行われた2぀以䞊のコミットを結合しようずするず、競合が発生したす。 そしお今、gitは䜕をすべきかを知りたせん。最初のオプションを遞択するか、2番目のオプションを遞択するか、叀いオプションを残すか、すべおを削陀したす。

い぀ものように、最も必芁な2぀のチヌムは私たちを助けるために急いでいたす
 dev1(master)$ git status # On branch master # Your branch is ahead of 'origin/master' by 5 commits. # # Unmerged paths: # (use "git add/rm <file>..." as appropriate to mark resolution) # # both modified: collider.init.sh # no changes added to commit (use "git add" and/or "git commit -a") dev1(master)$ gitk --all 


私たちはmasterにいたす。HEADは同じものを指し、コミットもそこに远加されたす。
ファむルは次のようになりたす。
 #!/bin/sh USER=collider <<<<<<< HEAD do_start(){ echo -n "Starting collider..." sleep 1s echo "ok" echo "The answer is 42. Please, come back again after 1 billion years." } case $1 in start) do_start ======= do_terminate() { echo -n "Safely terminating collider..." sleep 1s echo "oops :(" } case $1 in terminate) do_terminate >>>>>>> collider/terminate ;; *) echo Uknown Action: $1 ;; esac 

䞡方のオプションが必芁ですが、手動で結合したくありたせんか ここでは、すべおのマヌゞツヌルが圹立ちたす。
競合を解決する最も簡単な方法は、 git mergetoolコマンドを呌び出すこずです。 䜕らかの理由で、誰もがそのようなチヌムに぀いお知っおいるわけではありたせん。
圌女は次のようなこずをしたす。
  1. diffたたはmergeプログラムの遞択を芋぀けお提䟛する
  2. ファむルfilename.origマヌゞを詊みる前のファむルを䜜成したす
  3. ファむルfilename.base䜜成されたファむルを䜜成したす
  4. ファむルfilename.remoteを䜜成したす別のブランチで倉曎されたため
  5. ファむルfilename.localを䜜成したす倉曎したずおり
  6. 競合を解決した埌、すべおがファむル名で保存されたす

私達は詊みたす
 dev1(master)$ git mergetool merge tool candidates: opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse ecmerge p4merge araxis bc3 emerge vimdiff Merging: collider.init.sh Normal merge conflict for 'collider.init.sh': {local}: modified file {remote}: modified file Hit return to start merge resolution tool (kdiff3): 

倉曎が同じ競合の堎所にあったずいう事実により、倚くのこずが起こりたした。 したがっお、私はどこでも最初のオプションを取り、2番目のオプションを最初のオプションの盎埌にコピヌしたしたが、guiを䜿甚するず非垞に簡単です。 結果は次のずおりです。䞊郚にファむルオプションがあり、䞋郚にナニオンがありたす品質に぀いおは申し蚳ありたせん。

結果を保存し、りィンドりを閉じおコミットし、結果を確認したす。


他の2぀の結合である新しいコミットを䜜成したした。 このための盎接的な道がなかったため、早送りは行われたせんでした。ストヌリヌは少し混乱し始めたした。 マヌゞが本圓に必芁な堎合もありたすが、過床に耇雑なストヌリヌも圹に立ちたせん。
実際のプロゞェクトの䟋を次に瀺したす。

もちろん、これはダメです 「しかし、開発は䞊行しお行われ、早送りはありたせん」ずあなたは蚀いたすか 抜け道がありたす

再線

ストヌリヌを矎しくダむレクトに保぀​​ために䜕ができたすか ブランチを取埗しお、別のブランチで再構築できたす ぀たり ブランチを新しい開始点に向け、すべおのコミットを1぀ず぀再生したす。このプロセスはリベヌスず呌ばれたす。コミットは、再構築するブランチの継続ずなりたす。そうすれば、物語はシンプルで線圢になりたす。そしお、早送りが可胜になりたす。
蚀い換えれば、あるブランチから別のブランチぞの倉曎の履歎を繰り返したす。あたかも別のブランチを取埗しお同じ倉曎を再䜜成したかのように。

たず、最新の倉曎を元に戻したす。最も簡単な方法は、マスタヌポむンタヌを以前の状態に戻すこずです。 merge-commitを䜜成し、正確にmasterを移動したした。したがっお、それを戻す必芁がありたす。同じコミットが望たしいそしお堎合によっおは重芁こずがありたす。
その結果、マヌゞコミットはポむンタヌなしで残り、どのブランチにも属したせん。

gitkたたはコン゜ヌルを䜿甚しお、ポむンタヌを移動したす。collider / startブランチはすでにコミットを指しおいるので、そのIDを探す必芁はありたせんが、ブランチ名を䜿甚できたすこれは同じこずです
 dev1(master)$ git reset --hard collider/start HEAD is now at d229fa9 Added Collider Start Function 


merge-commitはどうなりたしたか
(), . Git , , .. , . , git garbage collector .
, . git reflog . , ( HEAD ). , id , checkout ( ).
( , ):
 d229fa9 HEAD@{0}: reset: moving to collider/start 80b77c3 HEAD@{1}: commit (merge): Merged collider/terminate d229fa9 HEAD@{2}: merge collider/start: Fast-forward 0c3aa28 HEAD@{3}: checkout: moving from collider/terminate to master 4ea02f5 HEAD@{4}: commit: Added Collider Terminate Function 0c3aa28 HEAD@{5}: checkout: moving from collider/start to collider/terminate d229fa9 HEAD@{6}: commit: Added Collider Start Function 0c3aa28 HEAD@{7}: checkout: moving from collider/launch to collider/start 0c3aa28 HEAD@{8}: checkout: moving from collider/terminate to collider/launch 0c3aa28 HEAD@{9}: checkout: moving from collider/stop to collider/terminate 0c3aa28 HEAD@{10}: checkout: moving from collider/start to collider/stop 0c3aa28 HEAD@{11}: checkout: moving from master to collider/start 0c3aa28 HEAD@{12}: commit: Added collider init script 41f0540 HEAD@{13}: checkout: moving from v2 to master 75607a1 HEAD@{14}: commit: Ugly changes 55280dc HEAD@{15}: checkout: moving from master to v2 41f0540 HEAD@{16}: commit: Change 3 55280dc HEAD@{17}: commit: Change 2 598a03a HEAD@{18}: commit: Change 1 d80e5f1 HEAD@{19}: commit (initial): Init Project 



のは、䜕が起こったのか芋おみたしょう


その埌、コミットに取り、別のブランチを再構築するためには、圌らの共通の起源を芋぀ける必芁が調敎可胜な枝をしお、同じ順序で、にそれらを眮くメむンベヌス支店。非垞に明確な画像機胜はマスタヌにリビルド䞭です

重芁な泚意「perestroika」の埌、これらは新しいコミットになりたす。そしお、叀いものは消えず、どこにも移動したせんでした。

: merge-commit. collider/terminate collider/start .
collider/terminate collider/start , master merge-commit . , , master ( git checkout master && git reset --hard collider/terminate ). , . Git — , .


私たちは理論を理解し、実際に詊しおみたした。コラむダヌ/終了に切り替え、マスタヌがポむントするコミットに再構築したすたたは、コラむダヌ/開始、より䟿利な人。コマンドは文字通り「珟圚のブランチを取埗し、指定されたコミットたたはブランチで再構築したす」
 dev1(master)$ git checkout collider/terminate Switched to branch 'collider/terminate' dev1(collider/terminate)$ git rebase -i master # -i    , ..  git rebase todo list       

゚ディタヌが開き、およそ次のものが衚瀺されたす。
 pick 4ea02f5 Added Collider Terminate Function # Rebase d229fa9..4ea02f5 onto d229fa9 # # Commands: # p, pick = use commit # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit # f, fixup = like "squash", but discard this commit's log message # x, exec = run command (the rest of the line) using shell # # These lines can be re-ordered; they are executed from top to bottom. # # If you remove a line here THAT COMMIT WILL BE LOST. # However, if you remove everything, the rebase will be aborted. # 

぀たり、ペレストロむカの過皋で、コミットに関するコメントを倉曎したり、コミット自䜓を線集したり、マヌゞしたり、完党にスキップしたりできたす。 ぀たりブランチの履歎を認識せずに曞き換えるこずができたす。この段階では、これは必芁ありたせん。゚ディタヌを閉じお続行したす。前回同様、競合を避けるこずはできたせん。
 error: could not apply 4ea02f5... Added Collider Terminate Function When you have resolved this problem run "git rebase --continue". If you would prefer to skip this patch, instead run "git rebase --skip". To check out the original branch and stop rebasing run "git rebase --abort". Could not apply 4ea02f5... Added Collider Terminate Function dev1((no branch))$ git status # Not currently on any branch. # Unmerged paths: # (use "git reset HEAD <file>..." to unstage) # (use "git add/rm <file>..." as appropriate to mark resolution) # # both modified: collider.init.sh # no changes added to commit (use "git add" and/or "git commit -a") 

git mergetoolを䜿甚しお競合を解決し、 "rebuild" -git rebase --continueを続行したす。Gitはむンタラクティブに倉曎およびコメントする機胜を提䟛したす。
結果

これで、マスタヌを曎新しお䞍芁なものをすべお削陀するこずはもはや難しくありたせん
 dev1(collider/terminate)$ git checkout master Switched to branch 'master' Your branch is ahead of 'origin/master' by 5 commits. dev1(master)$ git merge collider/terminate Updating d229fa9..6661c2e Fast-forward collider.init.sh | 11 +++++++++++ 1 file changed, 11 insertions(+) dev1(master)$ git branch -d collider/start Deleted branch collider/start (was d229fa9). dev1(master)$ git branch -d collider/terminate Deleted branch collider/terminate (was 6661c2e). 


この段階で、線集を削陀、線集、マヌゞし、出力では、倉化の矎しい線圢履歎を取埗したした。


䌑憩

かなり倚くの情報がすでに受信されおいるので、停止しおすべおに぀いお考える必芁がありたす。䟋を䜿甚しお、次のgit機胜に粟通したした。


さらなる䟋はより耇雑になりたす。ファむルにランダムな行を远加する簡単なスクリプトを䜿甚したす。
この段階では、どのようなコンテンツでも構いたせんが、1぀だけでなく、さたざたなコミットを甚意するこずをお勧めしたす。明確にするために。
スクリプトはファむルにランダムな行を远加し、gitコミットを䜜成したす。これは数回繰り返されたす
 dev1(master)$ for i in `seq 1 2`; do STR=`pwgen -C 20 -B 1`; echo $STR >> trash.txt; git commit -m "Added $STR" trash.txt; done [master e64499d] Added rooreoyoivoobiangeix 1 file changed, 1 insertion(+) [master a3ae806] Added eisahtaexookaifadoow 1 file changed, 1 insertion(+) 


倉曎の送信ず受信



リモヌトリポゞトリを操䜜する方法を孊ぶ時が来たした。䞀般的に蚀えば、仕事には次のこずができる必芁がありたす。


䜿甚される䞻なコマンドのリストは次のずおりです。
  1. git remote -リモヌトリポゞトリの管理
  2. git fetch -取埗
  3. git pull- git fetch+ ず同じgit merge
  4. git push -送信


git remote

䞊蚘のように、originはデフォルトのリポゞトリ名です。名前が必芁です いく぀かのリポゞトリが存圚する可胜性があり、䜕らかの方法で区別する必芁がありたす。たずえば、フラッシュドラむブにリポゞトリのコピヌがあり、フラッシュリポゞトリを远加したした。したがっお、originずflashの 2぀のリポゞトリを同時に䜿甚できたす。

リポゞトリ名はブランチ名のプレフィックスずしお䜿甚されるため、ブランチを別のブランチず区別するこずができたす䟋masterおよびorigin / master

ちょっずしたトリック
master origin origin/master . , '/'.
぀たり " origin\/master ", master . Git , , . , .


ヘルプgit remoteドキュメントは非垞によく説明されおいたす。予想どおり、コマンドがありたすadd、rm、rename、show。
show基本的なリポゞトリ蚭定が衚瀺されたす
 dev1(master)$ git remote show origin * remote origin Fetch URL: /home/sirex/proj/git-habr/origin Push URL: /home/sirex/proj/git-habr/origin HEAD branch: master Remote branch: master tracked Local branch configured for 'git pull': master merges with remote master Local ref configured for 'git push': master pushes to master (fast-forwardable) 


既存のリポゞトリを远加するには、次を䜿甚したすadd。
 git remote add backup_repo ssh://user@myserver:backups/myrepo.git #   git push backup_repo master 


git fetch

チヌムはそれを代匁したす。倉曎を取埗したす。
ロヌカルで倉曎がないこずは泚目に倀したす。Gitは䜜業コピヌに觊れず、ブランチにも觊れたせん。
新しいコミットがダりンロヌドされ、リモヌトブランチずタグのみが曎新されたす。これは、リポゞトリを曎新する前に、すべおの倉曎を確認できるため䟿利です。

以䞋はプッシュコマンドの説明ですが、フェッチがどのように機胜するかを明確に瀺すために、倉曎をoriginに枡す必芁がありたす。
 dev1(master)$ git push origin master Counting objects: 29, done. Delta compression using up to 4 threads. Compressing objects: 100% (21/21), done. Writing objects: 100% (27/27), 2.44 KiB, done. Total 27 (delta 6), reused 0 (delta 0) Unpacking objects: 100% (27/27), done. To /home/sirex/proj/git-habr/origin d80e5f1..a3ae806 master -> master 


次に、dev2を代衚しお、䜕が䜕であるかを確認し、すべおの倉曎を取埗したす。
 dev2(master)$ git log commit d80e5f1746856a7228cc27072fa71f1c087d649a Author: jsirex Date: Thu Apr 4 04:21:07 2013 +0300 Init Project #   ,  : dev2(master)$ git fetch origin remote: Counting objects: 29, done. remote: Compressing objects: 100% (21/21), done. remote: Total 27 (delta 6), reused 0 (delta 0) Unpacking objects: 100% (27/27), done. From /home/sirex/proj/git-habr/origin d80e5f1..a3ae806 master -> origin/master 


それは次のようになりたす。

私たちがしおいるこずに泚意しおくださいマスタヌ。
できるこず
git checkout origin/master-リモヌトマスタヌに切り替えお「タッチ」したす。このブランチを線集するこずはできたせんが、独自のロヌカルブランチを䜜成しお操䜜できたす。
git merge origin/master-新しい倉曎ず独自の倉曎を組み合わせたす。なぜなら ロヌカルに倉曎がなかった堎合、マヌゞは早送りに倉わりたす。
 dev2(master)$ git merge origin/master Updating d80e5f1..a3ae806 Fast-forward README.md | 2 ++ collider.init.sh | 31 +++++++++++++++++++++++++++++++ trash.txt | 2 ++ 3 files changed, 35 insertions(+) create mode 100755 collider.init.sh create mode 100644 trash.txt 


新しいブランチがオリゞンに衚瀺される堎合、fetch自䜓もそれらをダりンロヌドしたす。たた、すべおではなく特定のブランチのみを曎新するようにフェッチを芁求するこずもできたす。
重芁なポむント誰かがオリゞンからブランチを削陀するずき、あなたはただロヌカルでそれに぀いおのロヌカルレコヌドを持っおいたす。たずえば、origin / deleted / branchは匕き続き衚瀺されたすが、もう存圚したせん。これらの゚ントリを削陀するには、を䜿甚したすgit fetch origin --prune。

git pull

git pullgit fetch + git mergeず同じです。もちろん、倉曎は察応するブランチずマヌゞされたすmaster with origin / master、feature with origin / feature。ブランチは、誰かが考えるように名前で結合されおいたせんが、䞊流の远跡ブランチのためです。䜜業のためにブランチをチェックアりトするず、gitは次のようなこずをしたす。
  1. 既にそのようなブランチがロヌカルに存圚するかどうかを調べ、存圚する堎合はそれを取埗したす
  2. ブランチがない堎合は、リモヌトにあるかどうかを調べたす/ <branch_name>
  3. 存圚する堎合、origin / <branch_name>ず同じ堎所にロヌカルに<branch_name>を䜜成し、これらのブランチを「リンク」したすブランチ<branch_name>は珟圚、リモヌトのorigin / <branch_name>を远跡しおいたす

これは.git / configファむルで確認できたす
 [branch "master"] remote = origin merge = refs/heads/master 


95の堎合、この動䜜を倉曎する必芁はありたせん。

ロヌカルで倉曎があった堎合、git pullそれらはリモヌトブランチず自動的にマヌゞされ、早送りではなくマヌゞコミットが行われたす。䜕かを開発しおいる間、コヌドは叀くなっおいるため、最初にアップグレヌドし、新しいコヌドの䞊にすべおの倉曎を適甚しおから結果を出すのがいいでしょう。たたは、今のずころロヌカルで続行したす。そしお、物語が混ざらないように。これはこれを行うのに圹立ちたすrebase。
gitがデフォルトrebaseではなくを䜿甚するmergeように、あなたはそれを尋ねるこずができたす
 git config branch.<branch_name>.rebase true 


git push

git push origin-倉曎を転送したす。この堎合、すべおの远跡ブランチが送信されたす。特定のブランチを䌝えるために、明瀺的に名前を指定する必芁がありたすgit push origin branch_name。

この段階で、疑問が生じる堎合がありたす。


コマンドの拡匵ナヌスケヌスは、すべおの質問に答えるこずができたす。
git push origin <___>:<___origin>
䟋
 git push origin d80e5f1:old_master #       old_master.     d80e5f1 git push origin my_local_feature:new_feature/with_nice_name #     new_feature/with_nice_name  my_local_feature git push origin :dead_feature #   ""  dead_feature. ..  dead_feature   .    


重芁ブランチを曎新するずき、最初にすべおの最新の倉曎を取埗しおから、すべおを元に戻そうずするこずが想定されたす。Gitはストヌリヌが線圢のたたであるず想定し、珟圚の倉曎を継続したす早送り。それ以倖の堎合は、以䞋を受け取りたすrejected! non fast-forward push! 。
時々、あなたが䜕をしおいるかを正確に知っおいるずき、それは必芁です。これを回避できたす
 git push origin master --force #    ,   


私たちはプロゞェクトに含たれおいたす



この時点で、プッシュ、プルがどのように機胜するかは倚かれ少なかれ明らかです。さらに曖昧なのは、マヌゞずリベヌスの違いです。これがなぜ必芁で、どのように適甚するのかは完党に䞍明です。
誰かに尋ねられたら
-なぜバヌゞョン管理システムが必芁なのですか
ほずんどの堎合、あなたは聞くこずができたす
-このシステムは、プロゞェクトのすべおの倉曎を保存するのに圹立ち、䜕も倱われず、い぀でも「ロヌルバック」できたす。

ここで、「どのくらいの頻床でロヌルバックしなければならないのか」ずいう質問を自問しおください。プロゞェクトの最埌の状態よりも倚くを保存する必芁がありたすか正盎な答えは「非垞にたれ」です。この質問を提起しお、プロゞェクトにおけるバヌゞョン管理システムのはるかに重芁な圹割を匷調したす。
バヌゞョン管理システムにより、耇数の開発者がプロ​​ゞェクトで共同䜜業できたす。


プロゞェクトで他の開発者ず䞀緒に䜜業するのがいかに䟿利で、バヌゞョン管理システムがどれだけこれを支揎しおいるかが最も重芁なこずです。

VCS_NAMEを䜿甚しおいたすか䟿利ですか開発プロセスを制限し、芁件に簡単に適応したすか速いしたがっお、このVCS_NAMEはプロゞェクトに最適です。おそらく、䜕も倉曎する必芁はありたせん。

兞型的なプロゞェクトシナリオ


それでは、コヌドの芳点からプロゞェクトに取り組む兞型的なシナリオに぀いお話したしょう。そしおこれ


このプロセスを実珟するには、どこに䜕を保存するかを明確に決定する必芁がありたす。なぜならすべおのタスクに軜量のブランチ぀たり、リ゜ヌスや堎所などを費やさないの堎合、個別のブランチを䜜成できたす。これは良い習慣です。このアプロヌチにより、䞀連の倉曎を簡単に操䜜したり、それらをさたざたなブランチに含めたり、倱敗したオプションを完党に排陀したりするこずができたす。マスタヌは、通垞、最埌にリリヌスされたバヌゞョンを保持し、唯䞀のリリヌスからリリヌスに曎新されたす。次のように、バヌゞョンを瀺すタグを䜜成する必芁はありたせん。マスタヌが曎新される堎合がありたす。メむンの開発甚にもう1぀のブランチが必芁になりたす。これはすべおがマヌゞされ、masterの継続ずなるブランチです。これはテストされ、準備ができたらリリヌス䞭にすべおの倉曎がmasterにマヌゞされたす。このスレッドを呌び出したしょう


DEV。
修正プログラムをリリヌスする必芁がある堎合、マスタヌ状態たたは特定のタグに戻り、修正プログラム/バヌゞョンブランチを䜜成しお、重芁な倉曎の修正䜜業を開始できたす。これは、蚭蚈および進行䞭の開発には圱響したせん。feature / <feature_name>
ブランチを䜿甚しお機胜を開発するず䟿利です。このスレッドを最新の倉曎で開始し、devから自分に定期的に倉曎を「プル」するこずをお勧めしたす。ストヌリヌをシンプルか぀盎線的に保぀には、devgit rebase devでブランチを再構築するこずをお勧めしたす。
マむナヌなバグの修正はに盎接行くこずができたすDEV。ただし、小さなバグや倉曎があっおも、ロヌカルに䞀時的なブランチを䜜成するこずをお勧めしたす。それらをグロヌバルリポゞトリに送信する必芁はありたせん。これらは䞀時的なブランチにすぎたせん。このアプロヌチは倚くの機䌚を提䟛したす


バグ修正

devブランチを䜜成しお、兞型的なバグ修正シナリオを考えおみたしょう。
 dev1(master)$ git status # On branch master nothing to commit (working directory clean) dev1(master)$ git checkout -b dev Switched to a new branch 'dev' dev1(dev)$ git push origin dev Total 0 (delta 0), reused 0 (delta 0) To /home/sirex/proj/git-habr/origin * [new branch] dev -> dev 

そしお、2番目の開発者は、自分自身に新しいブランチを「取り入れ」たす。
 dev2(master)$ git pull From /home/sirex/proj/git-habr/origin * [new branch] dev -> origin/dev Already up-to-date. 


2人の開発者がそれぞれ独自のバグに取り組み、いく぀かのコミットを行うようにしたすこのようない方法で倚くのランダムコミットを生成するずいう事実ず混同しないでください。
 dev1(dev)$ for i in `seq 1 10`; do STR=`pwgen -C 20 -B 1`; echo $STR >> trash.txt; git commit -m "Added $STR" trash.txt; done [dev 0f019d0] Added ahvaisaigiegheweezee 1 file changed, 1 insertion(+) [dev c715f87] Added eizohshochohseesauge 1 file changed, 1 insertion(+) [dev 9b9672c] Added aitaquuerahshiqueeph 1 file changed, 1 insertion(+) [dev 43dad98] Added zaesooneighufooshiph 1 file changed, 1 insertion(+) [dev 9da2de3] Added aebaevohneejaefochoo 1 file changed, 1 insertion(+) [dev e93f93e] Added rohmohpheinugogaigoo 1 file changed, 1 insertion(+) [dev 54ba433] Added giehaokeequokeichaip 1 file changed, 1 insertion(+) [dev 05f72db] Added hacohphaiquoomohxahb 1 file changed, 1 insertion(+) [dev 8c03e0d] Added eejucihaewuosoonguek 1 file changed, 1 insertion(+) [dev cf21377] Added aecahjaokeiphieriequ 1 file changed, 1 insertion(+) 

 dev2(master)$ for i in `seq 1 6`; do STR=`pwgen -C 20 -B 1`; echo $STR >> trash.txt; git commit -m "Added $STR" trash.txt; done [master 1781a2f] Added mafitahshohfaijahney 1 file changed, 1 insertion(+) [master 7df3851] Added ucutepoquiquoophowah 1 file changed, 1 insertion(+) [master 75e7b2b] Added aomahcaashooneefoavo 1 file changed, 1 insertion(+) [master d4dea7e] Added iexaephiecaivezohwoo 1 file changed, 1 insertion(+) [master 1459fdb] Added quiegheemoighaethaex 1 file changed, 1 insertion(+) [master 1a949e9] Added evipheichaicheesahme 1 file changed, 1 insertion(+) 


䜜業が終了したら、倉曎をリポゞトリに転送したす。Dev1
 dev1(dev)$ git push origin dev Counting objects: 32, done. Delta compression using up to 4 threads. Compressing objects: 100% (30/30), done. Writing objects: 100% (30/30), 2.41 KiB, done. Total 30 (delta 19), reused 0 (delta 0) Unpacking objects: 100% (30/30), done. To /home/sirex/proj/git-habr/origin a3ae806..cf21377 dev -> dev 


2番目の開発者
 dev2(master)$ git push origin dev error: src refspec dev does not match any. error: failed to push some refs to '/home/sirex/proj/git-habr/origin' 


どうしたたず、私たちはやったがpull、devに切り替えるのを忘れおいたした。そしお圌らはマスタヌで働き始めたした。
gitを䜿甚するずきは、できるだけ具䜓的に「コマンド」を実行しおください。
倉曎をdevに枡したいず思いたした。代わりgit push origin devに単玔に䜿甚した堎合git push、
gitは必芁な凊理を行いたす- マスタヌからorigin / masterに倉曎を枡したす。この状況は修正できたすが、より耇雑です。すべおをロヌカルで修正する方がはるかに簡単です。


䞊蚘のように、それは倧䞈倫です、すべおが修正可胜です。い぀ものように、のは、圌女が行っおいたか芋おみたしょうgitk --all

私たちは前進を持っおいる「»運転したマスタヌを、しかしdevに「行く」必芁がありたした。状況を修正するためのいく぀かのオプションがありたす。
ここでは、たずえば次のようにできたす。
  1. 他に倉曎がなかったため、devに切り替えたす
  2. masterからdevぞのすべおの倉曎を結合したす盎接パス、早送り、問題なし。
  3. 正しいdevを実行し、間違ったマスタヌを以前の正しい䜍眮に蚭定したす。以前の䜍眮origin / master


䞀芋、倚くのアクションがあり、すべおが䜕らかの圢で耇雑になっおいるようです。しかし、芋おみるず、䜕をする必芁があるかずいう説明は、䜜業そのものよりもはるかに倚くなっおいたす。そしお、最も重芁なこずは、すでに䞊蚘で行ったこずです。緎習したしょう
 dev2(master)$ git checkout dev #  Branch dev set up to track remote branch dev from origin. Switched to a new branch 'dev' dev2(dev)$ git merge master #  fast-forward Updating a3ae806..1a949e9 Fast-forward trash.txt | 6 ++++++ 1 file changed, 6 insertions(+) dev2(dev)$ git checkout master #   master ... Switched to branch 'master' Your branch is ahead of 'origin/master' by 6 commits. dev2(master)$ git reset --hard origin/master # ...       HEAD is now at a3ae806 Added eisahtaexookaifadoow dev2(master)$ git checkout dev #   dev Switched to branch 'dev' Your branch is ahead of 'origin/dev' by 6 commits. 


結果を芋おみたしょう

今、すべおがそうあるべきです私たちの倉曎はdevにあり、originに枡す準備ができおいたす。
合栌
 dev2(dev)$ git push origin dev To /home/sirex/proj/git-habr/origin ! [rejected] dev -> dev (non-fast-forward) error: failed to push some refs to '/home/sirex/proj/git-habr/origin' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Merge the remote changes (eg 'git pull') hint: before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details. 


他の誰かdev1がリポゞトリを曎新し、倉曎を枡し、私たちは単に「遅れた」ため、転送は機胜したせんでした。git pullたたはを䜜成しお状態を曎新する必芁がありgit fetchたす。なぜならgit pullはすぐにブランチをマヌゞしたす。gitfetchを䜿甚するこずを奜みたす。埌で芋お回っお決定する機䌚を䞎えおくれたす。
 dev2(dev)$ git fetch origin remote: Counting objects: 32, done. remote: Compressing objects: 100% (30/30), done. remote: Total 30 (delta 19), reused 0 (delta 0) Unpacking objects: 100% (30/30), done. From /home/sirex/proj/git-habr/origin a3ae806..cf21377 dev -> origin/dev 


倉曎を䌝えるためのいく぀かのオプションがありたす。
  1. そこにあったものを消去しお、倉曎を匷制的に転送したす。 git push origin dev --force
  2. を䜿甚しおブランチを続行しgit merge origin/dev、次にgit push origin dev新しい倉曎を独自の倉曎ずマヌゞしお転送したす
  3. ブランチを新しいブランチの䞀番䞊に再構築したす。これにより、開発シヌケンスが保持され、䞍芁なブランチが䞍芁にgit rebase origin/devなりgit push origin devたす。

最も魅力的なのは3番目のオプションです。さらに、むンタラクティブモヌドで詊しおみたす。
 dev2(dev)$ git rebase -i origin/dev #      origin/dev 

゚ディタヌが開き、履歎を修正する機䌚を提䟛したす。たずえば、コミットの順序を倉曎したり、いく぀かを結合したりしたす。これは䞊に曞かれおいたす。そのたたにしおおきたす。
 pick 1781a2f Added mafitahshohfaijahney pick 7df3851 Added ucutepoquiquoophowah pick 75e7b2b Added aomahcaashooneefoavo pick d4dea7e Added iexaephiecaivezohwoo pick 1459fdb Added quiegheemoighaethaex pick 1a949e9 Added evipheichaicheesahme # Rebase cf21377..1a949e9 onto cf21377 # # Commands: # p, pick = use commit # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit # f, fixup = like "squash", but discard this commit's log message # x, exec = run command (the rest of the line) using shell # # These lines can be re-ordered; they are executed from top to bottom. # # If you remove a line here THAT COMMIT WILL BE LOST. # However, if you remove everything, the rebase will be aborted. # 


ペレストロむカの過皋で、察立が生じたす。git mergetoolたたは必芁に応じお解決し、リストラを続けたすgit rebase --continue
なぜなら私は垞に単䞀のファむルに行を远加しおいたすが、競合は避けられたせんが、実際のプロゞェクトでは、プロゞェクトのさたざたな郚分の䜜業が分散されるず、競合はたったく発生したせん。たたは、非垞にたれです。
ここから、いく぀かの䟿利なルヌルを導き出すこずができたす。


すべおの競合が解決されるず、ストヌリヌは線圢か぀論理的になりたす。明確にするために、コメントを倉曎したしたむンタラクティブなリベヌスがこの機䌚を䞎えたす

ブランチはorigin / devを継続し、倉曎を送信できたす関連、新しいコミットに適応
 dev2(dev)$ git push origin dev Counting objects: 20, done. Delta compression using up to 4 threads. Compressing objects: 100% (18/18), done. Writing objects: 100% (18/18), 1.67 KiB, done. Total 18 (delta 11), reused 0 (delta 0) Unpacking objects: 100% (18/18), done. To /home/sirex/proj/git-habr/origin cf21377..8212c4b dev -> dev 

さらに、物語は繰り返されたす。䞊蚘のように、䟿宜䞊、たたはいく぀かのバグに関する䜜業の堎合、䜜業を開始する前にdevたたはorigin / devから個別のブランチを䜜成するず䟿利です。

短い芁玄通垞のバグ修正は、次の簡単なアルゎリズムを䜿甚しお実行できたす。
  1. devブランチたたはセパレヌトの修正
  2. オリゞンからの倉曎の取埗git fetch origin
  3. 倉曎を最新バヌゞョンにリビルドしたすgit rebase -i origin/dev
  4. 倉曎をオリゞンに枡すgit push origin dev


機胜ブランチ

倧きな䜜業を行う必芁がある堎合がありたすが、それは終了するたでメむンバヌゞョンに分類されるべきではありたせん。いく぀かのブランチはそのようなブランチで動䜜できたす。非垞に深刻で膚倧なバグは、gitを機胜ずしお凊理するプロセスの芳点から考えるこずができたす-数人が䜜業する別のブランチです。プロセス自䜓は、通垞のバグ修正ずたったく同じです。唯䞀の䜜業はdevではなく、機胜/名前ブランチで行われたす。
䞀般に、このようなブランチは短呜1〜2週間ず長呜1か月以䞊になりたす。もちろん、ブランチの寿呜が長くなればなるほど、頻繁に曎新する必芁があり、メむンブランチから倉曎を「プル」したす。ブランチが倧きいほど、それに䌎うオヌバヌヘッドが倧きくなりたす。

短呜の機胜ブランチから始めたしょう

通垞、ブランチは最埌のコヌドから䜜成されたす。この堎合、devブランチから䜜成されたす。
 dev1(dev)$ git fetch origin remote: Counting objects: 20, done. remote: Compressing objects: 100% (18/18), done. remote: Total 18 (delta 11), reused 0 (delta 0) Unpacking objects: 100% (18/18), done. From /home/sirex/proj/git-habr/origin cf21377..8212c4b dev -> origin/dev dev1(dev)$ git branch --no-track feature/feature1 origin/dev #   feature/feature1  origin/dev,      dev1(dev)$ git push origin feature/feature1 #     ,      Total 0 (delta 0), reused 0 (delta 0) To /home/sirex/proj/git-habr/origin * [new branch] feature/feature1 -> feature/feature1 


今feature1の䜜業はfeature / feature1ブランチで行うこずができたす。しばらくするず、ブランチに倚くのコミットがあり、feature1の䜜業が完了したす。同時に、devにも倚くの倉曎が加えられたす。そしお、私たちのタスクは、倉曎をdevに送信するこずです。状況は
次

のようになりたす。状況は前の状況に䌌おいたす。2぀のブランチ、1぀を他のブランチずマヌゞし、リポゞトリに転送する必芁がありたす。唯䞀の違いは、ロヌカルのブランチではなく、2぀のパブリックリモヌトブランチです。これには少しコミュニケヌションが必芁です。䜜業が終了したら、開発者の1人は、devの倉曎を「マヌゞ」し、たずえばブランチを削陀するこずを他の開発者に譊告する必芁がありたす。したがっお、このスレッドに䜕かを転送しおも意味がありたせん。
そしお、アルゎリズムは以前ずほずんど同じです
 git fetch origin #    git rebase -i origin/dev # ,     ,    feature1    dev   .  origin/dev,   dev       ,       git checkout dev #   ,      git merge feature/feature1 #   git reset --hard feature/feature1.       .  ,   fast-forward. 

画像、feature1はdevの䞀郚になり、次に必芁なもの

䞍芁なものをプッシュしおクリヌンアップしたす
 dev1(dev)$ git push origin dev Counting objects: 11, done. Delta compression using up to 4 threads. Compressing objects: 100% (9/9), done. Writing objects: 100% (9/9), 878 bytes, done. Total 9 (delta 6), reused 0 (delta 0) Unpacking objects: 100% (9/9), done. To /home/sirex/proj/git-habr/origin 3272f59..e514869 dev -> dev dev1(dev)$ git push origin :feature/feature1 #   ,   To /home/sirex/proj/git-habr/origin - [deleted] feature/feature1 dev1(dev)$ git branch -d feature/feature1 #   Deleted branch feature/feature1 (was e514869). 


長期にわたる機胜ブランチ

サポヌトず曎新における長寿呜ブランチの耇雑さ。䞊蚘のようにすべおを行うず、灜害が発生する可胜性がありたす。時間がなくなり、メむンブランチが倉曎され、プロゞェクトが倉曎され、機胜が非垞に叀いバヌゞョンに基づいおいたす。機胜をリリヌスするずきが来るず、プロゞェクトからノックアりトされおしたい、組合は非垞に困難になるか、䞍可胜になる可胜性さえありたす。そのため、ブランチを曎新する必芁がありたす。 devが前進したら、時々devからブランチを再構築するだけです。

すべおは問題ありたせんが、publicブランチを取埗しお再構築するこずはできたせん。リベヌス埌のブランチはすでに新しいコミットセットであり、たったく異なる話です。圌女はすでに行ったこずを継続したせん。 Gitはそのような倉曎を受け入れたせん。2぀の異なるパス、早送りはありたせん。ストヌリヌを曞き盎すには、開発者が同意する必芁がありたす。
誰かが履歎を曞き換えお新しいバヌゞョンを匷制したすが、珟時点では、残りは珟圚のブランチに倉曎を転送しないでください。それは䞊曞きされ、すべおがなくなりたす。最初の開発者が終了するず、他の党員がコミットを転送したす。これは、すでに新しいブランチで行われおいる囜勢調査䞭に行う時間です。誰があなたがパブリックブランチをリベヌスできないず蚀ったのですか

緎習したしょう
 dev1(dev)$ git checkout -b feature/long Switched to a new branch 'feature/long' dev1(feature/long)$ git push origin dev Everything up-to-date dev1(feature/long)$ __ dev1(feature/long)$ git push origin feature/long Counting objects: 11, done. Delta compression using up to 4 threads. Compressing objects: 100% (9/9), done. Writing objects: 100% (9/9), 807 bytes, done. Total 9 (delta 6), reused 0 (delta 0) Unpacking objects: 100% (9/9), done. To /home/sirex/proj/git-habr/origin * [new branch] feature/long -> feature/long 


2番目の開発者は、すべおに暙準的に接続したす
 dev2(dev)$ git pull remote: Counting objects: 11, done. remote: Compressing objects: 100% (9/9), done. remote: Total 9 (delta 6), reused 0 (delta 0) Unpacking objects: 100% (9/9), done. From /home/sirex/proj/git-habr/origin * [new branch] feature/long -> origin/feature/long Already up-to-date. dev2(dev)$ git checkout feature/long Branch feature/long set up to track remote branch feature/long from origin. Switched to a new branch 'feature/long' dev2(feature/long)$    dev2(feature/long)$ git pull --rebase feature/long # fetch + rebase   dev2(feature/long)$ git push origin feature/long Counting objects: 11, done. Delta compression using up to 4 threads. Compressing objects: 100% (9/9), done. Writing objects: 100% (9/9), 795 bytes, done. Total 9 (delta 6), reused 0 (delta 0) Unpacking objects: 100% (9/9), done. To /home/sirex/proj/git-habr/origin baf4c6b..ce9e58d feature/long -> feature/long 

メむンのdevブランチにさらにいく぀かのコミットを远加するず、ストヌリヌは次のようになりたす。feature / long


を曎新する時が来たしたが、開発は個別に続行する必芁がありたす。dev1を再構築したす。その埌、圌はそれに぀いおdev2に譊告し、開始したす。
 dev1(feature/long)$ git fetch origin dev1(feature/long)$ git rebase -i origin/dev ...  ,  ,  .. 

珟時点では、dev2は匕き続き動䜜したすが、プッシュできないこずを知っおいたす。目的のブランチはただありたせん珟圚のブランチは削陀されたす。
最初のリベヌスはリベヌスし、ストヌリヌは次のようになりたす。

ブランチはリビルドされ、元の堎所/機胜/長い堎所はそのたたでした。私たちは目暙を達成したした。次は党員ず共有する必芁がありたす。
 dev1(feature/long)$ git push origin feature/long To /home/sirex/proj/git-habr/origin ! [rejected] feature/long -> feature/long (non-fast-forward) error: failed to push some refs to '/home/sirex/proj/git-habr/origin' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Merge the remote changes (eg 'git pull') hint: before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details. 

Gitは、䜕かが間違っおいるこずを改めお思い出させたす。しかし今、私たちは䜕をしおいるかを正確に知っおおり、それが必芁であるこずを知っおいたす。
 dev1(feature/long)$ git push origin feature/long --force Counting objects: 20, done. Delta compression using up to 4 threads. Compressing objects: 100% (18/18), done. Writing objects: 100% (18/18), 1.58 KiB, done. Total 18 (delta 12), reused 0 (delta 0) Unpacking objects: 100% (18/18), done. To /home/sirex/proj/git-habr/origin + ce9e58d...84c3001 feature/long -> feature/long (forced update) 

これで、䜜業の完了に぀いお他の人に譊告するこずにより、さらに䜜業を進めるこずができたす。

これらの倉曎が他の人、特にdev2にどのように圱響したかを芋おみたしょう。
 dev2(feature/long)$ git fetch origin remote: Counting objects: 20, done. remote: Compressing objects: 100% (18/18), done. remote: Total 18 (delta 12), reused 0 (delta 0) Unpacking objects: 100% (18/18), done. From /home/sirex/proj/git-habr/origin + ce9e58d...84c3001 feature/long -> origin/feature/long (forced update) 



歎史は分かれおおり、コミットは1぀を陀いお再構築されおいたす。コミットがたったくなかった堎合、぀たりdev2開発者はハブを読み取り、最初のハブは機胜したすfeature/longが、ポむンタヌを動かしおorigin/feature/long䜜業を続けるだけで十分です。ただし、远加する必芁があるコミットが1぀ありたす。ここで、rebaseがキヌずずもに再び圹立ちたす--onto。
git rebase --onto <___> <c____> <_____>
このアプロヌチでは、再構築のために䞀郚コミットのシヌケンスのみを取るこずができたす。最埌のいく぀かのコミットを匕き継ぐ必芁がある堎合に䟿利です。
蚘録に぀いおも思い出しおくださいHEAD~1。 〜N挔算子をポむンタヌに適甚しお、前のN番目のコミットを指すこずができたす。
HEAD~1-これは前のものですが、HEAD~2-これは前のものです。HEAD~5-5回コミット。 IDを芚えおいないのに䟿利です。

コミットを1぀だけ再構築する方法を芋おみたしょう。
 git rebase -i --onto origin/feature/long feature/long~1 feature/long 

さらに詳しく分析したしょう。
  1. 私たちは機胜/ロングにありたす。これは新しいものずは完党に異なりたすが、必芁なコミットが含たれおいたす1、最埌
  2. origin / feature / longぞの再構築を呜什したすブランチでの新しい開始
  3. ブランチ自䜓はこの機胜/長いです
  4. しかし、すべおを再構築する必芁はありたせん共通の開始の怜玢ずすべおのコミットの再構築は䞍芁であり、既に存圚したすが、前のコミットから始めたす包括的ではありたせん。 ぀たり機胜/ロング〜1

4぀のコミットをドラッグする必芁がある堎合は、になりたすfeature/long~4。
 dev2(feature/long)$ git rebase -i --onto origin/feature/long feature/long~1 feature/long Successfully rebased and updated refs/heads/feature/long. 


䜜業を継続するこずは残っおいたす。この堎合や他の倚くの堎合に圹立぀

別の䟿利なコマンドがありたす- git cherry-pick。
どこからでも、gitにコミットを䟝頌しお珟圚の堎所に適甚するこずができたす。必芁なコミットは「匕きずり捚おられる」可胜性がありたす。
 git reset --hard origin/feature/long && git cherry-pick commit_id # commit_id   , ..  reset      


修正プログラム

修正プログラムが必芁ですできるだけ早く修正する必芁がある非垞に重倧なバグがありたす。同時に、ホットフィックスず䞀緒に最埌のコヌドを転送するこずはできたせん。テストされおおらず、完党なテストの時間はありたせん。可胜な限り迅速にテストされたこの修正のみが必芁です。これを行うには、実皌働環境に送信された最新リリヌスを䜿甚したす。これは、タグたたはマスタヌを残した堎所です。タグは、䜕が正確に収集され、どこで取埗されたかを理解する䞊で非垞に重芁な圹割を果たしたす。
タグはチヌムによっお䜜成されたす
 git tag     '/'   . 

hotfix- :
hotfix tag master ( cherry-pick , - ) cherry-pick , . .
git:
dev2(feature/long)$ git checkout master Switched to branch 'master' dev2(master)$ git tag release/1.0 # , dev2(master)$ git checkout -b hotfix/1.0.x Switched to a new branch 'hotfix/1.0.x' dev2(hotfix/1.0.x)$ .. dev2(hotfix/1.0.x)$ git push origin hotfix/1.0.x Counting objects: 5, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 302 bytes, done. Total 3 (delta 1), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. To /home/sirex/proj/git-habr/origin * [new branch] hotfix/1.0.x -> hotfix/1.0.x dev2(hotfix/1.0.x)$ git tag release/1.0.1 # dev2(hotfix/1.0.x)$ git checkout dev # Switched to branch 'dev' dev2(dev)$ git cherry-pick release/1.0.1 # id, . # , git commit dev2(dev)$ git commit [dev 9982f7b] Added rahqueiraiheinathiav 1 file changed, 1 insertion(+) dev2(dev)$ git push origin dev Counting objects: 5, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 328 bytes, done. Total 3 (delta 2), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. To /home/sirex/proj/git-habr/origin b21f8a5..9982f7b dev -> dev
    git tag '/' .

    hotfix- :
    hotfix tag master ( cherry-pick , - ) cherry-pick , . .
    git:
    dev2(feature/long)$ git checkout master Switched to branch 'master' dev2(master)$ git tag release/1.0 # , dev2(master)$ git checkout -b hotfix/1.0.x Switched to a new branch 'hotfix/1.0.x' dev2(hotfix/1.0.x)$ .. dev2(hotfix/1.0.x)$ git push origin hotfix/1.0.x Counting objects: 5, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 302 bytes, done. Total 3 (delta 1), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. To /home/sirex/proj/git-habr/origin * [new branch] hotfix/1.0.x -> hotfix/1.0.x dev2(hotfix/1.0.x)$ git tag release/1.0.1 # dev2(hotfix/1.0.x)$ git checkout dev # Switched to branch 'dev' dev2(dev)$ git cherry-pick release/1.0.1 # id, . # , git commit dev2(dev)$ git commit [dev 9982f7b] Added rahqueiraiheinathiav 1 file changed, 1 insertion(+) dev2(dev)$ git push origin dev Counting objects: 5, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 328 bytes, done. Total 3 (delta 2), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. To /home/sirex/proj/git-habr/origin b21f8a5..9982f7b dev -> dev
  1. git tag '/' .

    hotfix- :
    hotfix tag master ( cherry-pick , - ) cherry-pick , . .
    git:
    dev2(feature/long)$ git checkout master Switched to branch 'master' dev2(master)$ git tag release/1.0 # , dev2(master)$ git checkout -b hotfix/1.0.x Switched to a new branch 'hotfix/1.0.x' dev2(hotfix/1.0.x)$ .. dev2(hotfix/1.0.x)$ git push origin hotfix/1.0.x Counting objects: 5, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 302 bytes, done. Total 3 (delta 1), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. To /home/sirex/proj/git-habr/origin * [new branch] hotfix/1.0.x -> hotfix/1.0.x dev2(hotfix/1.0.x)$ git tag release/1.0.1 # dev2(hotfix/1.0.x)$ git checkout dev # Switched to branch 'dev' dev2(dev)$ git cherry-pick release/1.0.1 # id, . # , git commit dev2(dev)$ git commit [dev 9982f7b] Added rahqueiraiheinathiav 1 file changed, 1 insertion(+) dev2(dev)$ git push origin dev Counting objects: 5, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 328 bytes, done. Total 3 (delta 2), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. To /home/sirex/proj/git-habr/origin b21f8a5..9982f7b dev -> dev
    git tag '/' .

    hotfix- :
    hotfix tag master ( cherry-pick , - ) cherry-pick , . .
    git:
    dev2(feature/long)$ git checkout master Switched to branch 'master' dev2(master)$ git tag release/1.0 # , dev2(master)$ git checkout -b hotfix/1.0.x Switched to a new branch 'hotfix/1.0.x' dev2(hotfix/1.0.x)$ .. dev2(hotfix/1.0.x)$ git push origin hotfix/1.0.x Counting objects: 5, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 302 bytes, done. Total 3 (delta 1), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. To /home/sirex/proj/git-habr/origin * [new branch] hotfix/1.0.x -> hotfix/1.0.x dev2(hotfix/1.0.x)$ git tag release/1.0.1 # dev2(hotfix/1.0.x)$ git checkout dev # Switched to branch 'dev' dev2(dev)$ git cherry-pick release/1.0.1 # id, . # , git commit dev2(dev)$ git commit [dev 9982f7b] Added rahqueiraiheinathiav 1 file changed, 1 insertion(+) dev2(dev)$ git push origin dev Counting objects: 5, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 328 bytes, done. Total 3 (delta 2), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. To /home/sirex/proj/git-habr/origin b21f8a5..9982f7b dev -> dev
  2. git tag '/' .

    hotfix- :
    hotfix tag master ( cherry-pick , - ) cherry-pick , . .
    git:
    dev2(feature/long)$ git checkout master Switched to branch 'master' dev2(master)$ git tag release/1.0 # , dev2(master)$ git checkout -b hotfix/1.0.x Switched to a new branch 'hotfix/1.0.x' dev2(hotfix/1.0.x)$ .. dev2(hotfix/1.0.x)$ git push origin hotfix/1.0.x Counting objects: 5, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 302 bytes, done. Total 3 (delta 1), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. To /home/sirex/proj/git-habr/origin * [new branch] hotfix/1.0.x -> hotfix/1.0.x dev2(hotfix/1.0.x)$ git tag release/1.0.1 # dev2(hotfix/1.0.x)$ git checkout dev # Switched to branch 'dev' dev2(dev)$ git cherry-pick release/1.0.1 # id, . # , git commit dev2(dev)$ git commit [dev 9982f7b] Added rahqueiraiheinathiav 1 file changed, 1 insertion(+) dev2(dev)$ git push origin dev Counting objects: 5, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 328 bytes, done. Total 3 (delta 2), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. To /home/sirex/proj/git-habr/origin b21f8a5..9982f7b dev -> dev
    git tag '/' .

    hotfix- :
    hotfix tag master ( cherry-pick , - ) cherry-pick , . .
    git:
    dev2(feature/long)$ git checkout master Switched to branch 'master' dev2(master)$ git tag release/1.0 # , dev2(master)$ git checkout -b hotfix/1.0.x Switched to a new branch 'hotfix/1.0.x' dev2(hotfix/1.0.x)$ .. dev2(hotfix/1.0.x)$ git push origin hotfix/1.0.x Counting objects: 5, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 302 bytes, done. Total 3 (delta 1), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. To /home/sirex/proj/git-habr/origin * [new branch] hotfix/1.0.x -> hotfix/1.0.x dev2(hotfix/1.0.x)$ git tag release/1.0.1 # dev2(hotfix/1.0.x)$ git checkout dev # Switched to branch 'dev' dev2(dev)$ git cherry-pick release/1.0.1 # id, . # , git commit dev2(dev)$ git commit [dev 9982f7b] Added rahqueiraiheinathiav 1 file changed, 1 insertion(+) dev2(dev)$ git push origin dev Counting objects: 5, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 328 bytes, done. Total 3 (delta 2), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. To /home/sirex/proj/git-habr/origin b21f8a5..9982f7b dev -> dev
  3. git tag '/' .

    hotfix- :
    hotfix tag master ( cherry-pick , - ) cherry-pick , . .
    git:
    dev2(feature/long)$ git checkout master Switched to branch 'master' dev2(master)$ git tag release/1.0 # , dev2(master)$ git checkout -b hotfix/1.0.x Switched to a new branch 'hotfix/1.0.x' dev2(hotfix/1.0.x)$ .. dev2(hotfix/1.0.x)$ git push origin hotfix/1.0.x Counting objects: 5, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 302 bytes, done. Total 3 (delta 1), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. To /home/sirex/proj/git-habr/origin * [new branch] hotfix/1.0.x -> hotfix/1.0.x dev2(hotfix/1.0.x)$ git tag release/1.0.1 # dev2(hotfix/1.0.x)$ git checkout dev # Switched to branch 'dev' dev2(dev)$ git cherry-pick release/1.0.1 # id, . # , git commit dev2(dev)$ git commit [dev 9982f7b] Added rahqueiraiheinathiav 1 file changed, 1 insertion(+) dev2(dev)$ git push origin dev Counting objects: 5, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 328 bytes, done. Total 3 (delta 2), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. To /home/sirex/proj/git-habr/origin b21f8a5..9982f7b dev -> dev
    git tag '/' .

    hotfix- :
    hotfix tag master ( cherry-pick , - ) cherry-pick , . .
    git:
    dev2(feature/long)$ git checkout master Switched to branch 'master' dev2(master)$ git tag release/1.0 # , dev2(master)$ git checkout -b hotfix/1.0.x Switched to a new branch 'hotfix/1.0.x' dev2(hotfix/1.0.x)$ .. dev2(hotfix/1.0.x)$ git push origin hotfix/1.0.x Counting objects: 5, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 302 bytes, done. Total 3 (delta 1), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. To /home/sirex/proj/git-habr/origin * [new branch] hotfix/1.0.x -> hotfix/1.0.x dev2(hotfix/1.0.x)$ git tag release/1.0.1 # dev2(hotfix/1.0.x)$ git checkout dev # Switched to branch 'dev' dev2(dev)$ git cherry-pick release/1.0.1 # id, . # , git commit dev2(dev)$ git commit [dev 9982f7b] Added rahqueiraiheinathiav 1 file changed, 1 insertion(+) dev2(dev)$ git push origin dev Counting objects: 5, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 328 bytes, done. Total 3 (delta 2), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. To /home/sirex/proj/git-habr/origin b21f8a5..9982f7b dev -> dev
  4. git tag '/' .

    hotfix- :
    hotfix tag master ( cherry-pick , - ) cherry-pick , . .
    git:
    dev2(feature/long)$ git checkout master Switched to branch 'master' dev2(master)$ git tag release/1.0 # , dev2(master)$ git checkout -b hotfix/1.0.x Switched to a new branch 'hotfix/1.0.x' dev2(hotfix/1.0.x)$ .. dev2(hotfix/1.0.x)$ git push origin hotfix/1.0.x Counting objects: 5, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 302 bytes, done. Total 3 (delta 1), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. To /home/sirex/proj/git-habr/origin * [new branch] hotfix/1.0.x -> hotfix/1.0.x dev2(hotfix/1.0.x)$ git tag release/1.0.1 # dev2(hotfix/1.0.x)$ git checkout dev # Switched to branch 'dev' dev2(dev)$ git cherry-pick release/1.0.1 # id, . # , git commit dev2(dev)$ git commit [dev 9982f7b] Added rahqueiraiheinathiav 1 file changed, 1 insertion(+) dev2(dev)$ git push origin dev Counting objects: 5, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 328 bytes, done. Total 3 (delta 2), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. To /home/sirex/proj/git-habr/origin b21f8a5..9982f7b dev -> dev
    git tag '/' .

    hotfix- :
    hotfix tag master ( cherry-pick , - ) cherry-pick , . .
    git:
    dev2(feature/long)$ git checkout master Switched to branch 'master' dev2(master)$ git tag release/1.0 # , dev2(master)$ git checkout -b hotfix/1.0.x Switched to a new branch 'hotfix/1.0.x' dev2(hotfix/1.0.x)$ .. dev2(hotfix/1.0.x)$ git push origin hotfix/1.0.x Counting objects: 5, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 302 bytes, done. Total 3 (delta 1), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. To /home/sirex/proj/git-habr/origin * [new branch] hotfix/1.0.x -> hotfix/1.0.x dev2(hotfix/1.0.x)$ git tag release/1.0.1 # dev2(hotfix/1.0.x)$ git checkout dev # Switched to branch 'dev' dev2(dev)$ git cherry-pick release/1.0.1 # id, . # , git commit dev2(dev)$ git commit [dev 9982f7b] Added rahqueiraiheinathiav 1 file changed, 1 insertion(+) dev2(dev)$ git push origin dev Counting objects: 5, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 328 bytes, done. Total 3 (delta 2), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. To /home/sirex/proj/git-habr/origin b21f8a5..9982f7b dev -> dev
  5. git tag '/' .

    hotfix- :
    hotfix tag master ( cherry-pick , - ) cherry-pick , . .
    git:
    dev2(feature/long)$ git checkout master Switched to branch 'master' dev2(master)$ git tag release/1.0 # , dev2(master)$ git checkout -b hotfix/1.0.x Switched to a new branch 'hotfix/1.0.x' dev2(hotfix/1.0.x)$ .. dev2(hotfix/1.0.x)$ git push origin hotfix/1.0.x Counting objects: 5, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 302 bytes, done. Total 3 (delta 1), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. To /home/sirex/proj/git-habr/origin * [new branch] hotfix/1.0.x -> hotfix/1.0.x dev2(hotfix/1.0.x)$ git tag release/1.0.1 # dev2(hotfix/1.0.x)$ git checkout dev # Switched to branch 'dev' dev2(dev)$ git cherry-pick release/1.0.1 # id, . # , git commit dev2(dev)$ git commit [dev 9982f7b] Added rahqueiraiheinathiav 1 file changed, 1 insertion(+) dev2(dev)$ git push origin dev Counting objects: 5, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 328 bytes, done. Total 3 (delta 2), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. To /home/sirex/proj/git-habr/origin b21f8a5..9982f7b dev -> dev
    git tag '/' .

    hotfix- :
    hotfix tag master ( cherry-pick , - ) cherry-pick , . .
    git:
    dev2(feature/long)$ git checkout master Switched to branch 'master' dev2(master)$ git tag release/1.0 # , dev2(master)$ git checkout -b hotfix/1.0.x Switched to a new branch 'hotfix/1.0.x' dev2(hotfix/1.0.x)$ .. dev2(hotfix/1.0.x)$ git push origin hotfix/1.0.x Counting objects: 5, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 302 bytes, done. Total 3 (delta 1), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. To /home/sirex/proj/git-habr/origin * [new branch] hotfix/1.0.x -> hotfix/1.0.x dev2(hotfix/1.0.x)$ git tag release/1.0.1 # dev2(hotfix/1.0.x)$ git checkout dev # Switched to branch 'dev' dev2(dev)$ git cherry-pick release/1.0.1 # id, . # , git commit dev2(dev)$ git commit [dev 9982f7b] Added rahqueiraiheinathiav 1 file changed, 1 insertion(+) dev2(dev)$ git push origin dev Counting objects: 5, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 328 bytes, done. Total 3 (delta 2), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. To /home/sirex/proj/git-habr/origin b21f8a5..9982f7b dev -> dev
git tag '/' .

hotfix- :
hotfix tag master ( cherry-pick , - ) cherry-pick , . .
git:
dev2(feature/long)$ git checkout master Switched to branch 'master' dev2(master)$ git tag release/1.0 # , dev2(master)$ git checkout -b hotfix/1.0.x Switched to a new branch 'hotfix/1.0.x' dev2(hotfix/1.0.x)$ .. dev2(hotfix/1.0.x)$ git push origin hotfix/1.0.x Counting objects: 5, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 302 bytes, done. Total 3 (delta 1), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. To /home/sirex/proj/git-habr/origin * [new branch] hotfix/1.0.x -> hotfix/1.0.x dev2(hotfix/1.0.x)$ git tag release/1.0.1 # dev2(hotfix/1.0.x)$ git checkout dev # Switched to branch 'dev' dev2(dev)$ git cherry-pick release/1.0.1 # id, . # , git commit dev2(dev)$ git commit [dev 9982f7b] Added rahqueiraiheinathiav 1 file changed, 1 insertion(+) dev2(dev)$ git push origin dev Counting objects: 5, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 328 bytes, done. Total 3 (delta 2), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. To /home/sirex/proj/git-habr/origin b21f8a5..9982f7b dev -> dev


すばやく簡単にできたすかホットフィックスで2぀のコミットがある堎合cherry-pick、devで 2回行う方が簡単かもしれたせん。ただし、それらが倚数ある堎合は、コマンドgit rebase --into ...を再び䜿甚しお、コミットのチェヌン党䜓を再構築できたす。

あらゆる皮類の有甚性


Gitでは、さたざたなチヌムの゚むリアスをカスタマむズできたす。これは非垞に䟿利で、入力時間を短瞮できたす。ここでは䟋を挙げたせん。それらはむンタヌネットでいっぱいです。芋おください。

倉曎を加える前に、履歎を敎理するために自分で倉曎を再構築できたす。
たずえば、ログでは次のようになりたす。
 9982f7b Finally make test works b21f8a5 Fixed typo in Test 3eabaab Fixed typo in Test e514869 Added Test for Foo b4439a2 Implemented Method for Foo 250adb1 Added class Foo 

自分自身を再構築したしょう。ただし、6コミット前から開始したす。
 dev2(dev)$ git rebase -i dev~6 # ..       origin/dev       dev2(dev)$ git rebase -i origin/dev 

むンタラクティブモヌドでは、最初の2぀のコミットを1぀ず最埌の4぀のコミットに結合スカッシュできたす。次に、ストヌリヌは次のようになりたす。
 0f019d0 Added Test for class Foo a3ae806 Implemented class Foo 

これは、共有リポゞトリに枡す方がはるかに優れおいたす。

䜕git configをするこずができるかを芋おくださいgit config --global。実際のプロゞェクトで䜜業を開始する前に、ナヌザヌ名ずメヌルアドレスを蚭定しおおくず䟿利です。
 git config --global user.name sirex git config --global user.email jsirex@gmail.com 


1぀のプロゞェクトで、倚くの機胜の䞊行開発を実斜したした。それらはすべお別々のブランチで開発されたしたが、䞀緒にテストする必芁がありたした。同時に、テスト甚のビルドリリヌスの時点では、機胜の準備が敎っおいるかどうかは明確ではありたせんでした。芁件が倉曎されたり、重倧なバグが発芋されたりする可胜性がありたした。そしお質問は、原則ずしおそれらをすべお組み合わせずに、リリヌス前にすべおを組み合わせおすべおの機胜の䜜業を続ける方法ですか論争Gitはこの問題の解決に圹立ちたす。その方法を次に瀺したす。
  1. ビルドをリリヌスするために、すべおの機胜がマヌゞされた別個のブランチが䜜成されたしたgit merge --no-ff
  2. ブランチはテスト甚に提䟛されたした
  3. 開発は支店で継続
  4. 新しい倉曎が再びマヌゞされたしたgit merge --no-ff
  5. , .
  6. - , dev .
  7. , ,


結論






gccはGit Extensionsをご芧になるこずを掚奚したした。
borNfreeは、別の゜ヌスツリヌ GUIクラむアントを促したした。
zloylosは、git
olanchegのビゞュアラむザヌぞのリンクを共有し、初心者向けの別のチュヌトリアルを参照するこずを提案したした。

PS。 ハブに最初の投皿をするずき、圌らは通垞䜕を曞きたすか厳しく刀断しないでください、できる限り曞きたした。

Source: https://habr.com/ru/post/J174467/


All Articles