코딩하는 두꺼비

학교에선 Github을 사용하다가 회사를 다니며 Gitlab을 쓰다보니 PR과 MR 단어를 같이 쓰지만 무엇이 다른지 정확히 모르고 사용하고 있었다. 또한 Git-Flow를 공부하다가 이 내용에 대해서 정확히 짚고 나가는 것이 좋다는 생각이 들었다.

그래서 이에 대해 알아보니 일단 결론적으론 브랜치를 합치는 작업에서 Github진영에서는 Pull Request라 하고 Gitlab진영에서는 Merge Request라고 부르는 같은 동의어와 같은 것임을 알게 되었다.

간단히 설명하자면 Github에서는 내가 작업한 브랜치를 Master의 입장에서 Pull하는 것이기에 Pull Request라 하는 것이고 Gitlab에서는 내가 작업한 브랜치 입장에서 Master에 Merge하는 것이기에 Merge Request라 하는 것이였다.

좀 자세히 알아보자면

Pull Request는 첫 액션이 Pull을 하는 것이기에 PR이 된 것이다.

Merge Request는 마지막 액션이 Merge를 하는 것이기에 MR로 부른다.

사실상 같은 용어들이므로 자신이 쓰는 서비스에 맞게 용어를 사용하면 될 것 같다!!

참고

https://stackoverflow.com/questions/7273434/is-it-possible-to-create-merge-requests-in-pure-git-from-the-command-line?noredirect=1&lq=1

https://prosaist0131.tistory.com/entry/MR%EA%B3%BC-PR%EC%9D%98-%EC%B0%A8%EC%9D%B4

처음에 Git-Flow라는 단어를 들었을 떈 그냥 단순히 브랜치의 흐름? 같은 것이라고 생각을 했었다.

비슷하지만 그런 것이 아니라 Git-Flow는 대표적인 Git 브랜칭 전략이다.

Git-Flow는 Vincent Driessen이라는 분이 처음 개발한 깃 브랜칭 모델이다.

1년여간 이 분이 이러한 브랜칭 모델을 사용했고 그에 대한 이야기를 적어놓았던 글이 화제가 되어 현재 많은 개발자들이 이 모델을 많이 사용하고 있다.

Git-Flow에 대해 간략한게 설명해보자면 이 모델은 5가지 브랜치를 사용하는 모델이다.

Master(Main) - 제품으로 출시되는 Branch, Production의 개념을 내포하고 있다.

Develop - 다음 출시 버전을 개발하는 Branch

Feature - 기능을 개발하는 Branch, 주로 이 브랜치에서 개발을 한다.

Release - 이번 출시 버전을 준비하는 Branch, QA를 진행하는 브랜치이다.

Hotfix - 출시 버전에서 발생한 버그를 수정하는 Branch

Git-Flow를 사용해서 개발하는 순서는 보통 아래와 같이 이루어진다.

• 처음에 Master(Main)와 Develop 생성
• 새로운 추가 작업은 Develop에서 Feature Branch 생성
• Feature는 Develop으로 Merge(이때 Develop이 최신 상태인지 확인해야함)
• QA를 위해서 Develop에서 Release Branch 생성
• QA에서 발생한 버그는 Release에서 수정
• QA가 끝나면 Release에서 Develop / Master(Main)으로 각각 Merge
• Hotfix는 Master에서 시작하여 수정 후 Master / Develop에 Merge

Git-Flow가 유용하긴 하지만 너무 많은 브랜치를 사용하는 점, 그에 따라 안쓰는 브랜치가 생기고 브랜치 마다 포지션이 애매해질 수 있기 때문에 이러한 점을 보완해 좀 더 간소화 된 브랜칭 전략이 나왔는데 그것이 GitHub-Flow이다.

GitHub-Flow란 Git-Flow가 복잡하기에 이를 좀 더 간소화시킨 방식으로 Scott chacon이 Github에서 좀 더 편리하게 사용하기 위해 만든 브랜칭 전략이다.

