GitHub Flow

원문 : GitHub Flow by Scott Chacon (Github 공동 창업자 및 GitHub 에발젤리스트)

git-flow 관련 문제

나는 여기저기를 돌아다니며 사람들에게 Git을 가르치고 있으며 최근에 내가 했던 거의 모든 수업과 워크샵에서 git-flow 에 대해 어떻게 생각하는지 물었습니다 . 나는 항상 그것이 훌륭하다고 생각한다고 대답합니다. 백만 개의 가능한 워크플로가 있는 시스템(Git)을 사용하고 상당히 간단한 방식으로 많은 개발자에게 작동하는 잘 테스트되고 유연한 워크플로를 문서화했습니다. 개발자가 프로젝트나 회사 간에 이동하고 이 표준화된 워크플로에 익숙해질 수 있도록 표준이 되었습니다.

그러나 문제가 있습니다. 나는 새로운 기능 분기가 , 또는 핫픽스를 처리하는 방식 이 develop아닌 시작되는 것을 좋아하지 않는다는 라인을 따라 사람들로부터 많은 의견을 들었지만 이는 master상당히 미미합니다.

나에게 더 큰 문제 중 하나는 대부분의 개발자와 개발 팀이 실제로 요구하는 것보다 더 복잡하다는 것입니다. 흐름을 적용하는 데 도움이 되도록 큰 도우미 스크립트 가 개발되었을 정도로 복잡 합니다. 멋지긴 하지만 Git GUI에서는 명령줄에서만 적용할 수 없으므로 모든 단계를 수동으로 수행해야 하기 때문에 복잡한 워크플로를 정말 잘 배워야 하는 유일한 사람이 문제입니다. 명령줄에서 사용할 만큼 시스템에 익숙하지 않은 동일한 사람들입니다. 이것은 큰 문제가 될 수 있습니다.

이 두 가지 문제는 훨씬 더 단순화된 프로세스만 있으면 쉽게 해결할 수 있습니다. GitHub에서는 git-flow를 사용하지 않습니다. 우리는 훨씬 더 간단한 Git 워크플로를 사용하고 있으며 항상 사용해 왔습니다.

그 단순성은 여러 가지 이점을 제공합니다. 하나는 사람들이 이해하기 쉽다는 것입니다. 즉, 빨리 이해할 수 있고 실수를 범하거나 잘못한 단계를 실행 취소해야 하는 경우는 거의 없습니다. 또 다른 하나는 이를 시행하거나 따르기 위해 래퍼 스크립트가 필요하지 않으므로 GUI 등을 사용하는 것이 문제가 되지 않는다는 것입니다.

GitHub flow

그렇다면 GitHub에서 git-flow를 사용하지 않는 이유는 무엇인가? 주요 문제는 우리가 항상 배포한다는 것입니다. git-flow 프로세스는 주로 release를 중심으로 설계되었습니다. 우리는 매일 프로덕션에 배포하기 때문에 “release”가 없습니다. 종종 하루에 여러 번입니다. CI 결과가 표시되는 동일한 장소인 채팅방 로봇을 통해 그렇게 할 수 있습니다. 우리는 모든 직원이 편안하게 할 수 있도록 테스트 및 배송 프로세스를 가능한 한 간단하게 만들려고 노력합니다.

정기적으로 배포하면 여러 가지 이점이 있습니다. 몇 시간마다 배포하면 많은 수의 큰 버그를 도입하는 것이 거의 불가능합니다. 작은 문제가 발생할 수 있지만 매우 빠르게 수정 및 재배포할 수 있습니다. 일반적으로 ‘핫픽스’나 정상적인 프로세스 외부에서 수행해야 하는 작업이 있지만 이는 단순히 정상적인 프로세스의 일부입니다. 핫픽스와 매우 작은 기능 간의 GitHub 흐름에는 차이가 없습니다.

상시 배포의 또 다른 장점은 모든 종류의 문제를 신속하게 해결할 수 있다는 것입니다. 우리는 주목을 받은 보안 문제에 대응하거나 작지만 흥미로운 기능 요청을 엄청나게 빠르게 구현할 수 있지만, 일반 또는 대규모 기능 개발을 처리할 때와 똑같은 프로세스를 사용하여 이러한 변경 사항을 해결할 수 있습니다. 모든 과정이 동일하고 매우 간단합니다.

우리가 그것을 하는 방법

그렇다면 GitHub Flow는 무엇입니까?

