배포를 해보고 있는데 Git 브랜치 설정에 대해 질문이 있습니다.

Question

안녕하세요 국비 학원다니면서 프로젝트를 진행하다가 다들 열심히 해줘서 배포까지 해보게 됐는데요. 처음엔 배포에 대한 생각이 없이 프로젝트를 진행하다가 하게된거라 처음부터 설계되지 않아서 문제를 겪고 있다고 생각합니다 ㅠㅠ우선 Git을 사용하던 방식은Main : 개발최종본A : 팀원AB : 팀원BC : 팀원C이 상태로 각자의 개발이 되면 Main에 PR해서 병합하고 서로의 변경점은 Main에서만 가져다가 업데이트 해서 하다가이번에 배포를 해보게 됐는데요Main : 개발 최종본Main -> Deploy : 배포 최종본Main -> A,B,C : 팀원 개발브랜치이렇게 브랜치가 생겨있는 상태입니다.Main과 Delploy 브랜치의 차이는 redirection주소나 security에서 허용하는 주소같은것들이 로컬주소인지 도메인주소인지 이런것들이 다른상태인데요기능을 한두가지 더 추가하고 수정할것들이 있는데 Main에서 나온 A에서 작업을하고 Main에 합치면 Deploy에서 pull 했을 때 도메인주소 이런것도 다 바뀔까봐 무서워서어떻게해야하지 하고 있는중입니다. 혹시 Main에 새로 추가된 내용들만 알아서 pull하나요? 아니면 Deploy랑 Main이랑 달라진거 같다 하면 그 내용도 바꿔버리나요?아니면 또 다른방법이 있다면.. 조언해주시면 감사하겠습니다 ㅠㅠ

S_J · Answer

.gitignore에 대해서 찾아보세요.

감독님테스트가하고싶어요 · Answer

다중 profile 을 검색해보세요

또닉 · Answer

git 브랜치 전략은 여러 방법론이 있는데 그중 많이 알려진 것은 GItFlow라는 것입니다. 이러한 브랜치전략을 선택/수립하고 팀원들 모두 그것을 이해하고 브랜치 규칙을 지켜야죠. 그건 그렇고. 설정의 차이로인해 브랜치/관리코드가 다르면 안됩니다. 배포환경마다 관리하는 소스코드가 바뀌어야한다면 그것은 잘못된 소스관리입니다. 하나의 앱이 배포될때 OS환경은 여럿일 수 있습니다. 로컬환경만해도 팀원 각자의 로컬컴퓨터 환경이 다를수 있는데 OS차이는 차치하고라도 Docker를 쓸수도 있고 VM을 쓸수도 있죠. 서버의 경우 개발서버, 테스트서버, QA서버, 스테이징서버, 프로덕션서버로 증식가능합니다. 그러한 서버환경설정값은 환경변수나 별도 config 파일을 이용하게하고 그것만 바꿔주면 환경에 맞춰 돌아가게 해야하는 것입니다. 그 과정에서 비밀정보는 git에 포함되지 않게 (소스관리로 공유되지않게) ignore 해야하는 거고요. 예를들어 닷넷은 appsettings.Production.json 은 프로덕션환경에 쓰이는 구성파일인데 이것을 ignore해두고 이것을 어떻게 작성해야할지 예제는 appsettings.Production.json.sample 같은 파일로 제공하는 겁니다. 다른 스택에서는 .env 가 실제로 로컬과 프로덕션에 모두 쓰인다면 ignore해두고 .env.local 파일을 관리/배포해서, 공유받은 사람은 .local을 삭제하고 씀으로써 로컬개발환경에서 돌수 있게하는거죠. 프로덕션에서는 내용이 서버별로 진짜 비밀정보를 작성하게 될거고요. 비밀정보가 아니더라도 서버환경별 구성(도메인주소등)은 구성파일만 바꿔줌으로써 다 해결되면 그만입니다. 그걸위해 .json파일이나 YAML파일로 구성파일을 쓰죠. 닷넷은 그 방법 중 하나로 (서버)OS환경변수 설정과 appsettings.{환경}.json 식으로 여러 환경별 구성파일을 포함할 수 있도록 프레임워크가 구성되어있습니다. 서버 웹앱의 경우 단일버전 배포입니다. 새버전을 배포하면 이전버전은 접근이 안되게 내리는게 일반적이죠. 그런데 데스크탑앱이나 OS에대한 소스코드관리를 생각해보면 어떨까요? 이러한 데스트탑앱/OS들은 여러 메인버전마다 프로덕션으로 배포되어 여러 프로덕션 코드가 공존,관리되는 시기를 지속하게됩니다. 엔드유저 누구는 1.0을 그대로 쓰고 누구는 2.0을 새로 업데이트 받죠. 그렇게 2.0이 나온상태에서도 여전히 1.0버전의 보안패치를 해서 1.1 이런식으로 올려서 개발/테스트/QA후 프로덕션으로 재배포해야합니다. 이런것들을 브랜치로 나누어 관리해야하는데 각각의 개발버전, 테스트버전, QA버전,프로덕션버전 마다 설정값에따라 git 브랜치를 또 다시 달리해야한다면 그곳이 git 지옥이겠죠.