자동화 개념이 포함되어 있으며 Master(Main) Brnach에 대한 role만 정확하다면 나머지 Branch들에는 관여를 하지 않는다. 그리고 Pull Request 기능의 사용을 권장한다.

사용법 및 특징을 정리해보면

1. Master Branch의 어느것이든 배포가 가능하다.

• master 브랜치는 항상 최신 상태며, stable 상태로 product에 배포되는 브랜치
• 이 브랜치에 대해서는 엄격한 role과 함께 사용한다
• merge하기 전에 충분히 테스트를 해야한다. 테스트는 로컬에서 하는 것이 아니라 브랜치를 push 하고 Jenkins로 테스트 한다

2. 새로운 일을 시작하기 위해 Branch를 Master에서 딴다면 이름은 어떤 작업인지 명확하게 명시한다.

• 브랜치는 항상 master 브랜치에서 만든다
• Git-flow와는 다르게 feature 브랜치나 develop 브랜치가 존재하지 않음
• 새로운 기능을 추가하거나, 버그를 해결하기 위한 브랜치 이름은 자세하게 어떤 일을 하고 있는지에 대해서 작성해주도록 하자
• 커밋메시지를 명확하게 작성하자

3. Local Branch에 수시로 커밋하고 이 내용을 원격 Branch에 수시로 Push한다.

• Git-flow와 상반되는 방식
• 항상 원격지에 자신이 하고 있는 일들을 올려 다른 사람들도 확인할 수 있도록 해준다
• 이는 하드웨어에 문제가 발생해 작업하던 부분이 없어지더라도, 원격지에 있는 소스를 받아서 작업할 수 있도록 해준다

4. 피드백이나 도움이 필요할 때 혹은 자신의 Branch가 merge할 준비가 되었다면, PR을 생성하여 공유한다.

• pull request는 코드 리뷰를 도와주는 시스템
• 이것을 이용해 자신의 코드를 공유하고, 리뷰받자
• merge 준비가 완료되었다면 master 브랜치로 반영을 요구하자

5. PR 리뷰 후에는 다른 사람의 동의를 얻고 Master에 Merge한다.

• 곧장 product로 반영이될 기능이므로, 이해관계가 연결된 사람들과 충분한 논의 이후 반영하도록 한다
• 물론 CI도 통과해야한다!

6. Master Branch로 Merge나 Push가 이루어지면 즉시 배포해야한다.

• GitHub-flow의 핵심
• master로 merge가 일어나면 자동으로 배포가 되도록 설정해놓는다

마지막으로 GitLab-Flow란 GitLab에서 Git-Flow를 간소화하여 만든 브랜칭 전략이다.

또한 Github-flow는 너무나도 간단하여 배포, 환경 구성, 릴리즈, 통합에 대한 이슈를 남겨둔 것이 많았다.

그것을 보완하기 위해 GitLab에서 관련 내용들을 추가적인 가이드를 제공하여 전략을 만들었다.

아래는 GitLab-Flow의 특징이다.

Production branch with GitLab flow

Github-Flow에서는 매번 Merge후에 배포를 하라고 하지만 iOS앱 등 배포 시기를 맞추지 못하는 서비스 등 이 특징을 매번 적용하기 힘든 경우가 있다.

이러한 경우들을 해결하기 위해 production 브런치가 존재하여 커밋한 내용들을 일방적으로 배포하는 형태를 만들었다. GitHub에서 브런치 하나를 더 구성하여 사용하는 이것도 조금은 간단한 구성이다.
이렇게 구성하면 배포 자동화가 되어있지않은 구성에서 어떻게 배포를 진행할 것인가에 대한 내용을 담았다. 물론 이걸로 부족하여 다음의 것도 추가되었다.

Environment branches with GitLab flow

master와 production 사이에 pre-production을 두어 개발한 내용을 곧장 반영하지 않고 시간을 두고 반영을 하는 것을 말한다. Staging을위한 공간인 pre-production에 MR을 Master에서 보낸다. 이와 같은 형식은 downstream flow의 방식을 취하게 되며 hotfix발생시 master에서 feature 브랜치를 만들어 수정 후 Master에 MR을 보낸다. feature 브랜치를 바로 삭제하지 않고 Master에서의 자동 테스트를 통과를 확인하고 삭제한다.

