git 브랜치는 GIT 버전 제어 시스템의 기본 구성 요소입니다. 이 튜토리얼에서 다른 분기 모델을 탐색 할 것입니다
마지막 기사에서 우리는 GIT 및 버전 제어 시스템의 기본 사항에 대해 배웠습니다. 우리는 단계별로 진행하여 Git 저장소를 설정하는 방법을 배웠습니다. 또한 변경 사항을 실행 취소하려는 경우 지점에 변경 사항을 추가하고 되돌리는 방법을 배웠습니다. 이제 우리는 버전 제어 시스템의 기본 사항, 특히 Git을 이해합니다. 따라서이 블로그 게시물에서는 GIT 브랜치를 사용하고 요청을 가져 오는 방법에 대해 논의 할 것입니다. 우리는 다른 워크 플로에 대해 배울 것입니다. 그래서 시작합시다!
git 브랜치는 무엇입니까?
지점과 분기가 필요한 이유와 코드와 효율적으로 작업하는 데 사용할 수있는 분기 전략에 대해 이야기합시다. 이름에서 알 수 있듯이 a 분기 는 루트에서 독립적 인 개발 라인을 나타냅니다. 저장소를 만들 때 기본적으로 분기도 만들어 마스터 (또는 기본값) 지점을 호출 할 수 있습니다. 우리는 마스터 지점에 변경을 저지를 수 있습니다. 그러나 기능을 사용해야하고 코드를 마스터 브랜치와 분리하고 싶지 않은 경우. 그래서 그곳에서 지점이 당신을 도와줍니다. 그들은 당신이 분기를 꺼내고 나중에 병합했습니다.
git 분기를 만들 / 수정합니다
git branch
명령을 사용하면 브랜치를 작성, 목록, 이름 바꾸고 삭제할 수 있습니다. 이를 위해서는 분기간에 전환 할 수 없습니다.이를 위해서는 GIT 체크 아웃 명령을 사용해야합니다. 또는 변경 사항을 분기로 다시 병합하려면 git merge 명령을 사용해야합니다. 지점은 단지 커밋을하는 포인터라는 것을 이해하는 것이 중요합니다. 분기를 만들 때 모든 git가해야 할 모든 것이 새 포인터를 만드는 것입니다. 다른 방식으로 저장소를 변경하지 않습니다. 다음 명령을 사용하여 분기를 만듭니다
git branch <branch-name>
지점에서 작업을 마치고 메인 코드베이스로 병합 한 후 다음 명령을 사용하여 기록을 잃지 않고도를 자유롭게 삭제할 수 있습니다.
git branch -d <branch-name>
풀 요청이란 무엇입니까?
풀 요청은 GIT와 같은 버전 제어 시스템을 사용하여 소프트웨어 프로젝트에 기여를 제출하는 방법입니다. 개발자는 풀 요청을 사용하여 코드베이스에 대한 변경 사항을 제안합니다. 풀 요청이 열리면 공동 작업자와의 잠재적 변경 사항을 논의하고 검토하고 변경 사항이 기본 지점에 병합되기 전에 후속 커밋을 추가 할 수 있습니다. 개발자가 풀 요청을 열면 다른 개발자에게 요청하는 것은 저장소에서 지점을 리포지토리로 끌어냅니다. 즉, 소스 리포지토리, 소스 분기, 대상 저장소 및 대상 분기 등 풀 요청을 만들기 위해 4 개의 입력 값을 제공해야합니다.
인기있는 분기 모델
전 세계 개발자 커뮤니티가 사용하는 숫자 O 브랜치 워크 플로가 있습니다. 그러나 우리는 가장 인기있는 세 가지 분기 모델을 하나씩 논의 할 것입니다.
git 흐름
GitFlow 워크 플로는 지속적인 소프트웨어 개발 및 DevOps 관행 구현에 도움이되는 GIT 워크 플로입니다. GIT 흐름은이 목록에서 가장 잘 알려진 워크 플로입니다. 그것은 2010 년 Vincent Driessen에 의해 만들어졌으며, 그것은 무한한 수명을 가진 두 개의 주요 지점과 기능-*, hotfixes-*와 같은 다른 지원 지점을 기반으로 한 다음 개인으로서 지점으로 통합됩니다. 항목이 완료되었습니다.
- Master -이 지점에는 생산 코드가 포함되어 있습니다. 모든 개발 코드는 생산으로 밀릴 준비가되면 마스터 브랜치로 병합됩니다.
- 개발 -이 분기에는 사전 생산 코드가 포함되어 있습니다. 기능이 완료되면 개발로 병합됩니다. Gitflow는 예정된 릴리스주기가있는 프로젝트에 이상적으로 적합합니다. 그러나 GIT 역사는 읽을 수 없게됩니다.
github 흐름
Github 흐름은 가벼운 워크 플로입니다. 2011 년 Github에 의해 만들어졌으며 주로 릴리스주기를 기다리지 않는 민첩한 모델에 중점을 둡니다. 대신 기능이 완료되면 매일 생산 변경을 추진합니다. Github 흐름은 다음에 다음과 같습니다.
- “마스터"지점의 모든 것을 배포 할 수 있습니다.
- 새로운 작업을 수행하려면 설명 이름이있는 별도의 오프 마스터 브랜치를 만듭니다.
- 해당 지점에 현지에서 정기적으로 작업을 서버의 동일한 이름 지점으로 푸시하십시오.
- 피드백이나 도움이 필요하거나 지점이 병합 될 준비가되었다고 생각하면 풀 요청
- 이 기능을 검토하고 서명 한 후 마스터로 병합 할 수 있습니다.
- 합병되어 ‘마스터’로 밀면 생산에 배치 할 수 있습니다.
gitlab 흐름
Gitlab Flow는 2014 년 Gitlab이 만든 워크 플로입니다. Gitlab Flow는 Gitflow에 대한 간단한 대안이며 기능 중심 개발 및 기능 분기를 문제 추적과 결합합니다. Gitlab 흐름과 Github 흐름의 주요 차이점은 환경 분기를 사용하는 것입니다. 개발자는 개발 지점을 만들고 기본값을 만들고 Gitlab Flow는 ‘메인’지점에서 즉시 작동합니다. Gitlab Flow는 여러 사전 생산 분기를 통합합니다. 그리고 그것들은 다른 수준에서 물건을 테스트하는 데 사용될 수 있습니다. 예 : 테스트 지점에서 수락 및 수락에서 생산에 이르기까지.
결론
이 기사에서는 Git 브랜치와 요청 요청에 대해 배웠습니다. 풀 요청의 중요성과 다양한 GIT 워크 플로우에서 어떻게 사용할 수 있는지 연구했습니다. 우리는 또한 다른 git 분기 모델을 간단히 탐색했습니다.