Gitdə münaqişələrin birləşməsini necə həll etmək olar?

Gedən münaqişələrin həllini necə həll etmək lazım olduğunu izah etmək üçün yaxşı bir yol varmı?

4274
02 окт. Spoike seti 02 oct . 2008-10-02 14:31 '08 at 2:31 pm 2008-10-02 14:31
@ 37 cavab
  • 1
  • 2

Keçin: git mergetool

Hər bir münaqişədən keçən qrafik interfeysini açır və birləşməyi seçə bilərsiniz. Bəzən bu, sonra bir az əl düzəliş tələb edir, lakin adətən özü kifayətdir. Hər şeyi əllə etməkdən daha yaxşıdır.

@JoshGlover şərhinə görə:

Quraşdırmanız yoxdursa komanda mütləq GUI-i açmır. git mergetool üçün git mergetool istifadəsinə gətirib çıxardı. Bunun əvəzinə istifadə etmək üçün aşağıdakı vasitələrdən birini qura bilərsiniz: meld , opendiff , kdiff3 , tkdiff , xxdiff , tortoisemerge , gvimdiff , ecmerge , p4merge , p4merge , araxis , vimdiff , emerge .

Aşağıda vimdiff münaqişələri birləşdirmək üçün istifadə proseduru bir nümunəsidir. Bu linki ilə

Addım 1 : Terminalınızdakı aşağıdakı əmrləri çalıştırın

 git config merge.tool vimdiff git config merge.conflictstyle diff3 git config mergetool.prompt false 

Bu, vimdiff'i standart birləşmə aracı olaraq təyin edəcək.

Addım 2 : Terminaldakı aşağıdakı əmrləri yerinə yetirin

 git mergetool 

Addım 3 : Aşağıdakı formatda bir vimdiff ekranı görəcəksiniz.

  +----------------------+ | | | | |LOCAL |BASE |REMOTE | | | | | +----------------------+ | MERGED | | | +----------------------+ 

Bu 4 növ

LOCAL, mövcud filialdan olan fayldır.

BASE - ümumi bir ata, faylın hər iki dəyişmədən əvvəl necə göründüyü

REMOTE - filialınıza daxil olan bir fayl

MERGED - birləşmənin nəticəsi, repo saxlanılır

ctrl+w istifadə edərək, bu görünüşlər arasında gedin ctrl+w ctrl+wj istifadə edərək birbaşa birləşdirilmiş görünüşə bilərsiniz.

Buradaburada vimdiff naviqasiya haqqında daha ətraflı məlumat .

Addım 4 Siz MERGED-i aşağıdakı kimi düzəldə bilərsiniz.

REMOTE-dən dəyişikliklər almaq istəyirsinizsə

 :diffg RE 

BASE-dən dəyişikliklər almaq istəyirsinizsə

 :diffg BA 

LOCAL'dən dəyişikliklər almaq istəyirsinizsə

 :diffg LO 

Addım 5 Saxla, çıxış, kilidlə və təmizləyin

:wqa saxlamaq və çıxmaq vi

git commit -m "message"

git clean clear diff alət tərəfindən yaradılan lazımsız faylları silin (məsələn, * .orig).

2535
02 окт. Cavab Peter Burns 02 oktyabr tərəfindən verilir . 2008-10-02 20:50 '08 saat 20:50 'da 2008-10-02 20:50

Yuxarıda göstərilən ehtimal bir nümunə:

Bəzi dəyişikliklər edəcəyik, amma təəssüf ki, bilmirsiniz:

 git fetch origin git pull origin master From ssh://gitosis@example.com:22/projectname * branch master -> FETCH_HEAD Updating a030c3a..ee25213 error: Entry 'filename.c' not uptodate. Cannot merge. 

Beləliklə, yeniləmə və yenidən cəhd edin, ancaq bir qarşıdurma var:

 git add filename.c git commit -m "made some wild and crazy changes" git pull origin master From ssh://gitosis@example.com:22/projectname * branch master -> FETCH_HEAD Auto-merging filename.c CONFLICT (content): Merge conflict in filename.c Automatic merge failed; fix conflicts and then commit the result. 

Buna görə dəyişikliklərə baxmağa qərar verdiniz:

border=0
 git mergetool 

Oh, mən, oh, mənim, yuxarı hissələrim dəyişdi, amma dəyişikliklərimi istifadə etmək üçün ... heç ... dəyişikliklər ...

 git checkout --ours filename.c git checkout --theirs filename.c git add filename.c git commit -m "using theirs" 

Və son dəfə cəhd edirik.

 git pull origin master From ssh://gitosis@example.com:22/projectname * branch master -> FETCH_HEAD Already up-to-date. 

Ta-da!

1625
04 авг. CoolAJ86 tərəfindən verilmiş cavab 04 aug. 2010-08-04 20:04 '10 at 08:04 PM 2010-08-04 20:04

