https://jhyeok.com/vscode-git-graph/
회사 팀장(리드)님이 주로 소스트리를 사용하셨고 주변에서 소스트리 등을 사용하는 것을 많이 봐왔었는데,
생활코딩님의 git conflict 영상을 보다 git graph라는게 있다는 것을 보게 됐고 별도 GUI 프로그램 설치없이 활용할 수 있다는 장점이 있는 것 같아서 찾아보았다. 결론은 git graph를 써볼만하다는 것이었고 맨처음 빼고는 현재까지는 이런 도구를 활용할 만한 기회가 많지는 않았지만 다음부터는 브랜치 구조를 봐야할 기회가 생긴다면 해당 툴을 한번 활용해볼 예정이다.
https://www.youtube.com/watch?v=wVUnsTsRQ3g
현업에서 conflict를 겪지 않을 수 없는데 구체적으로 revert, rebase 를 주로 사용했었으나
구체적으로 정리한적이 없었고 3 way merge가 무엇인지 알아두면 좋을 것 같아서 노트에 적는겸 글을 정리하게 되었다.
첫째로 3way merge는 깃에서 머지시 브랜치들을 비교해 병합하는 방법이라고 할 수 있을 것 같다.
예를 들면 main에서 서로 다른 브랜치가 분할해서 나왔을때 그 브랜치들을 merge하게 된다면 이들은 브랜치의 변경사항들을 비교하기 위해 공통 조상(부모)인 main을 찾게되고, main과 비교하여 양쪽의 변경사항이 있는지 비교하게 된다.
그렇게 비교했을때 어느 한쪽만 변경되었다면 그 사항을 적용하고, 양쪽다 변경되었다면 git 자체가 해결할 수 없는 문제로 판단하여 수정해달라는 요청으로 conflict를 발생시킨다. 이에 따라 수정사항을 정해 해당 라인을 git add 하고 git commit하면 충돌이 해결되게 된다.
두번째로 cherry-pick은 부분 병합으로 이전 커밋과 비교해 변경된 사항만 특정 다른 브랜치와 비교해 해당 사항을 적용시키고자 하는 과정이다. 주로 특정 다른 브랜치의 커밋을 현재 브랜치나 특정 브랜치에 반영하고 싶을 때 사용한다고 한다.
이 경우 변경사항을 가져오고 싶은 브랜치의 이전 커밋과 해당 커밋, 그리고 반영하고자 하는 브랜치와 비교해 3way merge를 진행하고-(단일 커밋뿐 아닌 여러개 커밋 사용도 가능하다 https://hbase.tistory.com/141)
머지와 구체적으로 다른 점을 고민해보았는데 머지의 경우 공통조상과 비교해 달라진 점들을 비교하지만
체리픽의 경우 반영하고자 하는 시작 커밋이전 커밋으로부터 비교해 반영하고자 하는 내용이 아닌 곳은 적용타겟 브랜치를 우선 적용하고 반영하고자 하는 내용이 커밋이전과 동일하면 반영내용을, 그렇지 않고 변경사항이 있다면 충돌이 나는 구조라는 게 다르기 때문에 방향성이(from->to) 정해져 있다는 것과 특정 반영하고 싶지 않은 사항들 또한 걸러낼 수 있다는게 크게 다른 점인 것 같다. 또한 충돌시 git add 후 git cherry-pick -continued를 적용해줘야 적용이 완료된다.
세번째로 rebase는 특정 다른 브랜치의 적용사항을 특정 브랜치의 마지막 commit을 시작으로 그 뒷부분에 연결되도록 만들어주는 것이다. 영상에서는 일렬로 만들어주는 것이다라고 표현하는데 마치 다른 브랜치의 적용사항을 반영하고자 하는 브랜치의 커밋들에 연결되서 적용된 것처럼 적용해 뒤로 연결시켜서 만들어주는 것이다. (타겟브랜치의 이전 커밋들이 적용되서 연결되어지는 작업이 반영됨)
충돌시 수정사항 반영후 git rebase --continue를 적용하거나 취소를 원한다면 git rebase --abort를, 스킵을 원한다면 git rebase --skip을 사용할 수 있다.
마지막으로 git revert는 우리가 취소한 작업을 병합하는 것이다. 체리픽과 같은데 작업내용은 반대이다.
특정 커밋의 반영사항을 취소하여 병합하고 뒤에서도 해당 라인에 작업이 있을시 conflict가 발생할 수 있다.
이렇게 가끔 사용하는 깃 작업과 헷갈릴 수 있는 사항을 정리해봤는데 시간이 될때 다음에는 특정 브랜치에서 내 작업브랜치를 파생시키고 작업을 하고 있는중 다른 분이 해당 브랜치에서 파생한 다른 브랜치에서 작업한 내용을 내 작업 브랜치에 업데이트해주고 싶을때 (예를 들면 develop브랜치에서 파생한 브랜치에 작업하고 있고 다른 분들이 develop에서 파생한 작업한 내용들을 develop에 머지했는데 해당 업데이트한 내용을 내 작업 브랜치에 반영하고 싶을때) 어떤 것들을 활용할 수 있는지 정리해봐야겠다. (보통은 git pull origin을 통해 develop를 업데이트 해주고 내 작업내용을 rebase로 이어주는 방식을 사용했다.)
'Git' 카테고리의 다른 글
깃헙에서 공식적으로 공개한 git 공부 curriculum (0) | 2022.06.20 |
---|---|
git author 변경하기 (0) | 2021.12.29 |
github에 잘못 올라간 파일 삭제하기. (0) | 2021.12.29 |
원격 저장소에 올라간 커밋 되돌리기 (0) | 2021.12.29 |