[feature/CI&CD] 브랜치 관리

[rnjstjdgh]

• dev 브랜치와 main 브랜치 2개를 두고
• 개발은 dev에서 하고
• 실 서버에 반영하고 싶으면 main 브랜치에 머지해서 반영하는 전략으로 구성해보자

[rnjstjdgh]

dev 브랜치의 내용을 main 브랜치와 병합하기

• https://backlog.com/git-tutorial/kr/stepup/stepup2_4.html

• dev에서 개발한 내용을 일괄적으로 main으로 머지 후 한방에 push하면 github action에 의해 실 서버에 반영되도록!

[rnjstjdgh]

Use Case

# 1.  dev 브랜치로 이동
    git checkout dev

# 2.  개발 진행.....및 커밋 & dev 브랜치의 github에 push
    git add *
    git commit -m "commit to dev branch"
    git push origin dev
    .....
    git add *
    git commit -m "commit to dev branch"
    git push origin dev
    ...

# 3.  일정 수준 개발한 부분을 실 서버에 반영해야 겠다고 판단되면
    # 3-1) 메인 브랜치로 이동
        git chekout main
    # 3-2) 개발 분 main 브랜치로 머지
        git merge issue1
        git merge issue2
        git merge issue3
    ...
    # 3-3) 로컬에서 마지된 분 github main 브랜치에 반영 => `이때 실 서버에 배포 진행!`
        git push origin main

[rnjstjdgh]

여러 커밋들 한번에 머지하기

• 참고자료:
  • squash: https://backlog.com/git-tutorial/kr/stepup/stepup7_7.html
  • [merge, squash and merge, rebase and merge] : https://im-developer.tistory.com/182

squash를 쓰지 말고 git merge {브랜치 명} 을 통해 머지하자

• 그래야 브랜치 sync가 동일한 곳에서 다시 출발하게 됨
• 동일한 sync에서 출발해야 나중에 충돌이라고 인식하지 않는다.

[rnjstjdgh]

지금까지 결론

1. squash option으로 마지하면

• main 브랜치는 마지가 아니라 그냥 일반 커밋으로 인식되는듯
• 그러니까
  1. dev에서 a.java를 개발 후 main에 squash 병합하면 main입장에서 병합이 아니라 그냥 누가 a.java를 개발해서 커밋한거로 인식됨
  2. 추후 dev에서 a.java를 추가 개발 하고 다시 main에 병합하려 하면 main 입장에서 처음 a.java를 커밋한 분과 지금 커밋한 분이 충돌된다고 인식함

2. squash말고 merge로 병합하자

•