Birləşmə vasitələrinin nadir hallarda mənə münaqişənin və qətnamənin anlaşılmasına kömək edir. Mən bir mətn redaktoru içərisində münaqişə markalarında daha çox uğurla baxıram və əlavə olaraq git log istifadə edirəm.

İşdə bəzi məsləhətlər:

Birinci şura

Mən tapdım ən yaxşı birləşmə münaqişəsinin diff3 stilindən istifadə etməkdir:

git config merge.conflictstyle diff3

Bu kimi münaqişə markaları yaradır:

 <<<<<<< Changes made on the branch that is being merged into. In most cases, this is the branch that I have currently checked out (ie HEAD). ||||||| The common ancestor version. ======= Changes made on the branch that is being merged in. This is often a feature/topic branch. >>>>>>> 

Orta hissədə ortaq atanın necə göründüyü. Bu, hər bir dəyişikliyin məqsədi nə daha yaxşı bir fikir verdiyini daha yaxşı başa düşmək üçün üst və alt versiyalarla müqayisə edə biləcəyiniz üçün faydalıdır.

Əgər münaqişə yalnız bir neçə xəttdən ibarətdirsə, bu, bir qayda olaraq, münaqişənin çox açıq olduğunu göstərir. (Münaqişənin necə qurulacağını bilmək çox fərqlidir: başqaları üzərində işləyənləri bilmək lazımdır. Əgər qarışıq olsanız, aradığınız şeyi görə bilərik ki, bu şəxsin otaqda adını çəkmək yaxşıdır).

Münaqişə daha uzun olsaydı, üç hissədən hər birini "mənim", "ümumi" və "bunlar" kimi üç ayrı-ayrı faylya kəsdirib yapışdırdım.

Sonra münaqişəyə səbəb olan iki vəziyyəti görmək üçün aşağıdakı əmrləri işə sala bilərsiniz:

 diff common mine diff common theirs 

Birləşmə aracı bütün qeyri-çakışan fərqlər daxil edəcəyi kimi, bu birləşmə alətindən istifadə etməklə eyni deyildir. Çaşqın hiss edirəm.

Iki ipucu

Biri artıq bunu bəyan etmişdi, ancaq hər bir sözün fərqinin arxasındakı anlayış anlayışı, münaqişənin qaynaqlandığını və onu necə idarə edə biləcəyini anlamaq üçün çox vaxt faydalıdır.

 git log --merge -p <name of file> 

Bu, bu faylın ortaq bir ata və birləşdiyiniz iki kafa arasındakı bütün əməlləri göstərir. (Beləliklə, birləşmədən əvvəl hər iki şöbədə mövcud olan əmrləri əhatə etmir.) Bu, mövcud münaqişələrinizdə açıq-aydın bir faktor olmadığı fərqləri görməməyə kömək edir.

İpucu üç

Dəyişikliklərinizi avtomatlaşdırılmış vasitələrlə yoxlayın.

Avtomatlaşdırılmış testlər varsa, onları işə salın. Bir lint varsa, onu çalıştırın. Əgər tikinti layihəsi varsa, onu tamamlamadan və s. Qurmaq lazımdır. Bütün hallarda, dəyişikliklərinizin pozulmadığından əmin olmaq üçün bir az sınaq əldə etməlisiniz. (Heck, hətta münaqişələr olmadan birləşmə iş kodunu poza bilər.)

İpucu dörd

Öncə planlaşdırın; həmkarları ilə ünsiyyət qururuq.

Əvvəldən planlaşdırma və başqalarının işləməsinin həyata keçirilməsi birləşmə münaqişələrinin qarşısının alınmasına və / və ya əvvəllər həll olunmasına kömək edə bilər - məlumatlar hələ də müvafiqdir.

Məsələn, əgər siz və başqa bir şəxsin eyni fayl dəstinə təsir edəcək müxtəlif refrakterlər üzərində işlədiyini bilirsinizsə, əvvəlcədən bir-birinizlə danışmalı və hər birinizin hansı növ dəyişikliklər etdiyini yaxşı başa düşməlisiniz. Planlaşdırılmış dəyişiklikləri paralel olaraq deyil, həyata keçirirsinizsə, çox vaxt və səy sərf edə bilərsiniz.

Böyük bir kod parçasını keçən böyük refrakterlər üçün ciddi şəkildə işləməyinizi ardıcıl olaraq nəzərdən keçirin: hər kəs bu kod sahəsi üzərində işləməyi dayandırır və bir nəfər tam refaktoring edir.

Əgər müvəqqəti olaraq işləməsiniz (bəlkə də müvəqqəti təzyiqlər səbəbindən), gözlənilən birləşmə münaqişələrindən bəhs etsəniz, ən azı problemləri əvvəllər həll etməyə kömək edərsiniz, halbuki təfərrüatları hələ təzədir. Məsələn, bir həftə ərzində işçi dağıdıcı bir sıra əməllər edərsə, bu filialı bu həftə bir və ya iki dəfə birləşdirmək / yenidən birləşdirmək isteyebilirsiniz. Beləliklə, birləşmə / yönləndirmə münaqişələri taparsanız, hər şeyi birlikdə bir parça halına gətirmək üçün bir neçə həftə gözləməyinizdən daha sürətli həll edə bilərsiniz.

