Abstract

현재 회사에서 진행하는 프로젝트의 팀원은 6명이다. git을 완벽하게 모른는 신입개발자라면 전부 공감하겠지만 내가 잘못해서 repository를 망치면 어떻게 하지? 라는 걱정을 무조건 해봤을 것이다. 물론 경험에서 나온 이야기이다..

그래서 앞으로 터미널에 git ~~ 를 자신있게 적기 위해 예전에 공부했던 내용들을 상기시켜볼까 한다.
주제는 Merge이고 내가 처음으로 벽을 느꼈던 부분까지 가려면 세단계정도의 과정이 필요할 것 같다.

[Git - Merge] post

• fast forward vs 3 way Merge
• git merge vs git pull origin branch
• git merge vs git rebase

---

fast forward vs 3 way Merge

목차

1. fast-forward란?
2. 3-way Merge란?
3. [cookie] pycharm에서 merge conflict 해결하기

Fast forward

fast forward는 예시를 들자면 당신이 재택근무를 하게 되어 개인 브렌치에서 작업을 한 후 커밋 & 푸시를 했다. 아직 작업이 마치지 않아 다음날 출근해서 다른 노트북으로 그 작업을 이어서 할때 그 브렌치에서 pull을 받을 것 이다.
말로 하면 쉬운것도 어렵기 때문에 아주 완벽한 그림을 가져왔다.

다음과 같이 branch가 같고 head의 타임라인이 다를때 local이 가리키고 있는 b를 d로 옮겨주면 끝이다. 그냥 edge만 바꿔주면 되기 때문에 빠르게 앞으로 땡긴다 해서 fast forward이다.

3 way Merge

협업을 할때 위와 같은 경우는 많지 않다. 보통 feature/working-name 브랜치에서 각자 분기해 working을 함께 끝내고 merge를 하는 경우가 더 많을 것 이다. 아니면 작업을 하다가 main에서 pull 받아주세요~ 하면 아무생각없이 네~ 댕길게요~ 하는 나와같은 사람이 하는 merge가 3 way Merge이다.

말 그대로 3가지의 길을 열고 merge를 하는 방법인데

위와 같은 그림이 있다. (이번에는 자료가 많기 때문에 양심것 구글링)
develop 브렌치에서 작업을 했다. 그런데 협업을 하기 때문에 master가 변경점이 있을 것 이다. 분명 같은 곳을 건들여서 충돌이 날 수도 있을 것이고 충돌이 났는지 안났는지를 확인하기 위해서는 두 브렌치를 두고 diffrence를 비교해야한다. 너무 일반적인 merge 방법이라 설명할건 별로 없을 것 같고 백문이 불여일견

나는 보통 pycharm에서 conflict를 해결하는 편이다.

Example

브렌치를 각각 만들어 같은 곳을 변경해 일부러 conflict를 낸다.

[main branch] > git checkout -b feature/testing1

if __name__ == '__main__':
    uvicorn.run("main:container.app", host="0.0.0.0", port=8000, reload=True)
    print("testing 1 에서 변경된 작업이에용~")

[feature/testing branch] > git checkout -b feature/testing2

if __name__ == '__main__':
    uvicorn.run("main:container.app", host="0.0.0.0", port=8000, reload=True)
    print("testing2 에서 작업했지롱 이거 컨플릭트 나도 어쩔티비 ㅋㅋ")

[feature/testing2 branch] > git merge feature/testing1

conflict result

참고로 conflict가 나야 위에 resolve conflicts 메뉴가 생긴다.

파란 Merge를 클릭하거나 main.py 를 더블클릭해 충돌 처리를 할 수 있다.

이걸 보여주기 위해 지금까지 이 난리를 쳤다.
보면 왼쪽은 testing2, 오른쪽은 testing1 브랜치의 작업이고 가운데는 merge될 3번째 way이다.

TMI를 더 알려주자면 충돌된 부분은 저렇게 갈색으로 같은 라인이 변경되었다고 나온다. 충돌이 안난 각자 브렌치에서의 변경점은 파란색으로 나오는데 화살표를 누르면 적용이 된다. (자동 적용이 아니니 꼭 하나씩 적용을 시켜주거나 위에 Apply non-conflicting changes를 눌러 적용하고 충돌처리를 하자.)
왼쪽아래 Accept Left or Right를 누르면 충돌이고 다 필요없고 그냥 왼쪽 혹은 오른쪽 브렌치로 가겠다는거

result

뒤에 rebase를 이해하기위해 merge하는 방법을 중심으로 블로그를 썼다. 추가적으로 Conflict를 안전하게 처리해야 다른 개발자가 열심히 짠 코드를 망치지 않을 수 있다. pycharm에는 정말 무겁다는 단점이 있지만 그 말은 즉슨 기능이 아주 많은 IDE 이다. 많은 기능을 쓸게 아니라면 VS code에서 필요한 기능만 받아서 유연하게 사용하는것이 훨씬 당신에게 좋을 것 이다.(사실 git에 대한 기능은 VS code extension이 더 잘 해주는 것 같다) 나는 떠먹여주는걸 좋아하기 때문에 잘 만들어준 기능에 숟가락을 얹을 것 이다.. 이번에는 어떤식으로 Merge가 되는지 알았으니 다음번에도 가볍게 git merge vs git pull origin branch의 차이점을 알아보도록 하자.