• master브랜치의 모든 것이 배포 가능합니다.
• 새로운 작업을 하려면 master(예: new-oauth2-scopes) 에서 설명적으로 명명된 분기를 만듭니다 .
• 해당 분기에 로컬로 커밋하고 정기적으로 서버의 동일한 명명된 분기에 작업을 푸시합니다.
• 피드백이나 도움이 필요하거나 브랜치가 병합할 준비가 되었다고 생각되면 풀 리퀘스트를 엽니다.
• 다른 사람이 기능을 검토하고 승인한 후 마스터에 병합할 수 있습니다.
• 병합되어 ‘마스터’로 푸시되면 즉시 배포 할 수 있고 배포 해야 합니다.

그것이 전체 흐름입니다. 매우 간단하고 매우 효과적이며 상당히 큰 팀에서 작동합니다. GitHub의 직원은 현재 35명이며 그 중 15-20명이 같은 프로젝트(github.com)에서 동시에 작업합니다. 대부분의 개발 팀(충돌을 일으킬 수 있는 동일한 논리 코드에서 동시에 작업하는 그룹)은 이 정도 규모이거나 그보다 작습니다. 특히 신속하고 일관된 배포를 수행할 수 있을 정도로 점진적입니다.

따라서 이러한 각 단계를 차례로 살펴보겠습니다.

1 - 마스터 브랜치의 모든 것은 배포 가능

이것은 기본적으로 시스템 의 유일한 엄격한 규칙 입니다. 구체적이고 일관된 의미를 가진 분기가 하나만 있으며 이름을 master. 우리에게 이것은 배포되었거나 최악의 경우 몇 시간 내에 배포될 것임을 의미합니다. 이것이 되감는 것은 매우 드뭅니다(작업을 되돌리기 위해 브랜치가 이전 커밋으로 다시 이동됨) - 문제가 있는 경우 커밋이 되돌려지거나 문제를 해결하는 새 커밋이 도입되지만 브랜치 자체는 거의 없습니다. 복구하다.

master분기 안정적이고 그것에서 배포 또는 오프 새로운 가지를 만들기 위해 항상, 항상 안전합니다. 테스트되지 않았거나 빌드를 깨뜨리는 것을 마스터하기 위해 푸시하면 개발 팀의 사회적 계약을 위반하고 일반적으로 그것에 대해 꽤 기분이 좋지 않습니다. 우리가 푸시하는 모든 분기에는 테스트가 실행되고 대화방에 보고되므로 로컬에서 실행하지 않은 경우 서버의 토픽 분기(단일 커밋이 있는 분기도 포함)로 푸시하고 Jenkins를 기다릴 수 있습니다. 모든 것을 통과했는지 알려줍니다.

deployed배포할 때만 업데이트 되는 분기를 가질 수 있지만 그렇게 하지 않습니다. 웹앱 자체를 통해 현재 배포된 SHA를 노출하고 curl비교가 필요한 경우 이를 노출합니다 .

2 - 마스터에서 설명 분기 만들기

무엇이든 작업을 시작하려면 안정적인 master브랜치 에서 설명적으로 명명된 브랜치를 만듭니다 . 현재 GitHub 코드베이스의 몇 가지 예는 user-content-cache-key, submodules-init-task또는 redis2-transition. 여기에는 몇 가지 장점이 있습니다. 하나는 가져올 때 다른 모든 사람들이 작업한 주제를 볼 수 있다는 것입니다. 또 다른 하나는 잠시 동안 분기를 포기하고 나중에 다시 돌아가면 그것이 무엇인지 기억하기가 상당히 쉽다는 것입니다.

GitHub 브랜치 목록 페이지로 이동하면 최근에 작업한 브랜치와 작업량을 쉽게 볼 수 있기 때문에 좋습니다.

현재 대략적인 상태의 향후 기능 목록과 거의 같습니다. 이 페이지는 사용하지 않을 때 유용합니다. 현재 선택한 브랜치와 관련하여 고유한 작업이 있는 브랜치만 표시하고 가장 최근에 작업한 브랜치가 맨 위에 오도록 정렬합니다. 정말 궁금한 점이 있으면 ‘비교’ 버튼을 클릭하여 해당 분기에 고유한 실제 통합 diff 및 커밋 목록이 무엇인지 확인할 수 있습니다.

따라서 이 글을 쓰는 현재 저장소에는 병합되지 않은 작업이 포함된 44개의 분기가 있지만 지난 주에는 그 중 9~10개 정도만 푸시되었음을 알 수 있습니다.

3 - 지속적으로 명명된 브랜치로 푸시

git-flow와의 또 다른 큰 차이점은 서버의 명명된 분기에 지속적으로 푸시한다는 것입니다. 우리가 정말로 걱정해야 하는 유일한 것은 master배포 관점에서이므로 서버로 푸시해도 다른 사람을 엉망으로 만들거나 혼동하지 않습니다. 그렇지 않은 모든 master것은 단순히 작업 중인 것입니다.