Beş ipucu

Birləşməyinizə əmin deyilsinizsə, onu məcbur etməyin.

Birləşmə xüsusilə çoxlu ziddiyyətli fayllar olduqda və ziddiyyət markerləri yüzlərlə xətti əhatə edərkən böyük ola bilər. Çoğu zaman, proqram layihələrini qiymətləndirərkən, biz crazy birləşmənin işlənməsi kimi əlavə ödənişlər üçün kifayət qədər vaxt vermirik, beləliklə hər bir münaqişəni təhlil etmək üçün bir neçə saat sərf etmək real müqavimət kimi görünür.

Uzunmüddətli perspektivdə, planlaşdırma və başqalarının işəgötürməsi birləşmə münaqişələrini proqnozlaşdırmaq və daha az vaxtda düzgün həllinə hazırlaşmaq üçün ən yaxşı vasitədir.

696
29 сент. Cavab Mark E. Haase 29 sep tərəfindən verilir . 2011-09-29 00:08 '11 'də 0:08' da 2011-09-29 00:08
  • Hansı faylların münaqişədə olduğunu müəyyənləşdirin (Git bunu sizə bildirməlidir).

  • Hər bir faylın açılması və fərqləri öyrənmək; Git onları demarcates. Ümid edirəm ki, hər bir blokun hansı versiyasını saxlamağa çalışacağıq. Bunu kodu tamamlayan digər developers ilə müzakirə etmək məcburiyyətindəsiniz.

  • git add the_file faylında münaqişəni həll etdikdən sonra git add the_file .

  • Bütün münaqişələri həll git rebase --continue davam git rebase --continue və ya başa çatdıqdan sonra hər hansı bir komanda Git.

326
02 окт. Cavab verilir davetron5000 02 oktyabr . 2008-10-02 15:41 '08 at 3:41 pm 2008-10-02 15:41

Cavabları Git Ləğv etmə məsələsində yoxlayın, xüsusilə Charles Bailey'nin Cavabını yoxlayın, bu da bir problem faylının müxtəlif versiyalarını necə keçirəcəyini göstərir, məsələn

100
03 окт. 03 oktyabr tarixində Pat Notz tərəfindən verilmiş cavab 2008-10-03 18:15 '08 saat 06:15 'da 2008-10-03 18:15

Münaqişə birləşməsi eyni zamanda faylda dəyişikliklər edildikdə baş verir. Bunu necə həll etmək olar.

git CLI

Çatışmazlıq halında olduğunuzda çəkmək üçün lazım olan sadə addımlar:

  • Unmerged paths faylların siyahısını qeyd edin: git status ( Unmerged paths bölməsində).
  • Hər bir fayl üçün aşağıdakı yanaşmalardan biri ilə münaqişələrin həlli:

    • git mergetool həll etmək üçün GUI istifadə edin: git mergetool (ən asan yol).

    • Bir uzaqdan / digər versiyanı qəbul etmək üçün, istifadə edin: git checkout --theirs path/file . Bu, bu faylda etdiyiniz yerli dəyişiklikləri rədd edəcəkdir.

    • Yerli / versiyanı qəbul etmək üçün istifadə edin: git checkout --ours path/file

      Lakin, ehtiyatlı olmalısınız, çünki silinən dəyişikliklər bir səbəbdən aradan qaldırılmışdır.

      Müəllif: "Bizim" və "bunları" da tam anlamı nədir?

    • Çatışan faylları əl ilə <<<<< / >>>>> arasında kod blokunu tapın, sonra ===== yuxarıda və ya yuxarı versiyanı seçin. Bax: münaqişələr necə təqdim olunur .

    • Yol və fayl adı münaqişələri git add / git rm ilə həll oluna bilər.

  • Nəhayət, istifadə etmək üçün hazır faylları nəzərdən keçirin: git status .

    Siz hələ də Unmerged paths altında fayllarınız varsa və münaqişəni özünüz həll etsəniz, Git bunu həll etdiyini bilsin: git add path/file .

  • Bütün münaqişələr müvəffəqiyyətlə həll edildikdə, dəyişiklikləri kopyalayın: git commit -a və adi git commit -a basın.

Həmçinin baxın: GitHub komanda satırından birləşmə münaqişəsinin həlli

DiffMerge

Windows, macOS və Linux / Unix fayllarını görsel olaraq müqayisə etmək və birləşdirə biləcək DiffMerge-ni müvəffəq etdilər .

Qrafik olaraq 3 fayl arasında dəyişikliklər göstərilir və avtomatik birləşmə (təhlükəsiz olduqda) və yaranan faylın redaktə edilməsi üzərində tam nəzarət etməyə imkan verir.

2019

05 авг. cavab cənab 05 avqu . 2015-08-05 17:29 '15 'də 17:29' də, 2015-08-05 17:29

