25.02 글로만 본 깃 정책의 재미난 경험

소프트웨어 개발을 진행하는 사람은 깃이라는 오픈소스를 사용해보지 않은 사람은 없을 것이다.

나도 그동안 일반적으로  git > commit > merge > pull /fetch > sync/push  작업만 주로했었고 아직도

그러하다.

이번 프로젝트를 진행하면서 재미난 일을 격어서 정리한다.

 

해당 글은 기본적으로 깃을 사용해본 경험이 있는 분을 기준으로 한다.

 

이해를 돕기 위해 ( A : master , B : new-branch, C : new-branch)

A작업 B자업 C작업이 존재했다.

 

니즈가 있어서 C작업을 B에 합쳐서 특정 파일을 생성해줘야 하는 일이 있었다.

이후 C 작업물이 먼저 A(master)에 올라갔으며 이후 B가 A(master)에 올라가는 상황에서 이슈가

발생했다.

 

master에는 없는 코드가 내 작업 브랜치에 commit으로 남아있던 것이다...

해당 파일을 트래킹 해보니 C를  B에 합치면서 들어온 코드이다.

 

그럼 B가 master에 올라가면서 해당 이슈가 된 코드가 삭제된 기록도 남아서 내 코드에 merge되면서 삭제

또는 conflict가 발생했어야 하는것 아닌가?

 

결론부터 이야기하자면 git은 일을 잘 하고 있었다.

 

현재 우리 회사의 git 정책이 squash and merge 로 작업 되고 있다.

위에서 언급한 merge가 발생하면서 삭제 또는 conflict가 발생하기 위해서는

Merge  정책을 가져가야 한다.

 

하지만 현재 회사의 정책은 squash and merge 라는 사실... 이는 결국 여러개의  commit이 하나의  commit으로

합쳐지는 정책을 사용하고 있다.

이로 인하여 master에 올라간 이슈 코드는 삭제 되어서 이슈가 없었고 B 작업물에 merge 하는 상황에서도

다른 충돌이 아지 않았던 것이다.

 

개발을 하다보면 진행중인 동료의 코드를 중간에 받아서 작업을 이어 나아가야하는 상황들이 존재한다.

그럴때 현회사의 git 정책을 고려해서 작업하면 좋을것 같다 ㅎㅎ

 

만약에 squash and merge 을 사용한다면 중간에 병합한 깃이 master에 올라가기 직전 상태 코드를

한번더 병합 받는게 좋을것 같다

 

 

정말 하필 반영 날짜 직정에 이걸 발견해서 고생했