또한 랩톱 분실 또는 하드 드라이브 오류가 발생한 경우 작업이 항상 백업되도록 합니다. 더 중요한 것은 모든 사람이 지속적으로 소통할 수 있다는 것입니다. 간단한 ‘git fetch’는 기본적으로 every가 현재 작업하고 있는 TODO 목록을 제공합니다.

$ git fetch
remote: Counting objects: 3032, done.
remote: Compressing objects: 100% (947/947), done.
remote: Total 2672 (delta 1993), reused 2328 (delta 1689)
Receiving objects: 100% (2672/2672), 16.45 MiB | 1.04 MiB/s, done.
Resolving deltas: 100% (1993/1993), completed with 213 local objects.
From github.com:github/github
 * [new branch]      charlock-linguist -> origin/charlock-linguist
 * [new branch]      enterprise-non-config -> origin/enterprise-non-config
 * [new branch]      fi-signup  -> origin/fi-signup
   2647a42..4d6d2c2  git-http-server -> origin/git-http-server
 * [new branch]      knyle-style-commits -> origin/knyle-style-commits
   157d2b0..d33e00d  master     -> origin/master
 * [new branch]      menu-behavior-act-i -> origin/menu-behavior-act-i
   ea1c5e2..dfd315a  no-inline-js-config -> origin/no-inline-js-config
 * [new branch]      svg-tests  -> origin/svg-tests
   87bb870..9da23f3  view-modes -> origin/view-modes
 * [new branch]      wild-renaming -> origin/wild-renaming

또한 GitHub Branch List 페이지를 보고 모든 사람이 어떤 작업을 하고 있는지 확인할 수 있으므로 검사하고 도움이 필요한지 확인할 수 있습니다.

4 - 언제든지 풀 리퀘스트

GitHub에는 Pull Request 라는 놀라운 코드 검토 시스템이 있습니다. 많은 사람들이 오픈 소스 작업에 사용합니다. 프로젝트를 분기하고, 프로젝트를 업데이트하고, 유지 관리자에게 pull 요청을 보냅니다. 그러나 내부 코드 검토 시스템으로 쉽게 사용할 수도 있습니다. 이것이 우리가 하는 일입니다.

사실, 우리는 풀 리퀘스트보다 브랜치 대화 보기로 더 많이 사용합니다. GitHub의 단일 프로젝트(퍼블릭 또는 프라이빗)에서 한 브랜치에서 다른 브랜치로 pull 요청을 보낼 수 있으므로 “Please merge this in” 외에 “I need help or review on this”라고 말할 수 있습니다.

여기에서 Josh가 Brian을 참조하여 검토하고 Brian이 코드 라인 중 하나에 대한 조언을 제공하는 것을 볼 수 있습니다. 더 아래로 내려가면 Josh가 Brian의 우려를 인정하고 이를 해결하기 위해 더 많은 코드를 푸시하는 것을 볼 수 있습니다.

마지막으로 우리는 아직 시험 단계에 있다는 것을 알 수 있습니다. 이것은 아직 배포 준비가 된 분기가 아닙니다. 실제로 master배포 를 위해 병합하기 훨씬 전에 끌어오기 요청을 사용하여 코드를 검토 합니다.

기능이나 브랜치의 진행 과정에서 막혀 도움이나 조언이 필요한 경우 또는 개발자이고 작업을 검토할 디자이너가 필요한 경우(또는 그 반대의 경우), 코드가 거의 또는 전혀 없는 경우에도 일부 스크린샷이 있는 경우 구성 요소 또는 일반적인 아이디어가 있으면 끌어오기 요청을 엽니다. @username을 추가하여 GitHub 시스템에서 사람들을 참조할 수 있으므로 특정 사람들의 리뷰나 피드백을 원하면 PR 메시지에서 참조하기만 하면 됩니다(Josh가 위에서 본 것처럼).

Pull Request 기능을 사용하면 통합된 diff의 개별 줄, 단일 커밋 또는 pull 요청 자체에 대해 주석을 달 수 있고 모든 것을 인라인으로 단일 대화 보기로 끌어올 수 있기 때문에 좋습니다. 또한 계속해서 브랜치로 푸시할 수 있으므로 누군가가 당신이 무언가를 하는 것을 잊었다거나 코드에 버그가 있다고 댓글을 달면 수정하고 브랜치로 푸시할 수 있습니다. GitHub는 대화 보기에 새 커밋을 표시합니다. 그런 분기에서 계속 반복할 수 있습니다.