Tez-tez kiçik git log --merge ilə şərh git log --merge . Sonra git diff sizə qarşıdurma göstərəcək.

Bir neçə xətt çəkən münaqişələr üçün xarici GUI alətində baş verənləri görmək daha asandır. İstəyirəm opendiff - Git həmçinin vimdiff, gvimdiff, kdiff3, tkdiff, meld, xxdiff, qutudan çıxmaq və digərləri quraşdıra bilərsiniz: git config merge.tool "your.tool" seçdiyiniz git config merge.tool "your.tool" quraşdırır və sonra uğursuz sonra git mergetool birləşmə kontekstində fərqlilikləri göstərəcəkdir.

Bir münaqişəni həll etmək üçün faylı düzəltmək üçün hər dəfə git add filename yeniləmələrini indeksə git add filename və fərqiniz artıq göstərməyəcəkdir. Bütün münaqişələr işləndikdə və onların faylları git add olunduqda, git add təyanı birləşməni tamamlayacaq.

75
02 окт. Cavab Paul 02 oktyabrda verilir . 2008-10-02 19:11 '08 at 7:11 pm 2008-10-02 19:11

Çatışmaların necə təqdim edildiyini və ya Git'te, git merge sənədlərinin sənədləşdirilməsinə baxın.

Bundan əlavə, münaqişələr bölməsinin həlli yolları münaqişələrin həllini necə izah edir:

Münaqişəni gördükdən sonra iki şeyi edə bilərsiniz:

  • Birləşməməyə qərar verin. Sizə lazım olan yeganə təmizləyicilər ters çevirmə üçün HEAD təyin etmək üçün 2-də və 3-də hazırlanmış işçi kəndində dəyişikliklərin aparılması üçün yenidən qurulma indeksi fayllarıdır; git merge --abort üçün istifadə edilə bilər.

  • Çatışmaları həll edin. Git iş ağacında münaqişələri qeyd edəcək. Formada olan faylları redaktə edin və onları git add edin. Müqaviləni bağlamaq üçün git commit istifadə edin.

Bir neçə vasitə ilə münaqişə ola bilər:

  • Mergetool istifadə edin. git mergetool birləşmə vasitəsilə işləyəcək bir qrafik mergetool çalıştırmak.

  • Fərqlərə baxın. git diff , HEADMERGE_HEAD dəyişmələrini vurğulayaraq, üçtərəfli git diff nümayiş etdirir.

  • Hər filial arasındakı fərqlərə baxın. git log --merge -p <path> HEAD versiyası və sonra MERGE_HEAD versiyası üçün ilk MERGE_HEAD .

  • Orijinalə baxın. git show :1:filename ümumi ata göstərir, git show :2:filename HEAD versiyasını göstərir və git show :3:filename MERGE_HEAD versiyasını göstərir.

Birləşmə münaqişəsinin markası və Pro Git Ana Birləşməsi Çatışmalar bölməsində necə həll edəcəyi barədə də oxuya bilərsiniz.

43
14 июля '13 в 21:34 2013-07-14 21:34 cavab 14 iyul 2013 -cü il saat 21 : 34 -da istifadəçi456814 tərəfindən verilmişdir 2013-07-14 21:34

Emacs üçün yarı manuel birləşmə münaqişələrini həll etmək istəyən istifadəçilər:

 git diff --name-status --diff-filter=U 

Çatışmanın həlli tələb edən bütün faylları görüntüler.

Bu faylların hər birini bir-bir və ya bir kerede açın:

 emacs $(git diff --name-only --diff-filter=U) 

Emacs'ta redaktə tələb edən bir tamponu ziyarət edərkən, daxil olun

 ALT+x vc-resolve-conflicts 

Bu üç tampon (mənim, onların və çıxış tamponunu) açacaqdır. "N" (növbəti sahə), "p" (proqnoz sahəsi) düyməsini basaraq gedin. Mənim və ya sahənin müvafiq olaraq çıxış tamponuna kopyalanması üçün "a" və "b" düymələrinə basın. Və / və ya çıxış tamponunu birbaşa düzəldin.

Bitirdiğinizde: "q" düyməsini basın. Emacs, bu tamponu saxlamaq istəsəniz soruşur: bəli. Tampon tamamlandıqda, pəncərədən başlamaq zamanı həll olunduğu kimi qeyd edin:

 git add FILENAME 

Bütün növ tamponlarla işləməyi tamamladı

 git commit 

birləşməni tamamlamaq.

36
23 февр. Cavab verilir 23 fevral. 2013-02-23 02:04 '13 at 2:04 2013-02-23 02:04

Mən ya versiyamı və ya versiyasını tamamilə istəmirəm, ya da fərdi dəyişiklikləri görmək və onların hər birinə qərar vermək istəyirəm.

Mənim və ya onların versiyasını tamamilə qəbul et :

Mənim versiyamı qəbul et (yerli, bizim):

 git checkout --ours -- <filename> git add <filename> # Marks conflict as resolved git commit -m "merged bla bla" # An "empty" commit 

