Git Branches & Buddy를 사용하여 프로젝트 코드를 구성하는 방법

이 기사는 Buddy와 공동으로 만들어졌습니다. Sitepoint를 가능하게 한 파트너를 지원해 주셔서 감사합니다.

이 기사에서는 분기 워크 플로우를위한 지속적인 통합/배포 파이프 라인을 설정하는 방법에 대해 안내합니다. Buddy CI/CD 서비스를 사용하여 이러한 파이프 라인을 설정합니다. 우리는 기본 JavaScript 프로젝트를 사용하여 여러 개발 지점을 설정할 것입니다. 각 유형의 지점에서 테스트를 자동화하는 방법을 보여 드리겠습니다. 또한 지점 워크 플로의 개념을 소개하고 프로젝트에서 취할 수있는 몇 가지 예를 보여 드리겠습니다. 키 포인트

git 브랜치는 개발자가 기본 코드베이스에 영향을 미치지 않고 동시에 다양한 기능이나 버그 수정을 처리 할 수 ​​있기 때문에 소프트웨어 개발에 중요합니다. 이는 효율성을 향상시키고 생산 코드에 오류를 도입 할 위험을 줄입니다.

다른 GIT 지점 정책에는 제로 브랜치 정책, 개발 지점 정책, 지점 정책 및 gitflow 지점 정책이 포함됩니다. 각 전략에는 장단점이 있으며 선택은 프로젝트 규모, 개발자 수 및 프로젝트의 복잡성에 따라 다릅니다.

Buddy CI/CD 서비스를 사용하여 분기 워크 플로우를위한 지속적인 통합/배포 파이프 라인을 설정할 수 있습니다. 이를 통해 테스트 실행 및 웹 서버에 배포와 같은 작업을 자동화 할 수 있습니다. 버디를 사용하면 마스터 브랜치, 개발/통합 브랜치, 기능 분기 및 핫 수리 분기를 포함한 다양한 GIT 지점 정책에 대한 파이프 라인을 설정할 수 있습니다. 각 파이프 라인은 지점의 역할에 따라 특정 작업을 실행하도록 구성 할 수 있습니다. 공유 저장소에 장기 분기를 설정하여 파이프 라인을 효율적으로 생성하는 것이 좋습니다. 또한 와일드 카드를 사용하여 여러 기능 및 핫 수리 분기 용 파이프를 설정할 수 있습니다.

전제 조건
이 튜토리얼을 배우려면 기본 Node.js 기술 만 있으면됩니다. 또한 Git에 익숙해야합니다. 다음은 도움을 줄 수있는 몇 가지 기사입니다
• git의 초보자 git 팀 협업 우리의 책, "Jump Start git"
파이프 라인을 설정하려면 농담을 사용하여 테스트를 작성해야합니다. Jest에 익숙하지 않은 경우 배울 필요가 없습니다.이 기사의 초점은 자동으로 새 지점을 선택하고 구축 할 파이프 라인을 설정하는 방법을 배우는 것입니다. 시작하기 전에 사용할 수있는 다양한 분기 전략을 살펴 봐야합니다.
제로 브랜치 전략
제로 브랜치 전략은 단지 "당신이 지점 전략을 사용하고 있지 않다"는 말입니다. 기본 워크 플로라고도합니다. 버전을 직접 커밋하고 구축 할 수있는 마스터 브랜치가 하나뿐입니다. 이 전략은 프로젝트가 다음 조건을 충족하면 편리하고 좋습니다.
작고 간단한 빈 업데이트는 거의 불필요합니다 단일 개발자가 관리합니다 이 유형의 프로젝트에는 자습서, 데모, 프로토 타입, 입문 프로젝트 템플릿 및 개인 프로젝트가 포함됩니다. 그러나이 방법에는 몇 가지 단점이 있습니다
• 한 명 이상이 프로젝트를 진행하는 경우 여러 합병 충돌이 발생할 가능성이 있습니다
당신은 동시에 여러 기능을 개발할 수없고 문제를 해결할 수 없습니다
• . 삭제 및 복원 기능은 어려운 작업이됩니다 팀은 새로운 기능을 개발하는 대신 버전 제어 문제를 다루는 데 너무 많은 시간을 소비합니다.
이러한 모든 문제는 분기 전략을 채택하여 해결할 수 있습니다. 이것은 다음과 같은 것을 제공해야합니다 :