Release branches with GitLab flow

release한 브런치를 두고서 보안상 문제가 발생한 것이나 백 포트를 위해서 작업을 할 경우, cherry-pick을 이용해서 작업을 진행할 수 도 있다.(2-3 stable이나 2-4 stable등의 브랜치를 만들어서 작업) 아니면 해당 릴리즈에서 발생하는 버그들을 묶어서 수정하는 방식으로 작업한다. 일반적으로 말하는 ‘upstream first’ 정책이다. 같은 버그를 수정하는 경우를 방지하기 위해 태그를 달아서 패치 버전을 관리해주는 것이 좋다.

Merge/pull requests with GitLab flow

Pull request를 사용하는 방법이다. GitHub Flow에서 하는 방법과 동일하다.(Github에서는 pull request이고 GitLab에서는 Merge request임)

보호되고 있는 Long-live branch는 maintainer만 merge할 수 있도록 해야한다. Merge후에는 feature 브랜치는 삭제해주도록 한다.

Issues with GitLab flow

Issue 트러커와 연결하여 사용하는 것을 말한다. 긴 시간 동안 작업을 할 경우, 이슈를 생성하여 작업을 진행하는 것으로 브랜치 이름에는 이슈번호를 적어 작업 중인 이슈가 어떤 것인지를 명확하게 해주는 것이 필요하다.
작업이 끝나거나 코드 공유가 필요한 시점이면 Merge/pull requsts를 보낸다.

이 글을 작성하면서 가장 많은 도움을 받았던 블로그이다. 특히 GitLab 관련해서 일어 번역을 해주셔서 편하게 공부할 수 있었다.. 또한 장단점 정리가 깔끔했다.

https://ujuc.github.io/2015/12/16/git-flow-github-flow-gitlab-flow/

위의 브랜칭 전략들을 공부하면서 정말 정답은 없다고 느꼈다. 우아한 형제들 블로그에서는 Github-flow를 사용하다가 오히려 Git-flow로 넘어가는 등 자신이 하고 있는 프로젝트나 팀 상황에 맞게 브랜칭 전략을 잘 수립해야 될 것 같다.

아래의 공식 사이트 등을 통해 좀 더 자세히 공부할 수 있다~

참고

https://docs.gitlab.com/ee/topics/gitlab_flow.html

https://about.gitlab.com/topics/version-control/what-is-gitlab-flow/

https://guides.github.com/introduction/flow/

https://hellowoori.tistory.com/56

https://ujuc.github.io/2015/12/16/git-flow-github-flow-gitlab-flow/

https://scottchacon.com/2011/08/31/github-flow.html

https://nvie.com/posts/a-successful-git-branching-model/

https://techblog.woowahan.com/2553/

https://muscardinus.tistory.com/223

항상 자바를 공부하다 보면 항상 헷갈리는 부분이 ==과 eqauls의 차이에 대한 것이다.

매번 찾아보지만 또 까먹은 김에 아예 글을 작성하게 되었다.

간단하게 결론부터 이야기 하자면 ==의 경우 주소값(Call by Reference)까지 비교하는 연산자이고 equals의 경우 값(Call by Value)만 비교하는 메소드이다.

예를 들어

String str1 = "abc";
Stirng str2 = new String("abc");

이 두개의 값을 비교해보자

str1의 경우 리터럴을 사용하여 선언하였기에 string constant pool이라는 영역에 존재하게 되고

str2의 경우 new를 통해 String을 생성했기에 Heap 영역에 존재하게 됩니다.

따라서 당연히 두 값의 주소값은 달라질 것이기에 아래와 같은 결과가 나오게 됩니다.

str1 == str2;		// false!!
str1.equals(str2);	// true!!

따라서 평상시 자바에서 String을 비교할때에는 equals를 사용해야한다!!

참고

https://coding-factory.tistory.com/536