Onların versiyasını qəbul edin (silindi):

 git checkout --theirs -- <filename> git add <filename> git commit -m "merged bla bla" 

Bütün qarşıdurma faylları üçün etmək istəyirsinizsə , işləyin:

 git merge --strategy-option ours 

və ya

 git merge --strategy-option theirs 

Bütün dəyişiklikləri nəzərdən keçirin və fərdi olaraq qəbul edin.

  1. git mergetool
  2. Dəyişiklikləri nəzərdən keçirin və hər biri üçün hər hansı bir versiyanı qəbul edin.
  3. git add <filename>
  4. git commit -m "merged bla bla"

Default olaraq, mergetool əmr satırında işləyir. Mergetool komut satırından istifadə etmək ayrı bir məsələ olmalıdır.

Bunun üçün, məsələn, meld və işləmək üçün görsel bir vasitə qura bilərsiniz

 git mergetool -t meld 

Yerli (bizim), "əsas" və ya "birləşdirilmiş" versiya (birləşmənin cari nəticəsi) və uzaqdan idarə edilənlər açılacaqdır. git mergetool -t meld sonra birləşdirilmiş versiyanı git mergetool -t meld "Faylları birləşdirməyə ehtiyac yoxdur" git mergetool -t meld qədər git mergetool -t meld işə git mergetool -t meld , sonra 3 və 4-cü git mergetool -t meld .

28
29 сент. Cavab Noidea 29 sep tərəfindən verilir . 2016-09-29 16:02 '16 'da 16:02' də 2016-09-29 16:02 'də

Lütfən, birləşmə münaqişələrinin aradan qaldırılması üçün aşağıdakı addımları tamamlayın:

  1. Git Status : Git statusunu yoxlayın

  2. Yamaq dəsti alın: get fetch ( git işinizdən doğru yamağı yoxlayın)

  3. Yerli şöbəni çıxarın (nümunəmdə temp1): git checkout -b temp1

  4. Magistrdən son məzmun çıxarın: go pull --rebase origin master

  5. Mergetool'u çalıştırın, münaqişələri yoxlayın və onları düzəlt ... və uzaq filialdakı dəyişiklikləri mövcud filialla yoxlayın : git mergetool

  6. Statusunu təkrar yoxlayın: git statusu

  7. Mergetool ilə yaradılan lazımsız faylları silin, adətən mergetool uzantı ilə əlavə bir fayl yaradır *. Xahiş edirik, bu dublikatı təkrar edin, yerli dəyişiklikləri düzəlt və faylların düzgün versiyasını əlavə edin. git #your_changed_correct_files əlavə edin

  8. Statusunu təkrar yoxlayın: git statusu

  9. Dəyişiklikləri eyni identifikatora (bu dəyişikliklərin yeni bir ayrı dəsti qarşısını alır) verin : git commit - amend

  10. Magistral şöbəsinə itələyin: gedin (Git deposuna)

28
16 апр. Cavab Chhabilal 16 apr verilir . 2015-04-16 10:02 '15 at 10:02 2015-04-16 10:02

Sadəcə qoyun ki, depolardan birində dəyişikliklər vacib deyil və bütün dəyişikliklərin digər tərəfin lehinə icazə verməsini istəsiniz:

 git checkout . --ours 

depolarınızın lehinə dəyişikliklərə və ya

 git checkout . --theirs 

Başqa və ya əsas deposunun lehinə dəyişikliklərə imkan verir.

Və ya, p4merge birləşmə p4merge , faylları vasitəsilə addım üçün GUI birləşmə aracı istifadə p4merge və ya artıq təyin etdiyiniz ad yazmaq lazımdır.

 git mergetool -t p4merge 

faylın doldurulmasından sonra növbəti birini açmaq üçün saxlamaq və yaxınlaşdırmaq lazımdır.

27
26 янв. 26 yanvarda Məhəmməd Səlim cavab verdi 2016-01-26 20:42 '16 saat 20:42 'da 2016-01-26 20:42

Başqalarının detallı olduğu kimi, münaqişələrin münaqişələri bir neçə yolla düzəldə bilərsiniz.

Hesab edirəm ki, real əsas yerli və uzaq depolarla dəyişikliklərin necə olacağını bilməkdir. Bunun əsas səbəbi izleme filiallarını başa düşməkdir. İzləmə şöbəsini mənim, mənim yerli, faktiki fayl dizimim və mənşə mənsubiyyəti ilə müəyyən edilən "ortada itkin hissə" kimi düşündüm.

Şəxsən mən bundan qaçmaq üçün iki şeyə alışmışam.

Bunun əvəzinə:

 git add . git commit -m"some msg" 

İki çatışmamazlıq nədir -

a) Bütün yeni / dəyişdirilmiş fayllar əlavə edilir və bəzi istenmeyen dəyişikliklər ola bilər.
b) İlk olaraq faylların siyahısını görüntüleyemezsiniz.