또닉 · Answer

지금 본문을 보면 main(master)브랜치를 Gitflow 에서의 develop 브랜치처럼 쓰고 있는데 깃허브 보호/병합대상브랜치가 main으로 설정되어있을거라 설정을 바꾸던가, develop 브랜치 새로 따서 거기부터 새로 지키던가 하는게 좋을듯하네요.보통 깃브랜치 전략이 먼저 수립되면 애초에 브랜치 이름을 기본 main으로 안쓰고 다르게 만들어요.

kenu,전독시 · Answer

환경변수로 세팅하면, 코드는 동일해도 다른 곳을 바라보게 됩니다.댓글 다신 분들 말씀의 공통점이라고 생각합니다.최근 소프트웨어를 서비스 형태로 제공하는게 일반화 되면서, 웹앱 혹은 SaaS(Software As A Service)라고 부르게 되었다. Twelve-Factor app은 아래 특징을 가진 SaaS 앱을 만들기 위한 방법론이다.설정 자동화를 위한 절차(declarative) 를 체계화 하여 새로운 개발자가 프로젝트에 참여하는데 드는 시간과 비용을 최소화한다.OS에 따라 달라지는 부분을 명확히하고, 실행 환경 사이의 이식성을 극대화 한다.최근 등장한 클라우드 플랫폼 배포에 적합하고, 서버와 시스템의 관리가 필요없게 된다.개발 환경과 운영 환경의 차이를 최소화하고 민첩성을 극대화하기 위해 지속적인 배포가 가능하다.툴, 아키텍처, 개발 방식을 크게 바꾸지 않고 확장(scale up) 할 수 있다.from: https://12factor.net/ko/위의 링크에 있는 글 강추합니다. 도움이 되시길

개미와고양이 · Answer

1. Main (master) Branch 는 Release, Hotfix 이외에는 외부에서 건들이지 않는것이 좋습니다.2. develop Branch 에서 각자의 Branch 를 생성하고 각지 진행하는 프로젝트 단위별로 feature 생성 후 작업을 진행 합니다. 진행중인 프로젝트 중간에 다른 branch 로 이동시 stash 기능을 사용 합니다.3. 개발 진행중 develop 브랜치에 변경 정보를 pull 로 당겨서 최신 상태를 유지해 줍니다. develop -> pull - > 개발자 Branch -> pull -> 개발자 feature4. 소스 취합시 develop 에서 Release 를 생성해서 각각 작업한 내용을 pull 또는 cherry pick 으로 소스 취합후 배포는 release 를 통해서 배포하고 테스트 후 이상 없는경우 Release 마무리 후 develop, master 에 반영 합니다.

배포를 해보고 있는데 Git 브랜치 설정에 대해 질문이 있습니다.

6개의 답변

#git 목록