[Git] git no conflict를 너무 믿지 말자

부제: CI/CD 툴 Jenkins, github actions의 중요성

부제 2: 작업 브랜치에 아무리 충돌날만한 게 없다고 생각되더라도 항상 최신 base branch를 반영해주자

 

너무나도 당연한 걸 간과해서 오늘 또 삽질을 했다. 일기장처럼 오늘 삽질한 내용에 대해 적어보려 한다. (지나가던 애기가 깔깔깔 배를 잡으면서 웃을만한 정도로 부끄럽고 바보같은 트러블 슈팅이다.)

 

base branch (develop)에 PR을 하나 머지한 후에, 겹치는 부분이 없다고 생각해서 별도로 작업 브랜치 (feature)에는 pull (fetch merge)해주지 않고 이어서 작업한 후에 PR을 날렸다.

좋아, 테스트도 잘 되고, 실행도 잘 되는 걸 확인했다!

Build Successful도 확인했다!

base 브랜치와 충돌도 없겠다!

이제 작업 끝내고 푹 쉴 생각에 행복해하고 있었는데

빌드가 실패했다고 화내는 젠킨스 할아버지

 

젠킨스 할아버지가 계속 실패했다고 화내는 모습을 볼 수 있었다.

하지만 분명 빌드도 되고, github no conflicts도 뜨고, 실행에도 문제가 없었는데 왜 젠킨스에서만 안된다고 화를 내는걸까?

 

처음에는 Jenkins 할아버지가 결국 치매가 온 줄 알았다.

정말 Jenkins 할아버지가 잘못하신 게 맞은걸까?

---

Git Conflict는 `추가된 부분`이 아닌 `base와 겹치는 부분`과의 충돌이며 빌드 실패와는 아무런 상관 없다는 것을 유의하자

너무나도 당연한 말이지만 git conflict는 base branch와 해당 PR의 겹치는 부분만 체크하고, 추가되는 부분은 conflict를 띄워주지 않는다. no conflict 부분에서 빌드가 실패를 하든, 컴파일 에러가 뜨든 git 입장에선 알 바 아니다.Git Conflicts가 무슨 github actions와 같은 CI 툴도 아니고, 얘가 빌드를 해주진 않는다.

 

난 바보같이 중간에 머지된 PR이 있다는 건 잊어버리고,

base와 no conflict면 머지해도 아무런 문제가 전혀 없을 것! 이라 생각했던 것이다. 

 

근데 구체적으로 어떤 이슈를 겪은걸까?

 

중간에 머지된 PR은 내가 보낸 PR과 다른 작업을 했다고 하자.  내가 작업한 PR과 중간에 머지된 PR은 서로 겹치는 부분이 없다.

(그렇기 때문에 git에서도 conflict 나지 않는다고 말해준 것이다.)

 

그런데 중간에 머지된 PR이 B 파트를 작업하면서 해당 부분의 생성자가 변했다. 하지만 나는 A 파트를 작업하면서 해당 상황을 몰랐고, pull (또는 fetch merge)를 받지 않고 진행했다. 어차피 겹치는 부분도 없을테니 말이다.

 

그러다가 새로운 테스트 코드를 작성하게 됐는데, 그 코드에선 B 파트 쪽에서 변경한 객체의 생성자를 호출한다. 이 과정에서 나는 중간에 머지된 PR의 변경된 생성자를 사용한 게 아닌, 변경 전 생성자를 호출한 것이다.

 

여기서 중요한 것은 이렇게 해도 git conflict는 나지 않는다는 것이다.

문제가 없다고 말하는 깃허브

 

내가 보낸 PR은 origin + A 일 때는 당연히 컴파일도 되고~ 빌드도 되고~ 실행도 될 것이다. 테스트도 다 통과할 것이고. 왜냐면 update base branch에 반영된 B 파트가 내 PR엔 반영되지 않았기 때문!

 

심지어 origin + B + A가 되는 데에 conflict도 없다. base branch에 B 파트가 추가된 부분이랑, 내가 보낸 PR의 A 파트와는 일단 겹치는 부분은 없기 때문! (추가된 부분은 있지만 conflict의 원인이 되진 않는다.)

 

깃허브와 다르게 문제가 있다고 화내는 귀여운 젠킨스 할아버지

 

 

하지만 update base branch는 origin + B 이다. 여기서 A가 추가될 때, A는 B를 모르는 상태로 작업을 했기 때문에 빌드가 성공적으로 되는 것은 다른 문제이다. 깃허브가 빌드 및 테스트를 해주는 것은 아니기 때문. 겹치는 부분이 없어서 conflict는 안나더라도, 추가되는 부분에서 B와 A는 서로 안맞을 수 있다.

 

 

즉, git no conflict를 너무 믿지 말자.

Base branch와의 빌드 및 테스트까지 해주는 Jenkins, Github Actions와 같은 CI/CD 툴의 결과가 더 신뢰성이 높다. 

그리고 웬만해선 작업 브랜치에는 최신 base branch를 반영해주자.

---

너무나도 바보같은 삽질이었지만, CI/CD 툴의 중요성을 느낄 수 있는 좋은 경험이었다.

Jenkins 할아버지가 아니었으면 머지된 develop에서 또 컴파일 에러 발생하고 수정해야 하는 귀찮음보단 나은 거 같기도 하다.

 

삽질 후기 PR은 여기서 볼 수 있다.

https://github.com/woowacourse-teams/2022-nae-pyeon/pull/347

fix: 모임에게 작성하는 롤링페이퍼의 메시지일 경우 비밀 옵션을 걸지 못하도록 수정 by kth990303