팀원에게 영향을 미치지 않고 독립적으로 작업하고 공유 리포지토리로 변경할 수있는 능력

팀 동료의 코드를 변경하여 변경 및 발생할 수있는 충돌을 신속하게 해결할 수있는 능력
팀 규모에 관계없이 코드 표준이 유지되고 협업 작업이 순조롭게 진행되도록하십시오.
• 여러 유형의 지점 워크 플로에서 자유롭게 선택할 수 있습니다. 또한 자신에게 적합한 사용자 정의 지점 워크 플로를 만들 수도 있습니다. 가장 간단한 분기 전략부터 시작하겠습니다.
• 지점 전략을 개발하십시오
• 이 정책에서는 본 분기와 병렬로 실행되는 Develop이라는 장기 지점을 설정합니다. 모든 작업은 먼저 개발 지점에 최선을 다하고 있습니다. 프로젝트를 중단 할 수있는 코드를 소개 할 수있는 안전한 장소입니다. 변경 사항이 병합 될 때 메인 브랜치에 오류가 도입되지 않도록 테스트 전략이 필요합니다.
이 워크 플로의 장점은 다음과 같습니다
• 구현하기 쉬운 개발 지점에서 실험 작업을 수행하는 한, 주 지점은 안정적이고 건강하게 유지됩니다 핫 수리는 현재 기능이 현재 구현되고있는 동안 언제든지 메인 브랜치에서 구현할 수 있습니다

이 워크 플로의 단점은 다음과 같습니다

동시에 여러 기능을 개발하지 않으려는
한 명의 개발자 (최대 2 명) 만 프로젝트에 적극적으로 참여할 수 있습니다 지점 삭제 및 복구 기능 만 사용하는 것은 도전입니다. 이러한 도전을 완화시킬 수있는 다른 워크 플로를 살펴 보겠습니다.
기능 분기 전략
• 이 워크 플로에서는 새로운 기능을 개발할 때마다 새로운 기능 지점을 설정합니다. 문제가있는 경우 항상 메인 브랜치에 핫 수정 사항을 적용 할 수 있습니다. 개발자는 기능 지점을 메인 브랜치로 병합하기 전에 메인 브랜치에서 최신 수정 사항을 추출해야합니다.
현재 개발중인 기능 및 버그 수정 사항을 추적하려면 지점에 대한 명명 대회를해야합니다. 인터넷에서 찾을 수있는 몇 가지 형식 제안 사항은 다음과 같습니다.
사용자/username/description 사용자/username/workitem > 버그 픽스/설명 기능/기능-이름 기능/기능-영역/기능-이름 기능/ID ( "ID"는 프로젝트 관리 도구에 의해 생성됩니다) > hotfix/description 이 전략의 장점은 다음과 같습니다
• 당신은 프로젝트에 동시에 많은 수의 개발자를 가질 수 있고 여러 기능을 처리 할 수 ​​있습니다. 마음을 바꾸면 기능을 삭제하고 나중에 복원하기가 쉽습니다 . 각 개발자가 작업중인 내용을 쉽게 추적 할 수 있습니다.
이 전략의 단점은 다음과 같습니다
• 함수의 동시 개발이 다른 미개발 함수에 의존하는 하나의 함수를 구현하는 데 항상 가능하지는 않습니다. 이것은 모든 종속성이 완료 될 때까지 함수를 기본 분기로 푸시 할 수 없음을 의미합니다.
다음 전략을 살펴 보고이 문제를 어떻게 완화 할 수 있는지 살펴 보겠습니다.
gitflow branch 전략
"개발"과 "피처"브랜치 워크 플로를 결합 할 수 있다면 서로의 단점을 제거 할 수있는 솔루션을 얻을 수 있습니다. Vincent Driessen은 대규모 팀이 복잡한 프로젝트에서 효율적으로 협력하고 버전 제어 문제를 최소화하는 데 도움이되는 고급 GIT 분기 모델을 설명하는 블로그 게시물을 작성했습니다.
gitflow는 프로젝트와 팀에 가장 적합한 기능을 선택할 수있는 사용자 정의 가능한 모델입니다. Gitflow를 사용하는 경우 Daniel Kummer의 Git Extension을 GIT로 가져갈 수 있습니다. 이 도구를 사용하면 개발자가 Vincent의 모델을 기반으로 고급 리포지토리 작업을 수행 할 수 있습니다. 나는 이것에 깊이 들어 가지 않을 것이지만 여기에 알아야 할 것이 있습니다.
프로 :
복잡한 프로젝트에서 일하는 대규모 팀의 경우 활동 기능 및 조직 버전을 쉽게 추적 할 수 있습니다
• 단점 :
소규모 프로젝트에는 너무 복잡합니다
• 이제 Buddy CI 서비스를 사용하여 지점에서 작업을 자동화하는 방법을 살펴 보겠습니다.
분기 모델 파이프 라인
• 먼저 간단한 프로젝트를 설정하고 파이프 라인을 설정하는 데 사용해야합니다. 변경 사항을 자동으로 추출하고 테스트를 실행하는 파이프 라인을 만듭니다. 먼저 새로운 Github 저장소를 만듭니다. 이름을 버디 데모로 지정하십시오.

