VIM을 사용하여 git 병합 충돌 해결

너는 충돌이 발생하기를 희망할 것이다

사진은 pexels가 촬영했다.일반 도메인 이름 형식
.
이 줄들은 VIM으로 썼고, 내가 쓴 줄마다 코드도 이렇다.
Git는 거의 모든 기술자의 통합 도구가 되었고 merge-conflicts 통상적으로 작업의 일부분이다.

Conflicts generally arise when two people have changed the same lines in a file…
In these cases, Git cannot automatically determine what is correct.
Conflicts only affect the developer conducting the merge, the rest of the team is unaware of the conflict.
Git will mark the file as being conflicted and halt the merging process.
It is then the developers’ responsibility to resolve the conflict.
— Atlassian Git Tutorials

git 충돌을 해결하는 것은 시종 개인의 장애이다.HEAD에서 통합/변경 사항을 취소하지 않고 무시하려고 하거나 다른 해커 솔루션을 무작위로 찾았습니다.
일단 내가 충돌이 발생한 사실을 받아들인다면, 나는 다시 위치를 정하고, 심지어는 나의 합병 기본값을 git merge --rebase 로 설정하여 모든 충돌을 없앨 것이라고 생각한다.
그러나 재정립이 충돌에서 멀어지지 않는다는 사실이 증명된다.rebase는 목표 지점의 맨 위에 제출을 적용합니다.
따라서 재설정 기초는 일반적으로 처리해야 할 충돌을 도입한다git merge --continue .

도주로

Vim Fugitive is an awesome plugin유.
그것의 좋은 특징은 Gstatus와 Gdiff입니다. 프로젝트의 상태와 차이를 볼 수 있습니다. 마치 터미널이나 가장 좋아하는git인터페이스에서gitstatus와gitdiff를 사용하는 것과 같습니다.
VIM 내부에는 이러한 충돌을 처리하는 매우 매끄러운 방법이 있다.충돌 파일을 편집할 때 Gdiff를 사용하면 Survious는 현재 작업공간 파일을 중심으로 삼방향 차이를 시작합니다.두 개의 새 버퍼가 나타납니다. 하나는 대상 브랜치 (즉, 병합 중인 브랜치) 이고, 다른 하나는 병합 브랜치 (병합 중인 브랜치) 입니다.
이전 개념을 검증합니다. 만약에 제가 마스터를 사용하고 있고 staging를 통합하고 싶다면gitmergestaging을 실행할 것입니다.
이런 상황에서 마스터는 목표 지점이고,staging은 합병 지점이다.
이 용어는 충돌을 해결하기 위해 어떤 버퍼를 선택할지 명확하기 때문에 뒤의 참고에 매우 중요하다.
Here’s an excellent video은Drew Niel을 통해 상기(실제 VIM)를 설명합니다.

또 무슨 할 말이 있습니까?

위의 방법은 불편한 버퍼 시스템과 따르기 어려운 명령 (예를 들어diffput나diffget) 을 사용하여 이루어진다. 버퍼 이름 인용을 계산하려고 할 때 이 명령들은 나에게 아무런 의미가 없다.물이 잘 흐르지 않아서 나는 무엇이 좀 부족하다고 생각한다.
나의 문제를 해결하기 위해서 나는 몇 개의 별명을 사용하여 나에게 집적했다.vimrc는 충돌 해결을 유쾌하고 순조롭게 하는데 가장 중요한 것은 직관이다.나는 내가 무엇을 하고 있는지 생각하고 싶지 않다. 나는 하고 싶다.그 밖에 나는 그것이 내가 본 그 어떤 다른 똑같은 일을 하는 도구보다 더 빠르고 빠르기를 바란다. 왜냐하면 그것은 복잡성과 직관적이지 않은 과정을 없애기 때문이다.

내 추가

우리 나의 나에 대한 첨가를 되돌아봅시다.vimrc와 충돌을 해결할 때 유용해지는 방법:

" Fugitive Conflict Resolution
nnoremap <leader>gd :Gvdiff<CR>
nnoremap gdh :diffget //2<CR>
nnoremap gdl :diffget //3<CR>

상기 세 개의 선은 충돌을 쉽게 해결하는 데 필요한 전부이다.
먼저 <leader>gd 를 입력하십시오. git diff 에서 보듯이 이 세 방향 분할 화면이 생성됩니다.매핑에서 수직 분할 창 Gvdiff 을 사용합니다.수평 보기를 선호한다면 v:Gdiff를 제거하십시오.
다음은 모양입니다.
Git 3소켓 차속기
중심 창은 현재 작업 영역이고 왼쪽은 HEAD입니다. 이 옵션을 선택하면 코드가 어떻게 되고 오른쪽은 주 지점 상태를 설명합니다.
머리의 변화를 결정하기 위해 제 맵에 따라 gdh를 입력하면 gd는gitdiff를 대표하고 h는 VIM의 왼쪽 키입니다.이 시퀀스에서 리더키를 삭제하려고 합니다. 내부 프로세스 조합이기 때문입니다.
마스터를 선택하면 현재 작업공간이 다음과 같이 변경됩니다.gdh 왼쪽 뒤의 작업공간 창 선택
주의, 왼쪽 하단의 실제 명령 언급:diffget //2 이것은 도주범이 버퍼에서 변경 사항을 가져오는 방식으로 그 이름은 //2이다.
이 프로세스를 완벽하게 보완하려면 다음과 같이 하십시오.

다음git hunk(또는 복구할 충돌)로 넘어가면 [c 뒤로 또는 ]c 앞으로 검색

을 통해 완료할 수 있습니다

자신의 업무 환경에 만족할 때(통상적으로 모든 충돌이 해결될 때), 이 창만 열 때가 되었다.이를 위해 <C-w>o 를 사용할 수 있습니다. VIM의 창 관리자는 현재 창만 유지합니다.

그게 다야.
습관이라는 서열은 생활 속의 충돌을 더욱 쉽게 해결할 수 있는 쉬운 일이다.
저는 Omer라고 합니다. ProdOps의 엔지니어입니다. 이것은 글로벌 컨설팅 회사입니다. DevOps 문화를 이용하여 신뢰할 수 있고 안전하며 간단한 방식으로 소프트웨어를 제공합니다.아래 댓글에서 당신의 생각을 알려주거나 트위터에 직접 연락하세요.만약 네가 박수치기를 좋아한다면, 그것은 내가 미래의 창작에 전념하는 것을 도울 수 있다.