Bunun əvəzinə:

 git add file,file2,file3... git commit # Then type the files in the editor and save-quit. 

Bu yolla, hansı faylları daha çox qəsdən müzakirə edirsiniz və siz də siyahıdan keçmək və mesajın redaktorunu bir az daha çox düşünə bilərsiniz. Mən tam ekran redaktorunu -m variantından daha çox istifadə edərkən də mənim mesajlarımı yaxşılaşdırır.

[Update - vaxt keçdikcə, daha çox keçirdim:

 git status # Make sure I know whats going on git add . git commit # Then use the editor 

]

Həm də (və vəziyyətinizə görə daha uyğun), mən qarşısını almaq üçün çalışırıq:

 git pull 

və ya

 git pull origin master. 

потому что pull подразумевает слияние, и если у вас есть локальные изменения, которые вы не хотите объединить, вы можете легко завершить объединенный код и/или слить конфликты для кода, который не должен быть объединен.

Вместо этого я пытаюсь сделать

 git checkout master git fetch git rebase --hard origin/master # or whatever branch I want. 

Вы также можете найти это полезным:

git ветвь, fork, fetch, merge, rebase и clone, каковы различия?

25
ответ дан Michael Durrant 19 апр. '13 в 4:08 2013-04-19 04:08

Бонус:

Говоря о pull/fetch/merge в приведенных выше ответах, я хотел бы поделиться интересным и продуктивным трюком,

git pull --rebase

Эта вышеприведенная команда является самой полезной командой в моей жизни git, которая сэкономила много времени.

Прежде чем нажимать вновь сделанное изменение на удаленный сервер, попробуйте git pull --rebase скорее git pull и ручной merge , и он автоматически синхронизирует последние удаленные изменения сервера (с помощью слияния + слияние) и поместит локальную последнюю фиксацию в вершина в журнале git. Не нужно беспокоиться о ручном вытягивании/слиянии.

В случае конфликта просто используйте

 git mergetool git add conflict_file git rebase --continue 

Найти информацию по адресу: http://gitolite.com/git-pull--rebase

25
ответ дан Sazzad Hissain Khan 25 дек. '15 в 18:24 2015-12-25 18:24

Ответ CoolAJ86 подводит итог всему. Если у вас есть изменения в обеих ветвях в одном и том же фрагменте кода, вам придется выполнить ручное слияние. Откройте файл в конфликте в любом текстовом редакторе, и вы увидите следующую структуру.

 (Code not in Conflict) >>>>>>>>>>> (first alternative for conflict starts here) Multiple code lines here =========== (second alternative for conflict starts here) Multiple code lines here too <<<<<<<<<<< (Code not in conflict here) 

Выберите один из вариантов или комбинацию обоих способов, которым вы хотите новый код, при удалении равных знаков и угловых скобок.

 git commit -a -m "commit message" git push origin master 
22
ответ дан iankit 25 янв. '14 в 19:17 2014-01-25 19:17

Есть 3 шага:

  1. Найти какие файлы вызывают конфликты по команде

     git status 
  2. Проверьте файлы, в которых вы найдете конфликты, помеченные как

     <<<<<<<<head blablabla 
  3. Измените его так, как вы хотите, затем подтвердите с помощью команд

     git add solved_conflicts_files git commit -m 'merge msg' 
18
ответ дан Qijun Liu 23 июня '17 в 17:38 2017-06-23 17:38
 git log --merge -p [[--] path] 

Кажется, что я всегда не работаю для меня и обычно заканчивает отображение каждой фиксации, которая была разной между двумя ветвями, это происходит даже при использовании -- для разделения пути от команды.

Что я делаю, чтобы обойти эту проблему, открыть две строки команд и за один проход

 git log ..$MERGED_IN_BRANCH --pretty=full -p [path] 

а в другом

 git log $MERGED_IN_BRANCH.. --pretty=full -p [path] 

Заменив $MERGED_IN_BRANCH ветвью, я объединил и [path] с конфликтующим файлом. Эта команда будет записывать все коммиты в форме патча между ( .. ) двумя коммитами. Если вы оставите одну сторону пустой, как в командах выше, git будет автоматически использовать HEAD (ветвь, в которую вы сливаетесь в этом случае).

Это позволит вам увидеть, какие коммиты вошли в файл в двух ветвях после их расхождения. Обычно это упрощает разрешение конфликтов.

15
ответ дан Brian Di Palma 11 дек. '14 в 18:19 2014-12-11 18:19

С 12 декабря 2016 года вы можете объединять ветки и разрешать конфликты на github.com

Таким образом, если вы не хотите использовать командную строку или любые сторонние инструменты, предлагаемые здесь из более старых @, перейдите к собственному инструменту GitHub.

Это сообщение в блоге подробно объясняется, но основы заключаются в том, что при объединении двух ветвей через пользовательский интерфейс вы увидите" разрешить конфликты, который приведет вас к редактору, позволяющему справиться с этими конфликтами слияния.