다음, 다음 입력 프로젝트를 다운로드하여 저장소로 푸시하십시오 :

이 프로젝트는 소포를 사용하여 구축 된 간단한 반응 프로젝트입니다. 다음 명령을 실행하여 실행 중인지 확인할 수 있습니다.
• Visual Studio 코드를 사용하는 경우 F5를 눌러 브라우저를 시작하십시오. 그렇지 않으면 브라우저 페이지를 열고 LocalHost : 1234로 이동하십시오.

보시다시피, 특별한 것은 없습니다. Buddy CI에 배치하기 전에 테스트를 작성해야합니다. 우리는 이것을 위해 Jest 테스트 프레임 워크를 사용할 것입니다 :

<.> NPM 테스트 명령이 실행될 때 jest를 실행하려면 package.json 스크립트 섹션을 업데이트하십시오.

<code>$ git clone git@github.com:brandiqa/react-parcel-starter.git buddy-demo
$ git remote rm origin
# 将`username`替换为您自己的用户名
$ git remote add origin git@github.com:username/buddy-demo.git
$ git config master.remote origin
$ git config master.merge refs/heads/master
$ git push -u origin master
</code>

약간 srcapp.jsx를 업데이트합시다

다음, 통과 가능한 테스트를 작성합시다. 파일 app.test.js를 만들고이 코드를 삽입하십시오 :

<code>$ npm install
$ npm start
</code>

테스트가 통과되었는지 확인하기 위해 NPM 테스트 명령을 실행하십시오.

<code>$ npm install -D jest
</code>

변경 사항을 제출하여 Github 저장소로 밀어 넣으십시오. 다음으로 Buddy에 CI 파이프 라인을 설정합니다. 플랫폼에 익숙하지 않은 경우 GitHub 계정을 사용하여 무료 계정에 가입하십시오. Buddy는 Github 이외의 많은 원격 저장소 서비스를 지원합니다.

선택한 서비스 제공 업체에 관계없이 버디는 자동화를 설정할 수있는 저장소를 나열합니다. 이 예에서는 Buddy-Demo 프로젝트를 선택합니다. "새 파이프 라인 추가"버튼을 클릭하고 다음 페이지의 다음 세부 정보를 입력하십시오.

이름 - 메인 브랜치 트리거 모드 - 를 밀 때 브랜드 - 단일 지점 : 마스터 브랜치

<code> "scripts": {
   //...
    "test": "jest"
  },
</code>

메인 브랜치 파이프 라인에서 다음을 설정합니다.

실행 테스트 번들 앱 웹 서버에 배포

다음 페이지에서는 동작을 정의하는 다른 방법이 나타납니다. node.js를 선택하고 다음 페이지에서 다음 명령이 지정되어 있는지 확인하십시오.