브랜치가 너무 오랫동안 열려 있고 마스터 브랜치와 동기화되지 않는 것 같다면 마스터를 토픽 브랜치에 병합하고 계속 진행할 수 있습니다. 풀 요청 토론이나 커밋 목록에서 분기가 ‘마스터’로 마지막으로 업데이트된 시간을 쉽게 확인할 수 있습니다.

브랜치에서 모든 것이 실제로 완료되고 배포할 준비가 되었다고 생각되면 다음 단계로 넘어갈 수 있습니다.

5 - pull 요청 검토 후에만 병합

우리는 단순히 master주제 브랜치에서 직접 작업 하거나 작업이 완료되었다고 생각될 때 병합 하지 않습니다. 우리는 회사의 다른 누군가로부터 승인을 얻으려고 노력합니다. 이것은 일반적으로 +1 또는 이모티콘 또는 “” 댓글이지만 다른 사람이 볼 수 있도록 노력합니다.

일단 그것을 얻고 브랜치가 CI를 통과하면 배포를 위해 마스터에 병합할 수 있습니다. 그러면 푸시할 때 풀 요청이 자동으로 닫힙니다.

6 - 검토 후 즉시 배포

마지막으로 작업이 완료되고 master분기에 병합됩니다 . 즉, 지금 배포하지 않더라도 사람들은 새로운 작업을 기반으로 하고 다음 배포(몇 시간 내에 발생할 가능성이 있음)에서 밀어낼 것입니다. 따라서 다른 사람이 당신이 작성한 것을 망가뜨리는 것을 밀어붙이는 것을 정말로 원하지 않기 때문에 사람들은 그것이 병합될 때 그것이 정말로 안정적인지 확인하는 경향이 있고 사람들은 또한 자신의 변경 사항을 밀어붙이는 경향이 있습니다.

우리의 캠프파이어 봇인 Hubot은 모든 직원을 위해 배포할 수 있으므로 간단합니다.

hubot depoy github to production

코드를 배포하고 제로 다운타임은 필요한 모든 프로세스를 다시 시작합니다. GitHub에서 이것이 얼마나 일반적인지 확인할 수 있습니다.

하루에 약 24번 배포하는 6명의 다른 사람(지원 담당자 및 디자이너 포함)을 볼 수 있습니다.

한 줄 변경이 포함된 하나의 커밋이 있는 분기에 대해 이 작업을 수행했습니다. 이 프로세스는 간단하고 간단하며 확장 가능하고 강력합니다. 2주가 걸리는 50개의 커밋 또는 10분이 소요된 1개의 커밋이 있는 기능 브랜치로 이를 수행할 수 있습니다. 매우 간단하고 마찰이 없는 프로세스이므로 1개의 커밋에도 수행해야 하는 번거로움이 없습니다. 즉, 변경 사항이 너무 작거나 중요하지 않아 중요하지 않은 경우가 아니면 사람들이 프로세스를 건너뛰거나 우회하려고 하는 경우가 거의 없습니다. .

이것은 매우 간단하고 강력한 프로세스입니다. 나는 대부분의 사람들이 GitHub의 플랫폼이 매우 안정적이고 문제가 발생하면 신속하게 해결되며 새로운 기능이 빠른 속도로 도입된다는 데 동의할 것이라고 생각합니다. 더 빠른 속도나 단순성 또는 더 적은 프로세스를 얻을 수 있도록 품질이나 안정성에 대한 타협은 없습니다.

결론

Git 자체는 이해하기가 상당히 복잡하므로 함께 사용하는 워크플로를 필요 이상으로 복잡하게 만드는 것은 단순히 모든 사람의 하루에 정신적 오버헤드를 추가하는 것입니다. 나는 항상 당신의 팀을 위해 작동할 수 있는 가장 간단한 시스템을 사용하고 더 이상 작동하지 않을 때까지 그렇게 한 다음 절대적으로 필요한 경우에만 복잡성을 추가하는 것을 옹호합니다.

더 긴 기간(릴리스 사이에 몇 주에서 몇 개월)에 공식 릴리스를 수행해야 하고, 핫픽스 및 유지 관리 분기 및 드물게 배송으로 인해 발생하는 기타 작업을 수행할 수 있는 팀의 경우 git-flow 는 감각과 나는 그것을 사용하는 것을 강력히 옹호할 것입니다.

배송 문화를 설정하고 매일 프로덕션을 추진하고 지속적으로 테스트 및 배포하는 팀의 경우 GitHub Flow와 같은 더 간단한 것을 선택하는 것이 좋습니다.