최근 신규 채용 관련 지식 교육 자식 워크 플로우입니다. 오랫동안 사용 된이 일을 이눔 아,하지만 어떻게 자식 워크 플로우 협업을 통해 팀이 실제로 문제가 만들 수 있습니다. 일부 동료들은 이전에 코드 관리 소프트웨어와 같은 TFS, 자식은 매우 익숙하지 않은, SVN 사용했다, 일부는 자식을 사용하고 있지만, 과정의 무언가가 필요가 작동이 방법을 사용하는 이유를 명확 특히, 익숙하지 않은 . 오늘 우리는 수다로 본다.
자식
자식 코드 관리 도구를 배포됩니다. 로컬 프로그래머의 원격 코드베이스 및 유지, 이외에도 코드베이스를 유지할 수있다. 그래서 준비 코드 이후에 제출하고, 요청을 당겨 않는 원격 코드 라이브러리 네이티브 코드 라이브러리에서 코드의 완료 후 제출하면 검토 후로, 정상적인 상황에서, 우리는 원격에서 코드를 얻을 수 있고, 지역 도서관에 동기화 당신은 원격 코드 라이브러리에 코드 병합을 넣을 수 있습니다.
당신이 수있는이 방법은 어떤 네트워크 / 원격 코드 라이브러리에 연결하지 않는 경우에 우리는 로컬 코드를 체크인하고, 지금하고 많은 팀이 사용이 네이티브 코드 변경의 여러 버전을 저장할 수 있습니다.
자식 흐름
자식 흐름은 실제로 코드 관리를 위해 자식 최상의 방법을 사용합니다. 코드를 제출할 때 버전을 관리하는 방법, 지점을 생성하는 방법, 코드베이스를 정의하는 방법을 포함. 그것은 연습 표준의 자식 세트를 사용하여 의미합니다. 나는 당신이 그렇게 사용하는 것이 좋습니다.
본점 : 긴 개발자가 네이티브 코드 라이브러리를 분기하는 중심 코드베이스에서.
마스터 지점 : 각 지점에 대한 최종 버전을 릴리스합니다. 우리가 일반적으로 게시 할 때마다 릴리스 이상의 지점, 라벨 표시 한 번 우리가 성공적으로 게시 한 릴리스 분기를 생성하고 병합 된 지점의 마스터 버전이 성공을 넣어 것입니다.
Develop分支：开发使用的分支，当开始一个sprint的开发的时候，程序员会从Devleop分支上面拉出一个Feature分支进行开发。一个Release版本发布成功以后也会合并到Develop分支。
Feature分支：从Develop分支拉出的一个分支，用来针对一个具体功能进行开发。开发人员完成Feature分支的开发以后，先要拉取一次Develop分支的内容在本地做一次合并，然后在推送Pull Request到远程的Develop分支进行Code Review。Code Review通过了才能把代码合并到远程的Develop分支。
Release分支：顾名思义每次发布版本的时候会生成对应版本的release分支。例如：要发布版本1.0，在发布过程中会遇到各种紧急的bug通常会在Release分支上做修改。生成1.0.1，1.0.2的Release版本。一旦发布成功，会把最后一个Release分支的版本合并到Master和Developer分支上面去。
github-flow
由于git-flow被广泛使用并且在业内被视为标准，所以很多公司都在使用。但是，由于其实际操作相对复杂，对于团队规模不是很大的企业来说显得有点繁琐了。这时候一个叫Scott Chacon的兄弟（GitHub）在自己的blog上面推荐了一款github-flow的工作方式，这个方式相对于git-flow要简单一些。其实就是简化版本的git-flow
master内容可以进行发布
开发新功能的时候可以直接在master上面建立分支
개발 지점의 완성은 상기 할 언급 한 코드 리뷰를 마스터 및 병합에 직접 전송
릴리스는 마스터 분기 아래에 발표 될 예정이다 때
위의 과정은, 분명히, 단지 마스터 지점, 테스트, 출시를 위해 개발되는 것을. 어떤 기능이없는, 개념 릴리스. 시간과 빠른 작업과 더 유사 워크숍의 상황. 작은 팀이 운영하는 몇 가지 규칙이 곧 적절한 시작합니다.
높은 기사를 읽고 추천