2019

ответ дан maxwell 09 янв. '17 в 22:45 2017-01-09 22:45

Используя patience

Я удивлен, что никто не говорил об урегулировании конфликта, используя patience с рекурсивной стратегией слияния. Для большого конфликта слияния использование patience дало хорошие результаты для меня. Идея состоит в том, что он будет пытаться сопоставить блоки, а не отдельные линии.

Например, если вы изменяете отступ вашей программы, стратегия слияния Git по умолчанию иногда соответствует одиночным скобкам { которые принадлежат разным функциям. Этого избегают с patience :

 git merge -s recursive -X patience other-branch 

Из документации:

 With this option, merge-recursive spends a little extra time to avoid mismerges that sometimes occur due to unimportant matching lines (eg, braces from distinct functions). Use this when the branches to be merged have diverged wildly. 

Сравнение с общим предком

Если у вас есть конфликт слияния и вы хотите увидеть, что другие имели в виду при изменении своей ветки, иногда проще сравнить их ветвь напрямую с общим предком (вместо нашей ветки). Для этого вы можете использовать merge-base :

 git diff $(git merge-base <our-branch> <their-branch>) <their-branch> 

Обычно вы хотите видеть изменения только для определенного файла:

 git diff $(git merge-base <our-branch> <their-branch>) <their-branch> <file> 
14
ответ дан Conchylicultor 30 нояб. '16 в 22:51 2016-11-30 22:51

Я всегда выполняю следующие шаги, чтобы избежать конфликтов.

  • git мастер проверки (придите к мастер-ветке)
  • git pull (обновите свой мастер, чтобы получить последний код)
  • git checkout -b mybranch (закажите новую ветку и начните работу над этой ветвью, чтобы ваш мастер всегда оставался верхом ствола.)
  • git добавить. AND git commit AND git push (на вашей локальной ветке после ваших изменений)
  • git мастер проверки (вернитесь к своему хозяину.)

Теперь вы можете делать то же самое и поддерживать столько локальных веток, сколько хотите, и работать одновременно, просто делая приказ git к вашей ветке, когда это необходимо.

12
ответ дан Chetan 12 февр. '15 в 7:25 2015-02-12 07:25

Если вы хотите объединить ветвь (тест) с мастером, вы можете выполнить следующие шаги:

Шаг 1: Перейти в ветку

 git checkout test 

Шаг 2: git pull --rebase origin master

Шаг 3: Если есть конфликты, перейдите к этим файлам, чтобы изменить его.

Шаг 4: Добавьте эти изменения

 git add #your_changes_files 

Шаг 5: git rebase --continue

Шаг 6: если конфликт все еще существует, вернитесь к шагу 3 снова. Если конфликта нет, сделайте следующее: git push origin +test

Шаг 7: И тогда между тестом и мастером нет конфликта. Вы можете использовать слияние напрямую.

11
ответ дан Haimei 18 авг. '14 в 22:42 2014-08-18 22:42

Конфликты слияния могут возникать в разных ситуациях:

  • При запуске "git fetch", а затем "git merge"
  • При запуске "git fetch", а затем "git rebase"
  • При запуске "git pull" (что фактически соответствует одному из вышеупомянутых условий)
  • При запуске "git stash pop"
  • Когда вы применяете git-патчи (коммиты, которые экспортируются в файлы для передачи, например, по электронной почте)

Вам нужно установить инструмент слияния, совместимый с Git, для разрешения конфликтов. Я лично использую KDiff3, и я нашел это хорошим и удобным. Вы можете скачать его версию для Windows здесь:

https://sourceforge.net/projects/kdiff3/files/

Кстати, если вы устанавливаете Git Extensions, в его мастере настройки есть опция для установки Kdiff3.

Затем настройте git config для использования Kdiff в качестве mergetool:

 $ git config --global --add merge.tool kdiff3 $ git config --global --add mergetool.kdiff3.path "C:/Program Files/KDiff3/kdiff3.exe" $ git config --global --add mergetool.kdiff3.trustExitCode false $ git config --global --add diff.guitool kdiff3 $ git config --global --add difftool.kdiff3.path "C:/Program Files/KDiff3/kdiff3.exe" $ git config --global --add difftool.kdiff3.trustExitCode false 

(Не забудьте заменить путь на фактический путь к исполняемому файлу Kdiff.)

Затем каждый раз, когда вы сталкиваетесь с конфликтом слияния, вам просто нужно выполнить эту команду:

 $git mergetool 

Затем он открывает Kdiff3 и сначала пытается автоматически разрешить конфликты слияния. Большинство конфликтов будут разрешены спонтанно, а остальные нужно исправить вручную.

Вот как выглядит Kdiff3:

2019

ответ дан akazemis 18 июня '16 в 8:29 2016-06-18 08:29

Этот ответ заключается в том, чтобы добавить альтернативу тем пользователям VIM, как я, которые предпочитают делать все в редакторе.


TL; DR

2019

ответ дан Vicente Adolfo Bolea Sánchez 16 окт. '17 в 9:01 2017-10-16 09:01

git fetch
git checkout ваша ветка
git мастер переадресации

На этом шаге вы попытаетесь исправить конфликт, используя предпочитаемый вами вариант IDE

Вы можете перейти по этой ссылке, чтобы проверить ho, чтобы исправить конфликт в файле
https://help.github.com/articles/resolving-a-merge-conflict-using-the-command-line/

git добавить
git rebase - продолжить git commit --amend
git push origin HEAD: refs/drafts/master (нажмите, как черновики)

Теперь все прекрасно, и вы найдете свою фиксацию в геррите

Я надеюсь, что это поможет каждому в решении этой проблемы.

3
ответ дан Baini.Marouane 05 июля '17 в 16:25 2017-07-05 16:25

Попробуйте Visual Studio Code для редактирования, если вы еще этого не сделали. После попытки слияния (и попадания в конфликты слияния).VS код автоматически обнаруживает конфликты слияния.

Это может помочь вам очень хорошо, показывая, какие изменения были внесены в оригинал, и если вы принимаете incoming или

current change (имеется в виду оригинальное перед слиянием) '?.

Это помогло мне, и это может работать на вас тоже!

PS: он будет работать, только если вы настроили git с помощью своего кода и кода Visual Studio.

2
ответ дан Kailash Bhalaki 16 марта '18 в 9:26 2018-03-16 09:26

Gitlense For VS Code

Вы можете попробовать Gitlense для VS Code, ключевые характеристики которого:

3. Легко разрешать конфликты.

Мне уже нравится эта функция:

2019

ответ дан Ilyas karim 05 янв. '19 в 21:33 2019-01-05 21:33

Я следую нижеописанному процессу.

Процесс устранения конфликта слияния:

  • Сначала вытащите последнюю из ветки назначения, к которой вы хотите объединить git pull origin develop

  • По мере того, как вы получаете последнее сообщение от адресата, теперь разрешите конфликт вручную в среде IDE, удалив лишние символы.

  • Сделайте git add , чтобы добавить эти отредактированные файлы в очередь git, чтобы она могла быть commit и push той же ветки, над которой вы работаете.

  • Как git add , выполните a git commit , чтобы зафиксировать изменения.

  • Теперь переместите изменения в рабочую ветвь на git push origin HEAD

Это он, и вы увидите, что он разрешен в вашем запросе на pull, если вы используете Bitbucket или GitHub.

1
ответ дан Aniruddha Das 14 окт. '17 в 0:49 2017-10-14 00:49

Если вы используете intelliJ как IDE Попробуйте объединить родителя с веткой на

 git checkout <localbranch> git merge origin/<remotebranch> 

Он отобразит все конфликты вроде этого

A_MBPro: test anu $ git слияние источника/автоматическое слияние src/test/java/com/.../TestClass.java CONFLICT (содержание): Объединить конфликт в SRC/тест/Java/COM/.../TestClass.java

Теперь обратите внимание, что файл TestClass.java отображается красным цветом в intelliJ Также статус git будет показывать

 Unmerged paths: (use "git add <file>..." to mark resolution) both modified: src/test/java/com/.../TestClass.java 

Откройте файл в intelliJ, он будет иметь разделы с

  <<<<<<< HEAD public void testMethod() { } ======= public void testMethod() { ... } >>>>>>> origin/<remotebranch> 

где HEAD - это изменения в локальной ветке, а origin/- изменения в удаленной ветке. Здесь держите нужные вещи и удаляйте ненужные вещи. После этого должны выполняться обычные шаги. Odur

  git add TestClass.java git commit -m "commit message" git push 
1
ответ дан AJC 11 июля '17 в 19:23 2017-07-11 19:23

Для тех, кто использует Visual Studio (2015 в моем случае)

  • Закройте свой проект в VS. Особенно в больших проектах VS, как правило, увлекается слиянием с использованием пользовательского интерфейса.

  • Сделайте слияние в командной строке.

    git checkout target_branch

    git merge source_branch

  • Затем откройте проект в VS и перейдите в Team Explorer → Branch. Теперь есть сообщение, в котором говорится, что Merge находится в ожидании, и конфликтующие файлы перечислены прямо под сообщением.

  • Нажмите конфликтующий файл, и у вас будет возможность объединить, сравнить, взять источник, принять цель. Инструмент слияния в VS очень прост в использовании.

1
ответ дан Mike 10 июля '17 в 23:29 2017-07-10 23:29

Если вы не хотите использовать какой-либо сторонний или графический инструмент, выполните шаги, указанные в этих документах, чтобы разрешить конфликты слияния.

https://githowto.com/resolving_conflicts

https://confluence.atlassian.com/bitbucket/resolve-merge-conflicts-704414003.html

0
ответ дан Always_Beginner 02 дек. '17 в 20:53 2017-12-02 20:53
  • 1
  • 2

Другие вопросы по меткам или Задайте вопрос