웹 개발을위한 GIT 워크 플로우

오래 전에 저와 함께 일하는 소규모 웹 개발자 팀은 웹 개발을 위해 git을 사용하기 시작했습니다. 그 당시 우리는 단지 스테이징이나 마스터 링을하기 위해 최선을 다했다. 아무것도 아닌 것보다 낫지 만 엉망이었습니다.

얼마 전에 우리는 gitflow 작업 흐름을 채택했습니다. 이전의 혼돈보다 확실히 낫지 만 다소 번거롭고 릴리스 / 마일스톤 지향적입니다. 동료 개발자들은 종종 작동 방식과 병합 및 금지 대상을 명확하게 요청합니다. 일반적으로 코드를 자주 배포하고 릴리스의 특정 이정표를 추적하지 않는 웹 개발 작업에는 적합하지 않은 것 같습니다.

친구 최근 제안에서 GitHub Flow를 살펴보기 시작했습니다 . Scott Chacon의 게시물을 읽으면 다음과 같이 어려움을 겪습니다 .

그렇다면 GitHub에서 git-flow를 사용하지 않는 이유는 무엇입니까? 주된 문제는 항상 배포한다는 것입니다. git-flow 프로세스는 크게 "릴리스"를 중심으로 설계되었습니다. 우리는 매일 매일 여러 번 프로덕션에 배포하기 때문에“릴리스”가 없습니다.

FWIW, 나는 또한 Atlassian 사이트에서이 멋진 워크 플로우를 살펴 봤습니다 : https://www.atlassian.com/git/workflows#!workflow-feature-branch

그러나 이들은 모두 소규모 팀에서 웹 개발에 대한 선택이 좋지 않은 것처럼 보이며 자주 / 매일 릴리스되지 않는 주요 애플리케이션 릴리스에 맞춰 조정되었습니다.

이것은 git-flow와 github-flow를 비교하도록 요청하는 SE에 대한 질문입니다 https : //.com -흐름

그것은 일반적으로 좋은 대답이지만 meta.programmers.SE 아래의 의견에서 언급했듯이 일반적인 최상의 워크 플로우 관행에 대한 질문이 여기에 속한다고 생각하는 것 같습니다 .git-flow 및 github보다 가능한 광범위한 답변 목록을 원했습니다. 웹 개발에 특화되어 있습니다. 따라서 나는 이것이 새로운 질문을 보증한다고 생각합니다.

이를 통해 소규모 웹 개발 팀이 상당히 지속적으로 배포하는 프로젝트를 수행하는 데 가장 적합하고 바람직한 git 기반 워크 플로는 무엇입니까? github-flow 또는 다른 것입니까?

web-development git gitflow

— jb510
소스

: BTW,이에 따라 Programmers.SE 여기에이 질문을 가하고있어 meta.programmers.stackexchange.com/posts/6312/revisions

— jb510

귀하의 연구를 공유하면 모든 사람을 도울 수 있습니다. 당신이 무엇을 시도했고 왜 그것이 당신의 요구를 충족시키지 못했는지 알려주십시오. 이것은 당신이 시간을내어 자신을 돕기 위해 노력했고, 명백한 답변을 반복하지 못하게하며, 무엇보다도보다 구체적이고 관련성있는 답변을 얻는 데 도움이됩니다. 또한 묻는 방법

— gnat

@gnat 나는 그 점에서 무엇을 더 공유 할 수 있는지 잘 모르겠습니다. gitflow는 릴리스 지향이므로 번거 롭습니다. GitHub-Flow는 매일 배포하기에 적합하지만 수십 개의 지점이 병합되기를 기다리는 것은 혼란처럼 보입니다. 누군가가 "X는 웹 개발자에게는 Y이기 때문에 훌륭합니다"라고 대답하기를 바랐습니다. 내가 제공 한 링크에서 잘 설명되어 있는데 인용에서 인용 할 수 있다고 생각합니까?

— jb510

@gnat-더 많은 연구를 보여주고 내가 찾고있는 답변에 대해 구체적으로 설명하기 위해 질문을 완전히 다시 작성했습니다.

— jb510

먼저 살펴본 다양한 워크 플로에 대해 간략하게 요약하고 있으며 현재 작업중인 개발에 적합하지 않다고 생각합니다.