작업 탭에서 작업 이름의 이름을 바꿀 수 있습니다. 내가 지적하고 싶은 것은 테스트가 데이터베이스 서비스가 필요한 경우 서비스 탭을 통해 하나를 설정할 수 있다는 것입니다.

가장 인기있는 데이터베이스는 이미 지원되었습니다. 데이터베이스 유형을 선택하고 연결 세부 정보 및 자격 증명을 제공하십시오. 완료되면이 버튼을 추가하십시오. 다음 페이지에서 하단의 플러스 버튼을 클릭하여 번들 리소스 작업을 추가하십시오. Node.js를 다시 선택하고 다음 페이지에서 다음 명령을 입력하십시오.

<code>$ git clone git@github.com:brandiqa/react-parcel-starter.git buddy-demo
$ git remote rm origin
# 将`username`替换为您自己的用户名
$ git remote add origin git@github.com:username/buddy-demo.git
$ git config master.remote origin
$ git config master.merge refs/heads/master
$ git push -u origin master
</code>

동작 탭에서 리소스를 번들로 만드는 작업의 이름을 바꿉니다. 완료되면이 추가를 클릭하십시오. 플러스 부호를 다시 클릭하여 배포를 생산 동작에 추가하십시오. 버디의 다른 유형의 호스팅 공급 업체에 프로젝트 배포에 대한 버디 네이티브 지원 :

이러한 서비스에 계정이있는 경우 배포 옵션을 자유롭게 사용하십시오. 하나가없는 경우, 무료 계정을 설정하여 응용 프로그램을 배포 할 수있는 공급자를 선택하십시오. 제 경우에는 이미 사용할 수있는 공유 웹 호스팅 계획 계정이 있습니다. 일반적으로 주요 웹 사이트 www.domainname.com에 프로젝트의 라이브 프로덕션 버전을 호스팅 할 수 있습니다.

개발 또는 통합 브랜치 파이프 라인에서 배포 된 별도의 스테이징 사이트 (일반적으로 공개적으로 숨겨져 있음)가 있어야합니다. 스테이징 사이트는 단지 하위 도메인 일 수 있으며 검색 엔진은 색인을 인덱싱해서는 안됩니다. 스테이징 사이트를 통해 개발자, 프로젝트 관리자 및 테스터는 라이브 프로덕션 사이트로 밀기 전에 새로운 기능이 제대로 작동하고 있음을 확인할 수 있습니다.

공유 또는 전용 웹 호스팅 서버 (CPANEL 사용)에 응용 프로그램을 배포하려면 FTP 메소드 만 사용하십시오. Buddy는 또한 서버에 업로드 할 때 프로젝트 리소스 패키지를 암호화하는 SFTP 메소드를 제공합니다. 다음은 내가 내 설정 방법의 예입니다.

CPANEL을 사용하여 새 FTP 계정을 설정해야합니다. 새 FTP 사용자 계정의 홈 디렉토리가 www 또는 하위 도메인 폴더를 직접 지적하는지 확인하십시오. 그렇지 않으면 FTP를 통해 올바른 관리 디렉토리에 액세스하지 못할 수 있습니다. 파이프 라인에서 세 가지 작업을 모두 설정 한 후 다음을 수행 할 수 있습니다.

파이프 라인을 수동으로 실행하십시오 새로운 코드를 원격 저장소로 푸시하면 버디가 자동으로 실행됩니다

완료 후 완전한 파이프 라인은 다음과 같습니다 gitflow 워크 플로 또는 이와 유사한 것을 사용하고 있다고 가정하면 다음과 같은 다른 파이프 라인을 설정해야 할 수도 있습니다.

개발/통합 분기

기능 분기 핫 수리 지점 개발 분기 파이프 라인은 메인 브랜치 파이프 라인과 거의 동일합니다. 그러나 스테이징 사이트에 코드를 배포하려면 배포에 대한 다른 구성을 제공해야합니다. 기능적 및 핫 수리 분기 파이프는 최소한 테스트 작업을 위해서만 구성하면됩니다. 기능 분기 파이프 라인에서 실행할 수있는 테스트 수를 제한 할 수 있습니다. 테스트 명령에 간단히 추가하여 Jest -Coverage -changedsince = Master에 추가하여 쉽게이 작업을 수행 할 수 있습니다. 이것은 메인 브랜치로 푸시되지 않은 새 코드 만 테스트합니다.

