개발, 스테이징 및 프로덕션 브랜치가있는 git

개발, 스테이징 및 프로덕션 브랜치가있는 git

---

이 기사는 흥미로울 것 같지만 다이어그램이 잘못되었다고 확신합니다. http://guides.beanstalkapp.com/version-control/branching-best-practices.html

그것은해야하지 DEVELOPMENT> STAGING> PRODUCTION?

병합은 한 방향으로 만 진행되어야합니다. 자체 브랜치에서 수행 된 기능 및 버그 수정에서 테스트를위한 스테이징으로 이동합니다. 테스트를 마치면 개발에서 프로덕션으로 이러한 변경 사항을 병합 할 수 있습니다.

여기서 나는 약간 혼란스러워합니다. 그래서 스테이징을 마스터에 병합하거나 마스터를 스테이징에 병합합니까?

SmartGit이라는 클라이언트를 사용하고 있는데이 점에 대해 혼란스러워합니다. 일반적으로 기능에 대한 분기를 만들고 커밋 한 다음 마스터로 전환하고 분기에 병합합니다 (앞으로). 따라서 스테이징 및 프로덕션이 포함 된이 새로운 워크 플로에서이 두 개의 추가 브랜치를 만든 다음 내 기능에 대한 마스터 (일명 dev)에서 브랜치를 만듭니다. 커밋 한 다음 스테이징으로 전환하고 기능 브랜치에 병합 (전달) 하시겠습니까? 맞습니까?

---

실제로 이것을 혼란스럽게 만든 것은 Beanstalk 사람들이 매우 비표준적인 스테이징 사용 뒤에 서 있다는 것입니다 (다이어그램에서 개발 전에 제공되며 실수가 아닙니다! https://twitter.com/Beanstalkapp/status/306129447885631488

Beanstalk와 Github를 잊기로 결정했습니다.

---

내가이 글을 올린 이후로 Beanstalk 사람들은 내 힌트를 받아 스테이지 이름을 변경하여 이제 Development "Stable"이라고 부릅니다.

---

여기서 생각하는 과정은 대부분의 시간을 development. 개발 feature중에는 브랜치 를 생성하고 (에서 벗어난 development) 기능을 완성한 다음 development. 그런 다음에 병합하여 최종 프로덕션 버전에 추가 할 수 있습니다 production.

이 접근 방식에 대한 자세한 내용은 성공적인 Git 분기 모델 을 참조하십시오 .

---

우리는 다르게합니다. IMHO 우리는 더 쉬운 방법으로 그것을합니다 : master우리는 다음 메이저 버전을 작업하고 있습니다.

각각의 큰 기능은 자체 분기 (마스터에서 파생 됨)를 가져오고 개발자가 정기적으로 마스터 위에 다시 기반 (+ 강제 푸시)됩니다. 리베이스는 단일 개발자가이 기능에 대해 작업하는 경우에만 제대로 작동합니다. 기능이 완료되면 마스터에 새로 리베이스 된 다음 마스터가 최신 기능 커밋으로 빨리 감 깁니다.

리베이스 / 강제 푸시를 방지하기 위해 마스터 변경 사항을 피쳐 브랜치에 정기적으로 병합하고 완료되면 피쳐 브랜치를 마스터로 병합 할 수도 있습니다 (일반 병합 또는 스쿼시 병합). 그러나 IMHO는 기능 브랜치를 덜 명확하게 만들고 커밋을 재정렬 / 정리하는 것을 훨씬 더 어렵게 만듭니다.

새 릴리스가 나오면 마스터에서 사이드 브랜치를 만듭니다. 예를 들어 release-5버그만 수정됩니다.

---

실제로 이것을 너무 혼란스럽게 만든 것은 Beanstalk 사람들이 매우 비표준적인 스테이징 사용 뒤에 서 있다는 것입니다 (다이어그램에서 개발 전에 제공되며 실수가 아닙니다!

https://twitter.com/Beanstalkapp/status/306129447885631488

---

git의 가장 좋은 점 중 하나는 자신에게 가장 잘 맞는 작업 흐름을 변경할 수 있다는 것입니다. 저는 http://nvie.com/posts/a-successful-git-branching-model/을 대부분 사용 하지만 필요에 맞는 모든 워크 플로우를 사용할 수 있습니다.

참고 URL : https://stackoverflow.com/questions/15072243/git-with-development-staging-and-production-branches