중앙 집중식 ( 소스 ) : SVN 워크 플로우와 유사하지만 이제는 분산 환경입니다. 모든 개발자는 직접 또는 풀 요청을 통해 개인 사본을 작성 master하고 변경 사항을 푸시 origin/master합니다.
기능 브랜치 ( Source ) : 글쎄요. 특정 기능을 작업하는 모든 개발자는 해당 기능 전용의 특정 지점에서만 작업해야합니다. 이 기능 분기는 master다른 기능 분기에서 작성 하거나 다른 기능 분기에서 작성해야합니다 . 결국 모든 것이 다시 병합됩니다 master.
Gitflow ( 소스 ) : 두 가지 주요 지점은 프로젝트 기록을 추적 develop하고 master. 또 다른 3 가지라고 hotfix, release그리고 feature보류 변경에 직접 master전 단지와 같은 특정 기능에 대한 릴리스 또는 직장에 중요한 생산 버그, 변경 버전 번호 및 기타 세부 고정 기능 분기를 각각.
GitHub 흐름 ( 소스 ) : 개발자가의 feature분기를 만듭니다 master. 풀 요청을 통해 변경 사항이 적용됩니다. 승인 된 변경 사항 master 은 GitHub 봇 Hubot에 의해 즉시 배포됩니다.

질문의 개발 부분에 대한 답변은 팀의 배경에 따라 다릅니다. 그들은 SVN 환경에서 왔습니까? 그런 다음 SVN과 가장 유사한 중앙 집중식 접근 방식을 사용해야합니다. 그들은 Git과 함께 일하는 것이 편안하다고 생각합니까? 그렇다면 팀의 워크 플로를 다른 워크 플로에 적용하지 말고 자신의 요구 사항에 맞게 제작하여 자신의 구현을 구현해야합니다.

또한 후자를 개선하는 데 집중해야한다고 생각합니다. 배포 파이프 라인 은 어떻게 구성되어 있습니까? " 빌드, 테스트 및 배포 자동화를 통한 안정적인 배포 : 안정적인 소프트웨어 릴리스 "에서 저자는 드물게 배포 할 수있는 원인을 식별합니다. 그 중 일부는 다음과 같습니다.

배포 프로세스가 자동화되지 않았습니다.
테스트 시간이 오래 걸립니다.
사람들은 빌드 / 테스트 / 배포 프로세스를 이해하지 못합니다.
개발자는 작고 점진적으로 변경하여 기존 기능을 자주 중단하여 응용 프로그램 작동을 유지하는 데 익숙하지 않습니다.

당신이 개선 할 수있는 것 같은 소리가 있습니까? 아마도 당신과 당신의 팀이 프로젝트의이 부분을 어떻게 다루는 지에 대해 조금 더 말해 줄 수있을 것입니다.

— 헤르 난 에라 스모
소스

+1, cd의 핵심은 git 또는 gitflow가 아니라 CI 및 전달 워크 플로우입니다.

— Wyatt Barnett

이것에 대해 많이 생각하십시오. 통찰력에 감사드립니다. FWIW, CI를 사용하지 않기 때문에 CI라는 용어를 사용하지 않는 것이 좋습니다. 어쩌면 우리는해야하지만, 그렇지는 않지만, 주어진 주, 단기, 장기에 대해 수십 개의 프로젝트를 수행하는 것은 너무 번거로운 일입니다.

— jb510

@ jb510-비슷한 프로젝트 설정이 있는데 CI 없이는 꿈을 꾸지 않을 것입니다. 멍청하지만 깨지기 쉬운 부분을 모두 스크립팅하면 컨텍스트 전환이 훨씬 쉬워집니다.

— Wyatt Barnett

때때로 CI를 쉽게 구현할 수 없다는 것은 프로젝트에 CI 가 얼마나 필요한지 를 나타내는 지표입니다. 단위 테스트가 없습니까? 모든 수동 배포? 어리석은 배포 단계가 많습니까? 검사가 필요합니다.

— Kzqai

나는이 질문에 따라 수년에 걸쳐 대답했습니다. 나는 다른 사람이 아니라 답변을 제공하는 것이 희망 싶지만,이 자체 그래서 마침내 허용 마킹 좋은 답변입니다 (아마 했어야 그 긴 시간 전)

— jb510