여러 기능과 핫 수정 분기가 있기 때문에이 상황에 대한 파이프 라인을 설정하는 방법을 알고 싶을 수도 있습니다. 매우 간단합니다 - 와일드 카드 옵션을 사용하십시오 :

개발/기능*/hotfix* 파이프 라인이 작동하는지 확인하려면 컴퓨터에 분기를 만듭니다. 이 예에서는 임의의 기능 분기를 만들어 봅시다 : 그런 다음 app.test.js : 에서 새로운 테스트를 만듭니다

다음, 변경 사항을 저지르고 지점을 Github 저장소로 밀어냅니다.

<code>$ git clone git@github.com:brandiqa/react-parcel-starter.git buddy-demo
$ git remote rm origin
# 将`username`替换为您自己的用户名
$ git remote add origin git@github.com:username/buddy-demo.git
$ git config master.remote origin
$ git config master.merge refs/heads/master
$ git push -u origin master
</code>

버디 계정 대시 보드로 빠르게 전환하면 파이프 라인이 새 지점을 선택하고 정의한 조치를 실행해야합니다. 이것은 프로젝트가 채택한 지점 정책 워크 플로우에 대한 파이프 라인을 설정하는 방법입니다.

요약

<code>$ npm install
$ npm start
</code>

마지막으로 주목해야 할 것은 장기 지점을 계획하면 먼저 공유 저장소에 설정하는 것이 가장 좋습니다. 이렇게하면 새 파이프 라인 생성을 시작할 때 선택 분기 옵션을 사용하여 장기 분기를 선택할 수 있습니다.

우리는 이제이 튜토리얼을 완료했습니다. 과제로, 뜨거운 수리 및 개발을위한 파이프 라인을 계속 설정하십시오. 일부 분기를 만들고 실패한 테스트를 작성하여 어떤 일이 발생하는지 확인하십시오. GIT 분기 전략에 대해 계속 연구 할 수도 있습니다. git-flow를 설치하고 도구를 사용하여 자신의 지점 워크 플로우를 사용자 정의 할 수도 있습니다. 그런 다음 버디 파이프 라인을 설정하여 사용자 정의 GIT 브랜치 워크 플로우를 지원하십시오.

git 분기 사용에 대한 FAQS (FAQ)

<code>$ npm install -D jest
</code>

소프트웨어 개발에서 git 브랜치를 사용하는 것이 무엇입니까?

Git Branch는 모든 소프트웨어 개발 프로세스의 중요한 부분입니다. 개발자는 기본 코드베이스에 영향을 미치지 않고 동시에 다른 기능이나 버그 수정을 처리 할 수 ​​있습니다. 이는 개발자가 기존 코드를 위반하지 않고 안전한 환경에서 새로운 아이디어를 실험 할 수 있음을 의미합니다. 새 기능 또는 버그 수정이 성공하면 메인 코드 기반으로 다시 병합 할 수 있습니다. 이로 인해 개발 프로세스가보다 효율적으로 만들어지고 생산 코드에 오류를 도입 할 위험이 줄어 듭니다.

git에서 새 지점을 만드는 방법은 무엇입니까?

git에서 새 지점을 만드는 것은 간단합니다. Git Branch 명령과 새 지점의 이름을 사용할 수 있습니다. 예를 들어, Git Branch New-Feature는 "New-Feature"라는 새 지점을 만듭니다. 지점을 만든 후 GIT 체크 아웃 명령을 사용하여 다음과 같이 해당 지점으로 전환 할 수 있습니다. GIT Checkout New-Feature. 한 분기에서 다른 지점으로 변경 사항을 병합하는 방법은 무엇입니까? 한 분기에서 다른 분기로 변경 사항을 병합하는 것은 git merge 명령을 사용하여 git에서 수행됩니다. 먼저 변경 사항을 병합하려는 분기로 전환해야합니다. 이것은 GIT 체크 아웃 명령을 사용하여 수행 할 수 있습니다. 올바른 지점에 있으면 Git Merge

