GitNotes.8-4.md
본 문서는 Git Notes for Professionals (라이센스:CC-BY-SA) 를 한글로 번역한 문서입니다. 번역상 오류가 있을 수 있으므로 정확한 내용은 원본 문서를 참고하세요.

Section 8.4: Merge 를 커밋을 생성하여 수행하기

가능한 경우, merge 의 기본 동작은 별도의 커밋을 생성하지 않고 브랜치의 포인터만 업데이트 하는 방식인 fast-forward 를 수행하게 되어 있다. 항상 merge 커밋을 생성하도록 강제하고 싶다면 --no-ff 옵션을 사용한다.

git merge <branch_name> --no-ff -m "<commit message>"

[출처] https://books.goalkicker.com/GitBook/ (CC BY-SA)

반응형
GitNotes.8-3.md
본 문서는 Git Notes for Professionals (라이센스:CC-BY-SA) 를 한글로 번역한 문서입니다. 번역상 오류가 있을 수 있으므로 정확한 내용은 원본 문서를 참고하세요.

Section 8.3: 진행중이던 merge 작업 취소하기

merge 작업을 시작한 이후, 진행하고 있던 merge 작업을 중지하고 모든 파일들을 merge 직전의 (pre-merge) 상태로 되돌리고 싶을 수 있다. 이러한 경우에는 --abort 옵션을 사용한다:

git merge --abort

역주: 위 옵션은 merge 가 완료된 이후에는 수행할 수 없으며, merge 시도를 하였지만 merge conflict 이 발생하였을 때 이용하면 편리합니다.

[출처] https://books.goalkicker.com/GitBook/ (CC BY-SA)

반응형
GitNotes.8-2.md
본 문서는 Git Notes for Professionals (라이센스:CC-BY-SA) 를 한글로 번역한 문서입니다. 번역상 오류가 있을 수 있으므로 정확한 내용은 원본 문서를 참고하세요.

Section 8.2: 이미 merge 완료된 원격 브랜치들 찾기

이따금씩 모든 변경사항들이 이미 master 브랜치에 merge 되었지만 정리되지 않고 남아있는 브랜치들을 발견할 수 있다.

아래 명령어는 origin 의 master 브랜치가 아니면서 로컬의 master 브랜치와 비교했을 때 merge 되지 않은 고유한 커밋을 가지고 있지 않은 모든 원격 브랜치들을 검색한다.

이는 PR (pull request) 가 이미 master 로 merge 된 이후 원격에서 삭제되지 않은 브랜치들을 검색할 때에 편리하게 이용할 수 있다.

for branch in $(git branch -r) ; do [ "${branch}" != "origin/master" ] && [ "${branch}" != "->" ] && [ $(git diff master...${branch} | wc -l) -eq 0 ] && echo -e `git show --pretty=format:"%ci %cr" $branch | head -n 1`\\t$branch done | sort -r

역주: '->' 검사 부분은 원문에는 없었으나 직접 테스트시 에러가 발생하는 것을 발견하여 임의로 추가하였습니다. 또한 현 상태로 실행할 경우 항상 origin/HEAD 도 검출 내역에 표시되나, 이 부분은 따로 수정하지 않았음을 유의하시기 바랍니다.

[출처] https://books.goalkicker.com/GitBook/ (CC BY-SA)

반응형
GitNotes.8-1.md
본 문서는 Git Notes for Professionals (라이센스:CC-BY-SA) 를 한글로 번역한 문서입니다. 번역상 오류가 있을 수 있으므로 정확한 내용은 원본 문서를 참고하세요.

Section 8.1: 자동으로 머지가 완료되는 경우

두 브랜치의 커밋들이 서로 충돌하지 (conflict) 않는다면, Git 은 자동으로 두 브랜치를 merge 해줄 것이다:

~/Stack Overflow(branch:master) » git merge another_branch Auto-merging file_a Merge made by the 'recursive' strategy. file_a | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[출처] https://books.goalkicker.com/GitBook/ (CC BY-SA)

반응형
GitNotes.8-0.md
본 문서는 Git Notes for Professionals (라이센스:CC-BY-SA) 를 한글로 번역한 문서입니다. 번역상 오류가 있을 수 있으므로 정확한 내용은 원본 문서를 참고하세요.

Chapter 8: Merge 하기

파라미터 설명
-m merge 커밋에 포함될 메시지를 기술한다
-v 상세 출력 (verbose) 옵션을 활성화한다
--abort merge 작업에 의해 변경된 모든 파일들을 원래 상태로 되돌린다
--ff-only merge-commit 이 새로 생성되어야 하는 경우에는 작업을 취소한다 (fast-foward merge 만 수행한다)
--no-ff 꼭 필요하지 않은 경우에라도 merge-commit 생성을 강제한다
--no-commit merge-commit 생성이 필요한 경우, 생성 직전에 merge 작업의 결과를 출력하고 진행을 취소하여 결과를 미리 확인할 수 있게 한다
--stat merge 작업 결과를 diffstat 형태로 출력한다
-n/--no-stat diffstat 을 출력하지 않도록 지정한다
--squash merge 작업 내역 전체를 (여러 커밋에 해당하는 변경사항일지라도) 한 커밋으로 squash 할 수 있도록 index 에 추가한다

