Replies: 6 comments
-
정리브랜치 전략 수립을 위한 전문가의 조언들 블로그의 초반 내용이 제가 하고자 하는 내용을 함유하고 있습니다. 우리는 소프트웨어 버전 관리가 필요한 앱이나 솔루션이 아니라, 웹 애플리케이션을 개발하고자 하기 때문에 Git-flow를 따를 필요없다. 따라서 보다 가볍지만, 관리하기 편한 GitLab-flow를 사용하고자 하는 것입니다. 그리고 이전부터 계속 논의하던 feature 관리에 대해서는 issue 번호로 네이밍하여 관리하는 것을 제안하는 바입니다. |
Beta Was this translation helpful? Give feedback.
-
|
한 달간 프로젝트를 진행함에 있어 GitLab-flow 방식이 더 적합해보인다고 생각합니다. 대략적인 이해는 완료했고 추후 대면 회의 때 한 번 더 이야기 나눠보면 좋을 거 같습니다. |
Beta Was this translation helpful? Give feedback.
-
|
GitLab-flow방식과 feature 관리를 issue 번호로 네이밍하여 관리하는 방식 괜찮다고 생각합니다. |
Beta Was this translation helpful? Give feedback.
-
|
회의를 할 때 고민이었던 브랜치 삭제에 대한 부분이 해결될 것으로 예상되어 좋은 방법이라고 생각합니다. 또한, milestone의 issue의 번호를 통해 branch를 생성하면 브랜치를 생성한 이유, 목적 그리고 생명주기까지 확인이 가능한 점이 관리에 용이할 것 같아 제안에 찬성합니다. |
Beta Was this translation helpful? Give feedback.
-
|
개발 시간과 규모를 고려했을 때 gitLab-flow 방식이 적합하다고 생각합니다. |
Beta Was this translation helpful? Give feedback.
-
|
한 달간 회의한 내용에 맞추어 생각해보면 GitLab-flow이 적합해보입니다. |
Beta Was this translation helpful? Give feedback.
-
이전에 Branch 전략으로 Git-flow로 선택을 했었습니다. 하지만, branch flow 방식을 확정 짓기 이전에 과연 이게 오픈소스로 사용하기 적합한 것인지에 대한 고민이 들었고, Git-flow 이외에 2가지 방식을 더 제안하고자 합니다.
그에 따라, GitLab-flow로 프로젝트를 진행하고자 하는데, 이에 대한 의견을 받고자 합니다.
Git-flow
우선 Git-flow는 다음과 같은 방식으로 브랜치를 활용하여 개발합니다.
master : 기준이 되는 브랜치로 제품을 배포하는 브랜치 입니다.
develop : 개발 브랜치로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능들을 합(Merge)칩니다.
feature : 단위 기능을 개발하는 브랜치로 기능 개발이 완료되면 develop 브랜치에 합칩니다.
release : 배포를 위해 master 브랜치로 보내기 전에 먼저 QA(품질검사)를 하기위한 브랜치 입니다.
hotfix : master 브랜치로 배포를 했는데 버그가 생겼을 때 긴급 수정하는 브랜치 입니다.
출처
Git Flow 개념 이해하기
GitHub-flow
master 브런치는 항상 최신의 상태이며, stable 상태로 Product에 배포되는 브런치이다. 그리고 이 브런치에 대해서는 엄격한 role를 주어 사용한다.
git flow 와는 다르게 feature 브런치나 develop 브런치가 존재하지 않는다. 그렇기에 새로운 기능을 추가하거나 버그를 해결하기 위한 브런치의 이름은 자세하게 어떤 일을 하고 있는지에 대해서 작성해주도록 하자. Github 페이지에서 보면 어떤 일들이 진행되고 있는지를 확인하기 쉽게 말이다.
git flow 와 가장 상반되는 방식이다. 항상 원격지에 자신이 하고 있는 일들을 올려 다른 사람들도 확인할 수 있도록 해준다.
이 방법의 좋은 점은 하드웨어에 문제가 발생하여 작업하던 부분이 없어지더라도 원격지에 있는 소스를 받아서 작업을 할 수 있도록 해준다.
pull request 는 코드 리뷰를 도와주는 시스템이다.
그렇기에 이것을 이용하여 자신의 코드를 공유하고, 리뷰를 받을 수 있도록 한다. 물론 머지가 준비 완료되어 master 브런치로 반영을 요구하여도 된다.
곧장 product로 반영이될 기능이기에 이해관계가 연결된 사람들과 충분한 논의 이후 반영하도록 한다.
GitHub Flow의 핵심인듯한 master로 머지가 일어나면 hubot을 이용하여 자동으로 배포가 되도록 설정해놓는다.
브런치 전략이 단순하다.
처음 git을 접하는 사람에게 정말 좋은 시스템이 된다.
Github 사이트에서 제공하는 기능을 모두 사용하여 작업을 진행한다.
코드 리뷰를 자연스럽게 사용할 수 있다.
CI가 필수적이며, 배포는 자동으로 진행할 수 있다.
Github가 작업을 할 때 이렇게 작업하고 있다.
CI와 배포 자동화가 되어있지 않은 시스템에서는 사람이 관련된 업무를 진행한다.
많은 것들이 올라오기 시작하면… 그때부터는 헬이…
너무 간단하니… 이거 단점이 있나 싶다…
출처
Git flow, GitHub flow, GitLab flow
GitLab-flow
단일 브랜치: GitLab Flow는 "main" 또는 "master"와 같은 하나의 브랜치만 사용합니다. 모든 개발이 해당 브랜치에서 진행됩니다.
Feature 브랜치: 새로운 기능이나 버그 수정과 같은 개발 작업은 별도의 브랜치에서 처리합니다. 이 브랜치는 "main" 브랜치에서 파생되고, 개발이 완료되면 다시 "main" 브랜치로 병합합니다.
Merge Request: GitLab Flow에서는 개발이 완료된 브랜치를 "main" 브랜치로 바로 병합하지 않고, Merge Request를 사용하여 다른 팀원들의 리뷰를 받습니다. 이를 통해 코드 품질을 유지하고 팀의 협업을 강화할 수 있습니다.
CI/CD 지원: GitLab은 통합 CI/CD 기능을 제공하여 코드 변경 사항이 자동으로 테스트되고 배포될 수 있도록 지원합니다.
요약: Git flow는 너무 복잡하고 Github flow는 너무 단순하다 라는 요구사항에 나온 전략으로 서비스의 규모가 조금 커진 팀에서 사용하기 좋은 전략으로 보입니다.
출처
[Git] 브랜치 전략 - GitLab Flow
결론
Git-flow와 같은 경우에는 1달 간 프로젝트를 진행하기 위해서는 복잡한 감이 있다. 그리고, Git-flow 자체는 우리가 개발하고자 하는 web/PWA/Extension의 형태에 적합하기보다는 release 버젼의 관리가 중요한 앱의 형태에 적합하다는 판단이 든다.
GitHub-flow와 같은 경우에는 단순해서 프로젝트를 진행하기에 편하지 않나라는 생각이 들긴 하지만, 프로젝트가 복잡해짐에 따라 소스관리가 힘들어질 가능성이 높다. 따라서 GitLab-flow를 사용하고자 한다.
제안
기존에는 feature 별로 나눠서 브랜치 네이밍을 하기로 했었는데... milestone을 사용하는 점, 그리고 코드를 변경하는 목적은 분명하기 때문에, 이슈 번호로 생성하여 관리하자는 것을 제안합니다.
브랜치 전략 수림을 위한 전문가의 조언들라는 블로그를 보게 되면 다음과 같은 말이 있다.
'코드를 변경하는 목적은 분명하므로 이슈로 생성하여 관리하자.'는 이념 아래로 코드 변경 사유를 투명하게 공개하자는 원칙입니다. GitLab은 동일한 repository를 사용하는 개발자들끼리 작업 내용을 알아야 된다고 말합니다. 또한 이슈를 기반으로 관리하면 브랜치 생명주기 보다 명확하게 파악되어 유지보수가 용이하죠.위와 같은 말을 통해서 우리가 기존에 우려하던, "너무 많은 브랜치가 생기면 보기 힘들며, 이미 수명주기가 끝난 브랜치일 수 있다."와 "브랜치를 삭제하면, 코드를 오히려 해석하기 힘들다."라는 문제가 해결될 것으로 보인다. 이에 milestone의 issue의 번호를 통해 branch를 생성하고, hotfix 등과 같이 급하게 수정해야될 코드들을 bug issue의 번호를 통해 branch를 생성하여 관리하고, 완료되면 삭제하는 방안을 사용하는 것은 어떤가에 대해 제안한다.
Beta Was this translation helpful? Give feedback.
All reactions