를 사용하여 다른 지점의 변경 사항을 병합 할 수 있습니다. 예를 들어, "new-feature"라는 지점에서 "마스터"지점으로 변경하려면 먼저 "마스터"지점에 체크 아웃 한 다음 Git Merge New-Feature를 실행합니다.

Git Branch 충돌이란 무엇이며 해결 방법은 무엇입니까?

git 브랜치 충돌은 두 명 이상의 개발자가 다른 지점에서 코드 기반의 동일한 부분을 변경 한 다음 해당 변경 사항을 병합 할 때 발생합니다. Git은 어떤 변화를 유지 해야하는지, 폐기 할 것인지를 알지 못하여 갈등이 발생합니다. 충돌을 해결하려면 충돌하는 파일을 수동으로 편집하여 유지할 변경 사항을 결정해야합니다. 충돌이 해결되면 GIT 추가를 사용하여 분해 된 파일을 준비 영역에 추가 한 다음 GIT 커밋을 사용하여 변경 사항을 커밋 할 수 있습니다.

git에서 분기를 삭제하는 방법은 무엇입니까?

git에서 분기를 삭제하는 것은 git branch -d 명령과 분기 이름을 사용하여 수행됩니다. 예를 들어, Git Branch -d Old-Feature는 "Old-Feature"라는 지점을 삭제합니다. 그러나 지점에 병합되지 않은 변경 사항이 있으면 GIT를 사용하면 분기를 삭제할 수 없습니다. 분기를 삭제하고 이러한 변경 사항을 잃어버린 경우 다음과 같이 -D 옵션을 대신 사용할 수 있습니다. Git Branch -D Old -Feature.

git 저장소에서 모든 지점을 보는 방법은 무엇입니까?

당신은 git branch 명령 (매개 변수가없는)을 사용하여 GIT 저장소의 모든 분기를 볼 수 있습니다. 여기에는 저장소의 모든 분기가 나열되며 현재 분기에는 별표가 표시되어 있습니다.

git의 로컬 브랜치와 원격 지점의 차이점은 무엇입니까?

git의 로컬 브랜치는 로컬 기계에만 존재하는 지점이며, 원격 분기는 원격 저장소에 존재하는 지점입니다. 저장소를 복제 할 때 Git은 모든 원격 분기에 대한 로컬 브랜치를 만듭니다. 이 로컬 브랜치를 처리 한 다음 준비되면 원격 브랜치로 변경 사항을 푸시 할 수 있습니다.

git 지점의 이름을 바꾸는 방법은 무엇입니까?

git 브랜치의 이름을 바꾸는 것은 Git Branch -m 명령과 이전 지점 이름과 새 지점 이름을 사용하여 수행됩니다. 예를 들어, Git Branch -m Old-Name New-Name은 Branch "Old-Name"으로 이름을 "New-Name"으로 바꿀 것입니다. 현재 이름을 바꾸고 싶은 지점에있는 경우 다음과 같이 이전 지점 이름을 생략 할 수 있습니다. git branch -m new -name.

git 지점의 변경 사항을 복원하는 방법은 무엇입니까?

git 리버드 명령과 커밋 해시를 사용하여 git 브랜치의 변경 사항을 복원 할 수 있습니다. 이것은 지정된 커밋에서 이루어진 새로운 커밋, 실행 취소 변경을 만듭니다. 예를 들어, GIT는 A867B4AF를 되돌릴 수 있습니다. "A867B4AF"로 해시 된 커밋에서 이루어진 새로운 커밋을 취소합니다.

Git Branch의 커밋 기록을 보는 방법은 무엇입니까?

git log 명령을 사용하여 Git 브랜치의 커밋 기록을 볼 수 있습니다. 이것은 현재 지점에서 이루어진 모든 커밋 목록을 역 순서대로 표시합니다. 다른 지점의 커밋 기록을 보려면 분기 이름을 다음과 같이 지정할 수 있습니다. Git Log Branch-Name.

위 내용은 Git Branches & Buddy를 사용하여 프로젝트 코드를 구성하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!