[출처] https://books.goalkicker.com/GitBook/ (CC BY-SA)

반응형
GitNotes.7-6.md
본 문서는 Git Notes for Professionals (라이센스:CC-BY-SA) 를 한글로 번역한 문서입니다. 번역상 오류가 있을 수 있으므로 정확한 내용은 원본 문서를 참고하세요.

Section 7.6: 일련의 커밋들을 한꺼번에 되돌리거나 다시 적용하기

만약 여러개의 연속된 커밋들을 되돌리면서 그 중에 몇개의 커밋은 유지하고 싶은 경우, 아래와 같은 작업을 수행한다:

git rebase -i <rebase를 시작할 기준 커밋 SHA>

-i 옵션은 rebase 를 "대화형 (interactive) 모드" 로 동작하게 해 준다. rebase 수행에 따른 실제 커밋을 replay 적용하기 직전에, 앞으로 replay 될 각각의 커밋들에 대해 수행할 작업을 신택할 수 있도록 잠시 rebase 작업을 멈추게 된다.

rebase -i 수행시 아래와 같이 적용될 커밋들과 각 수행할 작업 목록을 편집할 수 있도록 사용자의 기본 편집기에 표시하여 줄 것이다:

commit_list

커밋을 제거하고 싶다면, 간단히 해당 라인을 편집기에서 삭제하기만 하면 된다. 위 그림에 표시된 예제에서, 잘못된 커밋들을 프로젝트에서 제거하고자 한다면 1 번 라인과 3-4 번 라인을 삭제하면 된다. 만약 두개의 커밋을 하나로 합치고자 한다면, squashfixup 명령을 아래와 같이 기입하여 준다.

rebase_commands

[출처] https://books.goalkicker.com/GitBook/ (CC BY-SA)

반응형

'번역 > Git Notes for Professionals' 카테고리의 다른 글

8.1: 자동으로 머지가 완료되는 경우  (0) 2019.10.10
8: Merge 하기  (0) 2019.10.02
7.5: 기존 커밋들 되돌리기  (0) 2019.10.01
7.4: merge 작업 되돌리기  (2) 2019.09.30
7.3: reflog 활용하기  (0) 2019.09.20
GitNotes.7-5.md
본 문서는 Git Notes for Professionals (라이센스:CC-BY-SA) 를 한글로 번역한 문서입니다. 번역상 오류가 있을 수 있으므로 정확한 내용은 원본 문서를 참고하세요.

Section 7.5: 기존 커밋들 되돌리기

git revert 를 이용하면 기존 커밋들을 되돌릴 수 있으며, 이는 특히 원격 저장소에 해당 커밋들이 이미 push 된 경우 더욱 유용하다. 이 작업은 기존 커밋의 효과를 되돌리는 새로운 커밋을 생성하게 되며, 이를 통해 history 를 덮어쓰지 않고도 안전하게 원격 저장소에 되돌린 결과물을 push 할 수 있게 된다.

git push --force 을 통해 history 를 덮어쓰는 행위는 해당 저장소를 사용하는 다른 사용자들로부터 항의를 받을 수 있는 위험한 행위이므로 절대 이러한 작업을 수행해서는 안된다.

만약, 방금 push 한 커밋에 버그가 있는 것을 발견하여 해당 커밋을 바로 되돌리고 싶다면, 아래와 같이 수행하도록 한다:

git revert HEAD~1 git push

이 작업 이후, 로컬에서 위 revert 커밋을 다시 revert 한 다음, 문제점을 수정한 후에 정상 동작하는 코드를 push 하도록 한다:

git revert HEAD~1 수정 .. 수정 .. 수정 .. git add -A . git commit -m "Update error code" git push

만약 revert 하고자 하는 커밋이 history 상에서 이후에 추가된 다른 커밋들에 뒤덮여 있다면 (HEAD~1 로 지정할 수 없다면), 커밋 해시값을 지정해서 revert 를 수행할 수도 있다. Git 은 해당 커밋을 되돌리는 counter-commit 을 생성해 줄 것이고, 이를 원격 저장소에 안전하게 push 할 수 있다.

git revert 912aaf0228338d0c8fb8cca0a064b0161a451fdc git push

[출처] https://books.goalkicker.com/GitBook/ (CC BY-SA)

반응형
GitNotes.7-4.md
본 문서는 Git Notes for Professionals (라이센스:CC-BY-SA) 를 한글로 번역한 문서입니다. 번역상 오류가 있을 수 있으므로 정확한 내용은 원본 문서를 참고하세요.

Section 7.4: merge 작업 되돌리기

원격 저장소에 아직 push 되지 않은 merge 작업 되돌리기

만약 merge 작업을 수행하긴 하였지만 원격 저장소에 아직 push 를 하지 않은 상태라면 아래에 소개된 일반적인 커밋 되돌리기와 유사한 과정을 통해 merge 작업을 되돌릴 수 있다.

reset 을 이용한 방법은 merge 커밋 자체와 해당 커밋 이후 브랜치에 추가된 모든 커밋들을 되돌리기에 가장 간단한 방법이다. 그러나, 이렇게 reset 을 하려면 되돌아갈 대상 커밋의 SHA 해시값을 알아야 하는데, git log 의 결과는 merge 한 두 브랜치 모두의 커밋 목록을 보여주기에 되돌아가고자 하는 정확한 커밋을 알아내기가 어려울 수 있다. 만약 잘못된 커밋을 지정하여 reset 을 수행한다면 (예: 되돌아가고자 하는 브랜치가 아닌 merge 의 대상이 되었던 브랜치의 커밋을 지정한다던가) 이전에 커밋하였던 작업 내역이 유실될 수 있다.

git reset --hard <작업 중이던 브랜치의 마지막 커밋>

혹은, 만약 되돌리고자 하는 merge 커밋 자체가 가장 최근에 추가된 커밋이라면:

git reset HEAD~

revert 를 이용하는 방법은 이미 커밋된 어떠한 작업도 무효화하지 않는다는 점에서 더욱 안전한 방법이나, 이후에 해당 브랜치와의 merge 를 다시 수행하고 싶다면 revert 한 커밋을 다시 revert 해야 한다는 점에서 추가적인 작업이 더 필요한 방법이기도 하다 (아래 섹션을 참고하라).

원격 저장소에 push 완료된 merge 작업 되돌리기

아래와 같이 'add-gremlins' 라는 새로운 feature 를 추가하는 상황을 고려해보자

git merge feature/add-gremlins ... # merge conflict 을 해결한다 ... git commit # merge 작업을 커밋한다 ... git push ... 501b75d..17a51fd master -> master

역주: gremlin 을 사전에서 찾아보면 다음과 같이 정의되어 있습니다 - 그렘린(기계에 고장을 일으키는 것으로 여겨지는 가상의 존재)

이 작업 이후에, merge 를 수행한 feature 가 다른 개발자들의 시스템 상에서 문제를 일으키는 것으로 밝혀진 경우, 실제 문제를 수정하기에는 시간이 걸리므로 아래와 같이 우선적으로 merge 작업 자체를 되돌릴 수 있다.

git revert -m 1 17a51fd ... git push ... 17a51fd..e443799 master -> master

이 시점에서는 시스템에 문제를 일으켰던 feature 가 원격 저장소에서 제외되어 다른 개발자들의 시스템이 다시 정상 동작하기 시작할 것이다. 이제 add-gremlins feature 의 문제를 해결한 후 다시 merge 를 수행하기 위해서는, 위 revert 작업을 되돌릴 필요가 있다.

git checkout feature/add-gremlins ... # 문제 해결을 위한 커밋을 이 시점에 추가한다. git checkout master ... git revert e443799 ... git merge feature/add-gremlins ... # 문제 수정으로 인해 새로이 발생한 merge conflict 을 해결한다 ... git commit # merge 작업을 커밋한다 ... git push

이 과정을 마치면 해당 feature 가 성공적으로 다시 추가되었을 것이다. 그러나, 이러한 버그들이 주로 merge conflict 으로 인해 발생하는 경우가 많다는 점을 고려하면, 아래와 같이 feature 브랜치에서 master 를 merge 한 후 문제를 해결하는 작업 순서를 따르는 것이 더 유용할 때가 있다.

git checkout feature/add-gremlins ... # master 브랜치를 merge 한 후 바로 이전 revert 작업을 revert 한다. # 이 작업을 통해 이전에 master 에 문제가 생겼던 상태와 동일한 상태를 만들수 있다. git merge master ... git revert e443799 ... # 이제 발생한 문제를 해결한다 (여러 커밋이 이 시점에서 추가될 수 있다) git checkout master ... # revert 작업을 revert 하는 것은 위에서 수행 하였기에 이 시점에서는 필요하지 않다 git merge feature/add-gremlins ... # 문제 수정으로 인해 새로이 발생한 merge conflict 을 해결한다 git commit #commit the merge ... git push

[출처] https://books.goalkicker.com/GitBook/ (CC BY-SA)

반응형

+ Recent posts