Git 명령을 배웠지만 CI(지속적 통합)가 실제로 어떻게 작동하는지 상상하고 싶으십니까? 아니면 일상 활동을 최적화하고 싶으신가요? 이 과정에서는 GitHub 저장소를 사용한 지속적인 통합에 대한 실용적인 기술을 제공합니다. 이 과정은 간단히 클릭할 수 있는 마법사가 아니라 오히려 사람들이 실제로 직장에서 하는 것과 동일한 작업을 동일한 방식으로 수행하게 됩니다. 관련된 단계를 진행하면서 이론을 설명하겠습니다.

우리는 무엇을해야합니까?

진행하면서 점차적으로 일반적인 CI 단계 목록을 만들 것이며, 이는 이 목록을 기억하는 좋은 방법입니다. 즉, 지속적인 통합을 하면서 개발자가 취하는 행동 목록, 지속적인 통합을 수행하는 것입니다. 또한 CI 프로세스를 실제 프로세스에 더 가깝게 만들기 위해 간단한 테스트 세트를 사용할 것입니다.

이 GIF는 과정을 진행하면서 저장소의 커밋을 개략적으로 보여줍니다. 보시다시피 여기에는 복잡한 것이 없으며 가장 필요한 것만 있습니다.

다음과 같은 표준 CI 시나리오를 진행하게 됩니다.

• 기능 작업
• 품질을 보장하기 위해 자동화된 테스트를 적용합니다.
• 우선순위 작업의 구현
• 브랜치 병합 시 충돌 해결(병합 충돌)
• 프로덕션 환경에서 오류가 발생합니다.

무엇을 배울 것인가?

당신은 다음 질문에 대답할 수 있을 것입니다:

• 지속적 통합(CI)이란 무엇입니까?
• CI에는 어떤 유형의 자동화된 테스트가 사용되며 어떤 작업에 대한 응답으로 트리거됩니까?
• 끌어오기 요청은 무엇이며 언제 필요합니까?
• 테스트 주도 개발(TDD)이란 무엇이며 CI와 어떤 관련이 있나요?
• 변경 사항을 병합하거나 리베이스해야 합니까?
• 다음 버전에서 롤백하거나 수정하시겠습니까?

처음에는 "풀 리퀘스트"와 같은 것을 모든 곳에서 번역했지만 결과적으로 텍스트의 광기 정도를 줄이기 위해 일부 장소에서는 문구를 영어로 반환하기로 결정했습니다. 나는 때때로 사람들이 직장에서 실제로 사용하는 멋진 동사 "commit"처럼 "programmer surzhik"을 사용할 것입니다.

지속적 통합이란 무엇입니까?

지속적인 통합, 또는 CI는 각 팀 구성원이 자신의 코드를 하루에 한 번 이상 공통 저장소에 통합하고 결과 코드가 최소한 오류 없이 빌드되어야 하는 기술 관행입니다.

이 용어에 대해서는 의견이 분분합니다.

논쟁의 포인트는 통합 빈도입니다. 어떤 사람들은 하루에 한 번만 코드를 병합하는 것만으로는 실제로 지속적으로 통합하기에는 충분하지 않다고 주장합니다. 모든 사람이 아침에 새로운 코드를 가져와 저녁에 한 번 통합하는 팀의 예가 제공됩니다. 이것이 합리적인 반대이긴 하지만 일반적으로 하루에 한 번이라는 정의는 합리적으로 실용적이고 구체적이며 다양한 규모의 팀에 적합하다고 믿어집니다.

또 다른 반대 의견은 C++가 더 이상 개발에 사용되는 유일한 언어가 아니며 단순히 검증 방법으로 오류 없는 어셈블리를 요구하는 것은 약하다는 것입니다. 일부 테스트 세트(예: 로컬로 실행되는 단위 테스트)도 성공적으로 완료되어야 합니다. 현재 커뮤니티는 이를 요구 사항으로 만드는 방향으로 나아가고 있으며, 아직 그렇지 않은 경우 "빌드 + 단위 테스트"가 아마도 일반적인 관행이 될 것입니다.

지속적인 통합 다른 지속적인 전달 (지속적인 전달, CD) 각 통합 주기 후에 릴리스 후보가 필요하지 않습니다.

과정 전체에서 사용할 단계 목록

1. 최신 코드를 가져오세요. 다음에서 지점 만들기 master. 일을 시작하다.
2. 새 브랜치에 커밋을 생성하세요. 로컬에서 빌드하고 테스트하세요. 통과하다? 다음 단계로 이동합니다. 실패하다? 오류나 테스트를 수정하고 다시 시도하세요.
3. 원격 저장소나 원격 지점으로 푸시합니다.
4. 풀 요청을 생성합니다. 변경 사항에 대해 논의하고 토론이 계속됨에 따라 더 많은 커밋을 추가합니다. 기능 분기에서 테스트를 통과시킵니다.
5. 마스터에서 커밋을 병합/리베이스합니다. 병합 결과에 대한 테스트가 통과되도록 합니다.
6. 기능 분기에서 프로덕션으로 배포합니다.
7. 일정 기간 동안 프로덕션의 모든 것이 양호하면 변경 사항을 마스터에 병합합니다.

️ 준비

올바른 소프트웨어가 있는지 확인하세요.

이 강좌를 수강하려면 다음이 필요합니다. Node.js를 и 힘내 클라이언트.

모든 Git 클라이언트를 사용할 수 있지만 여기서는 명령줄에 대한 명령만 제공하겠습니다.

명령줄을 지원하는 Git 클라이언트가 설치되어 있는지 확인하세요.

명령줄을 지원하는 Git 클라이언트가 아직 없다면 설치 지침을 찾을 수 있습니다. 여기에.

저장소 준비

개인 복사본(포크)을 만들어야 합니다. 강좌용 코드가 포함된 템플릿 저장소 GitHub에서. 이 개인 사본을 호출하는 데 동의합시다. 코스 저장소.

완료? 기본 설정을 변경하지 않은 경우 코스 저장소가 호출될 가능성이 높습니다. continuous-integration-team-scenarios-students, GitHub 계정에 있으며 URL은 다음과 같습니다.

https://github.com/<ваше имя ползователя на GitHub>/continuous-integration-team-scenarios-students

그냥 이 주소로 전화할게요 <URL репозитория>.

꺾쇠괄호는 다음과 같습니다. <тут> 이는 해당 표현식을 적절한 값으로 바꿔야 함을 의미합니다.

다음을 확인하세요. GitHub 작업 이 코스 저장소에 포함되어 있습니다. 활성화되어 있지 않은 경우 페이지 중앙에 있는 큰 버튼을 클릭하여 활성화하세요. GitHub 인터페이스에서 작업을 클릭하면 해당 버튼으로 이동할 수 있습니다.

GitHub Actions가 활성화되지 않으면 내 지침에 따라 과정을 완료할 수 없습니다.

언제든지 GitHub의 Markdown 렌더링 기능을 사용하여 여기에서 작성 중인 목록의 현재 상태를 확인할 수 있습니다.

https://github.com/<your GitHub user name>/continuous-integration-team-scenarios-students/blob/master/ci.md

답변에 대해

이 과정을 완료하는 가장 좋은 방법은 직접 해보는 것이지만, 몇 가지 어려움이 있을 수 있습니다.

무엇을 해야 할지 이해가 안 되고 계속할 수 없다고 생각되면 스레드를 살펴보세요. solution, 이는 시작 저장소에 있습니다.
병합하지 마세요. solution в master 과정 중에. Git이 제공하는 모든 기능을 사용하여 이 분기를 사용하면 수행할 작업을 파악하거나 코드를 작성자의 코드와 비교할 수 있습니다. 완전히 분실된 경우 지점을 완전히 교체할 수 있습니다. master 가지에 solution 그런 다음 작업 디렉토리를 필요한 코스 단계로 재설정하세요.

정말 필요한 경우에만 사용하세요

코드를 커밋하세요.

git add .
git commit -m "Backing up my work"

이 명령

• 이름 바꾸기 master в master-backup;
• 이름 바꾸기 solution в master;
• 새 지점으로 결제 master 작업 디렉토리의 내용을 다시 작성합니다.
• 나중에 "솔루션" 분기가 필요한 경우를 대비하여 "마스터"(이전에는 "솔루션"임)에서 "솔루션" 분기를 만듭니다.

git branch -m master master-backup
git branch -m solution master
git checkout master -f
git branch solution

이 단계 후에는 다음을 사용할 수 있습니다. git log master 어떤 커밋이 필요한지 알아보세요.
다음과 같이 작업 디렉터리를 이 커밋으로 재설정할 수 있습니다.

git reset --hard <the SHA you need>

결과가 만족스러우면 어느 시점에서는 저장소 버전을 원격 저장소에 게시해야 합니다. 이 작업을 수행할 때 원격 분기를 명시적으로 지정하는 것을 잊지 마세요.

git push --force origin master

사용하고 있으니 참고해주세요 git push --force. 이 작업을 자주 수행할 가능성은 낮지만 여기에는 자신이 수행하는 작업을 이해하고 있는 한 명의 저장소 사용자에 대한 매우 구체적인 시나리오가 있습니다.

일을 시작하다

CI 단계 목록을 컴파일해 보겠습니다. 일반적으로 원격 저장소에서 최신 버전의 코드를 체크아웃하여 이 단계를 시작하지만 아직 로컬 저장소가 없으므로 대신 원격 저장소에서 복제합니다.

️ 작업: 로컬 저장소를 업데이트하고 다음에서 분기를 만듭니다. master, 일을 시작하다

1. 다음에서 코스 저장소를 복제합니다. <URL репозитория>.
2. 실행 npm install 코스 저장소 디렉토리에 있습니다. 테스트를 실행하는 데 사용하는 Jest를 설치하려면 이것이 필요합니다.
3. 브랜치를 만들고 이름을 지정하세요. feature. 이 스레드로 전환하세요.

4. 테스트 코드 추가 ci.test.js 나한테 이렇게 해달라고 요청하는 댓글들 사이에요.

   it('1. pull latest code', () => {
     expect(/.*pull.*/ig.test(fileContents)).toBe(true);
   });
   
   it('2. add commits', () => {
     expect(/.*commit.*/ig.test(fileContents)).toBe(true);
   });
   
   it('3. push to the remote branch with the same name', () => {
     expect(/.*push.*/ig.test(fileContents)).toBe(true);
   });
   
   it('4. create a pull request and continue working', () => {
     expect(/.*pulls+request.*/ig.test(fileContents)).toBe(true);
   });

5. 파일에 처음 4단계로 텍스트 추가 ci.md.

   1. Pull in the latest code. Create a branch from `master`. Start working.    
   2. Create commits on your new branch. Build and test locally.  
   Pass? Go to the next step. Fail? Fix errors or tests and try again.  
   3. Push to your remote repository or remote branch.  
   4. Create a pull request. Discuss the changes, add more commits  
   as discussion continues. Make tests pass on the feature branch.  

   팀

# Клонируйте репозиторий курса
git clone <repository URL>
cd <repository name>

# Выполните npm install в каталоге репозитория курса; он установит Jest, который мы используем для запуска тестов.
npm install

# Создайте ветку и назовите ее feature. Переключитесь на эту в ветку.
git checkout -b feature

# Отредактируйте ci.test.js как описано выше.
# Отредактируйте ci.md как описано выше

새 브랜치에 커밋을 생성하고, 로컬에서 빌드 및 테스트하세요.

커밋하기 전에 실행할 테스트를 설정한 다음 코드를 커밋하겠습니다.

테스트가 자동으로 실행되는 일반적인 시나리오

• 장소 상에서:
  • 지속적으로 또는 적절한 코드 변경에 대응하여
  • 저장 시(통역 또는 JIT 컴파일 언어의 경우)
  • 조립 중(컴파일이 필요한 경우)
  • 커밋 시;
  • 공유 저장소에 게시하는 경우.

• 빌드 서버 또는 빌드 환경에서:
  • 코드가 개인 브랜치/저장소에 게시되는 경우.
  • 이 스레드의 코드는 테스트 중입니다.
  • 합병의 잠재적 결과는 테스트됩니다(일반적으로 master).
  • 지속적인 통합 단계/지속적인 배포 파이프라인

일반적으로 테스트 도구 모음이 더 빠르게 실행될수록 더 자주 실행할 수 있습니다. 일반적인 스테이지 분포는 다음과 같습니다.

• 빠른 단위 테스트 - 빌드 중 CI 파이프라인에서
• CI 파이프라인에서 느린 단위 테스트, 빠른 구성 요소 및 통합 테스트 - 커밋 시
• 느린 구성 요소 및 통합 테스트 - CI 파이프라인에서
• 보안 테스트, 로드 테스트 및 기타 시간이 많이 걸리거나 비용이 많이 드는 테스트 - CI/CD 파이프라인에서 수행되지만 릴리스 후보를 준비하거나 수동으로 실행할 때와 같이 빌드의 특정 모드/단계/파이프라인에서만 가능합니다.

️과제

먼저 다음 명령을 사용하여 수동으로 테스트를 실행하는 것이 좋습니다. npm test. 그런 다음 커밋 시 테스트를 실행하기 위해 git 후크를 추가해 보겠습니다. 한 가지 문제가 있습니다. Git 후크는 저장소의 일부로 간주되지 않으므로 나머지 교육 자료와 함께 GitHub에서 복제할 수 없습니다. 후크를 설치하려면 다음을 실행해야 합니다. install_hook.sh 아니면 파일을 복사해서 repo/hooks/pre-commit 로컬 디렉토리로 .git/hooks/.
커밋하면 테스트가 실행되는 것을 볼 수 있으며 특정 키워드가 목록에 있는지 확인합니다.

1. 명령을 실행하여 수동으로 테스트를 실행하십시오. npm test 코스 저장소 폴더에 있습니다. 테스트가 완료되었는지 확인합니다.
2. 다음을 실행하여 커밋 후크(사전 커밋 후크)를 설정합니다. install_hook.sh.
3. 변경 사항을 로컬 저장소에 커밋합니다.
4. 커밋하기 전에 테스트가 실행되는지 확인하세요.

다음 단계를 수행하면 저장소가 다음과 같이 보일 것입니다.

팀

# Установите pre-commit hook выполнив install_hook.sh.  

# Закоммитьте изменения в локальный репозиторий. Используйте "Add first CI steps" в качестве сообщения при коммите.
git add ci.md ci.test.js
git commit -m "Add first CI steps"

# Убедитесь, что тесты запускаются перед коммитом.  

원격 저장소 또는 원격 지점에 코드 게시

로컬에서 작업을 마친 후 개발자는 일반적으로 코드를 공개적으로 공개하여 결국 대중과 통합될 수 있도록 합니다. GitHub를 사용하면 일반적으로 저장소의 개인 복사본(개인 포크)이나 개인 지점에 작업을 게시하여 이를 수행할 수 있습니다.

• 포크를 사용하면 개발자는 원격 공유 저장소를 복제하여 포크라고도 하는 개인 원격 복사본을 생성합니다. 그런 다음 이 개인 저장소를 복제하여 로컬로 작업합니다. 작업이 완료되고 커밋이 이루어지면 그는 이를 자신의 포크에 푸시합니다. 포크에서 해당 커밋은 다른 사람들이 사용할 수 있고 공통 저장소에 통합될 수 있습니다. 이 접근 방식은 GitHub의 오픈 소스 프로젝트에서 일반적으로 사용됩니다. 내 고급 과정 [Git을 사용한 팀워크 및 CI]에서도 사용됩니다(http://devops.redpill.solutions/).
• 또 다른 접근 방식은 하나의 원격 저장소만 사용하고 분기만 계산하는 것입니다. master 공유 저장소가 "보호됨"입니다. 이 시나리오에서 개별 개발자는 다른 사람이 이 코드를 볼 수 있도록 원격 저장소의 분기에 자신의 코드를 게시합니다. 모든 것이 정상이면 다음과 병합합니다. master 공유 저장소.

이 특정 과정에서는 브랜치를 사용하는 워크플로를 사용합니다.

코드를 공개해 보겠습니다.

️과제

• 작업 지점과 동일한 이름을 가진 원격 지점에 변경 사항 게시

팀

git push --set-upstream origin feature

끌어오기 요청 만들기

제목이 포함된 풀 요청 만들기 단계 검토... 설치 feature "본점"과 같은 master "기본 지점"과 같습니다.

설치했는지 확인하세요. master 그의 저장소를 포크하다 "기본 분기"로서 저는 강의 자료 저장소 변경 요청에 응답하지 않습니다.

GitHub 용어에서 "기본 분기"는 작업의 기반이 되는 분기이고 "헤드 분기"는 제안된 변경 사항이 포함된 분기입니다.

변경 사항에 대해 토론하고, 토론이 계속되면서 새로운 커밋을 추가하세요.

풀 리퀘스트(홍보)

풀 리퀘스트(홍보) 코드를 논의하고 문서화할 뿐만 아니라 코드 검토를 수행하는 방법입니다. 풀 요청의 이름은 개별 변경 사항을 전체 코드에 통합하는 일반적인 방법을 따서 명명되었습니다. 일반적으로 사람은 프로젝트의 원격 공식 저장소를 복제하고 로컬에서 코드 작업을 수행합니다. 그 후 그는 자신의 개인 원격 저장소에 코드를 배치하고 공식 저장소 책임자에게 코드를 가져오도록 요청합니다(당겨) 해당 코드를 로컬 저장소에 저장하여 검토하고 통합할 수 있습니다(병합) 그의. 이 개념은 다른 이름으로도 알려져 있습니다. 병합 요청.

실제로 GitHub 또는 유사한 플랫폼의 풀 요청 기능을 사용할 필요는 없습니다. 개발팀은 대면 커뮤니케이션, 음성 통화, 이메일 등 다른 커뮤니케이션 방법을 사용할 수 있지만 여전히 포럼 스타일 풀 요청을 사용하는 데에는 여러 가지 이유가 있습니다. 그 중 일부는 다음과 같습니다.

• 특정 코드 변경과 관련된 체계적인 토론;
• 자동 테스터와 동료 모두의 진행 중인 작업에 대한 피드백을 볼 수 있는 장소입니다.
• 코드 리뷰의 공식화;
• 나중에 이 코드 또는 해당 코드 뒤에 숨은 이유와 고려 사항을 찾을 수 있습니다.

일반적으로 무언가를 논의하거나 피드백을 받아야 할 때 끌어오기 요청을 만듭니다. 예를 들어, 여러 가지 방법으로 구현할 수 있는 기능을 작업하는 경우 첫 번째 코드 줄을 작성하기 전에 풀 요청을 생성하여 아이디어를 공유하고 공동 작업자와 계획을 논의할 수 있습니다. 작업이 더 간단하다면, 무언가가 이미 완료되고, 커밋되고, 논의될 수 있을 때 풀 요청이 열립니다. 일부 시나리오에서는 자동화된 테스트를 실행하거나 코드 검토를 시작하기 위해 품질 관리 목적으로만 PR을 열 수 있습니다. 무엇을 결정하든 끌어오기 요청에서 승인을 원하는 사람들을 @멘션하는 것을 잊지 마세요.

일반적으로 PR을 만들 때 다음을 수행합니다.

• 변경하려는 내용과 위치를 표시하십시오.
• 변경 목적을 설명하는 설명을 작성합니다. 당신은 원할 수도 있습니다:
  • 코드에서 명확하지 않은 중요한 항목이나 관련 #bug 및 커밋 번호와 같이 컨텍스트를 이해하는 데 유용한 항목을 추가합니다.
  • 함께 작업을 시작하고 싶은 사람을 @멘션하거나 나중에 댓글에서 @멘션할 수 있습니다.
  • 동료에게 도움을 요청하거나 구체적인 사항을 확인하세요.

PR을 열면 이러한 경우에 실행되도록 구성된 테스트가 실행됩니다. 우리의 경우 이는 로컬에서 실행한 것과 동일한 테스트 세트이지만 실제 프로젝트에서는 추가 테스트 및 확인이 있을 수 있습니다.

테스트가 완료되는 동안 잠시 기다려 주십시오. GitHub 인터페이스의 PR 토론 하단에서 테스트 상태를 확인할 수 있습니다. 테스트가 완료되면 계속하세요.

️ CI 단계 목록의 무작위성에 대한 메모를 추가하세요.

이 과정에서 사용된 목록은 임의적이고 주관적이므로 이에 대해 참고 사항을 추가해야 합니다.

️ 작업: 이 댓글에 대한 풀 요청 생성

1. 지점으로 전환 master.
2. 라는 이름의 지점을 만듭니다. bugfix.
3. 파일 끝에 메모 텍스트 추가 ci.md.

   > **GitHub flow** is sometimes used as a nickname to refer to a flavor of trunk-based development  
   when code is deployed straight from feature branches. This list is just an interpretation  
   that I use in my [DevOps courses](http://redpill.solutions).  
   The official tutorial is [here](https://guides.github.com/introduction/flow/).

4. 변경 사항을 커밋합니다.
5. 스레드 게시 bugfix 원격 저장소로.
6. 라는 이름의 풀 요청을 생성합니다. 비고 추가 본부 지점이 있는 bugfix 그리고 기본 지점master.

설치했는지 확인하세요. master 그의 저장소를 포크하다 "기본 분기"로서 저는 강의 자료 저장소 변경 요청에 응답하지 않습니다.

저장소는 다음과 같아야 합니다.

팀

# Переключитесь на ветку master. Создайте ветку bugfix.
git checkout master

# Создайте ветку bugfix-remark.
git checkout -b bugfix

# Добавьте текст примечания внизу ci.md.

# Закоммитьте изменения
git add ci.md
git commit -m "Add a remark about the list being opinionated"

# Опубликуйте ветку bugfix в удалённый репозиторий.
git push --set-upstream origin bugfix

# Создайте pull request при помощи интерфейса GitHub как описано выше

풀 요청 승인 "비고 추가"

️과제

1. 풀 요청을 생성합니다.
2. "풀 요청 병합"을 클릭하세요.
3. "병합 확인"을 클릭하세요.
4. "브랜치 삭제"를 클릭하면 더 이상 필요하지 않습니다.

이는 병합 후 커밋을 보여주는 다이어그램입니다.

️ 계속 작업하고 테스트를 추가하세요

끌어오기 요청에 대한 공동 작업으로 인해 추가 작업이 발생하는 경우가 많습니다. 이는 일반적으로 코드 검토 또는 토론의 결과이지만, 우리 과정에서는 CI 단계 목록에 새 항목을 추가하여 이를 모델링할 것입니다.

지속적 통합에는 일반적으로 일부 테스트 적용 범위가 포함됩니다. 테스트 적용 범위 요구 사항은 다양하며 일반적으로 "기여 지침"과 같은 문서에서 찾을 수 있습니다. 간단하게 유지하고 체크리스트의 각 줄에 대한 테스트를 추가하겠습니다.

할당을 실행할 때 먼저 테스트를 커밋해 보세요. 올바르게 설치했다면 pre-commit 더 일찍 후크하면 새로 추가된 테스트가 실행되고 실패하며 아무 것도 커밋되지 않습니다. 이것이 우리의 테스트가 실제로 무언가를 테스트하고 있다는 것을 아는 방법입니다. 흥미롭게도 테스트 전에 코드로 시작했다면 테스트를 통과했다는 것은 코드가 예상대로 작동했거나 테스트가 실제로 아무것도 테스트하지 않았다는 것을 의미할 수 있습니다. 게다가, 우리가 처음에 테스트를 작성하지 않았다면 우리는 그 테스트에 대해 완전히 잊어버렸을 것입니다.

테스트 주도 개발(TDD)

TDD는 코드를 작성하기 전에 테스트를 작성할 것을 권장합니다. TDD를 사용하는 일반적인 작업 흐름은 다음과 같습니다.

1. 테스트를 추가합니다.
2. 모든 테스트를 실행하고 새 테스트가 실패하는지 확인합니다.
3. 코드를 작성하세요.
4. 테스트를 실행하고 모든 테스트가 통과하는지 확인하세요.
5. 코드를 리팩터링하세요.
6. 반복하다.

실패한 테스트의 결과는 일반적으로 빨간색으로 표시되고, 통과한 테스트의 결과는 일반적으로 녹색으로 표시되므로 이 주기를 빨간색-녹색-리팩터링이라고도 합니다.

️과제

먼저 테스트를 커밋하고 실패하도록 한 다음 CI 단계 목록 자체의 텍스트를 추가하고 커밋합니다. 테스트가 통과된 것을 볼 수 있습니다("녹색").
그런 다음 새 코드를 원격 저장소에 게시하고 끌어오기 요청 토론 하단에 있는 GitHub 인터페이스에서 테스트가 실행되는 것과 PR 상태 업데이트를 살펴보세요.

1. 지점으로 전환 feature.

2. 이 테스트를 다음에 추가하십시오. ci.test.js 마지막 통화 후 it (...);.

   it('5. Merge/rebase commits from master. Make tests pass on the merge result.', () => {
     expect(/.*merge.*commits.*testss+pass.*/ig.test(fileContents)).toBe(true);
   });
   
   it('6. Deploy from the feature branch to production.', () => {
     expect(/.*Deploy.*tos+production.*/ig.test(fileContents)).toBe(true);
   });
   
   it('7. If everything is good in production for some period of time, merge changes to master.', () => {
     expect(/.*merge.*tos+master.*/ig.test(fileContents)).toBe(true);
   });

3. 테스트를 커밋해 보세요. 만약에 pre-commit 후크가 설치되어 있으면 커밋 시도가 실패합니다.
4. 그런 다음 이 텍스트를 ci.md.

   5. Merge/rebase commits from master. Make tests pass on the merge result.  
   6. Deploy from the feature branch with a sneaky bug to production.
   7. If everything is good in production for some period of time, merge changes to master. 

5. 로컬에서 변경하고 커밋합니다.
6. 지점에 변경 사항 게시 feature.

이제 이런 것이 있어야합니다

팀

# Переключительна ветку feature
git checkout feature

# Добавить тесты в ci.test.js как описано выше

# Добавьте в индекс ci.test.js чтобы позже закоммитить
git add ci.test.js

# Попытайтесь закоммитить тесты. Если pre-commit hook установлены, коммит не произойдёт.
git commit

# Теперь добавьте текст в ci.md как описано выше

# Внесите изменения и закоммитьте их
git add ci.md
git commit -m "Add the remaining CI steps"

# Опубликуйте изменения в ветку feature
git push

병합 충돌

변경요청 바로가기 단계 검토.

우리가 잘못한 것이 없고 코드에 대한 테스트가 통과되었음에도 불구하고 여전히 브랜치를 병합할 수 없습니다. feature и master. 다른 스레드 때문이에요. bugfix 와 합병되었다 master 우리가 이 PR 작업을 하는 동안.
이로 인해 원격 지점이 master 우리가 브랜치를 기반으로 한 버전보다 최신 버전이 있습니다. feature. 이 때문에 HEAD를 되감을 수는 없습니다. master 스레드 끝까지 feature. 이 상황에서는 커밋을 병합하거나 적용해야 합니다. feature 리베이스 master. GitHub는 충돌이 없으면 실제로 자동 병합을 수행할 수 있습니다. 아쉽게도 우리 상황에서는 두 브랜치 모두 파일에 경쟁적인 변경 사항이 있습니다. ci.md. 이러한 상황을 병합 충돌이라고 하며 수동으로 해결해야 합니다.

병합 또는 리베이스

병합

• 추가 병합 커밋을 생성하고 작업 기록을 저장합니다.
  • 원래 타임스탬프 및 작성자와 함께 브랜치의 원래 커밋을 보존합니다.
  • 변경 요청 토론에서 커밋의 SHA와 이에 대한 링크를 저장합니다.
• 일회성 충돌 해결이 필요합니다.
• 이야기를 비선형적으로 만듭니다.
  • (IDE 케이블을 연상시키는) 분기 수가 많아 스토리를 읽기 어려울 수 있습니다.
  • 자동 디버깅을 더 어렵게 만듭니다. git bisect 덜 유용합니다. 병합 커밋만 찾습니다.

리베이스

• 기본 분기 위에 현재 분기의 커밋을 차례로 재생합니다.
  • 새로운 SHA가 포함된 새로운 커밋이 생성되어 GitHub의 커밋이 원래 끌어오기 요청과 일치하지만 해당 주석은 일치하지 않습니다.
  • 커밋은 프로세스에서 다시 결합 및 수정되거나 하나로 병합될 수도 있습니다.
• 여러 충돌을 해결해야 할 수도 있습니다.
• 선형적인 스토리를 유지할 수 있습니다.
  • 합리적인 이유 없이 너무 길지 않다면 이야기가 더 읽기 쉬울 수도 있습니다.
  • 자동 디버깅 및 문제 해결이 조금 더 쉬워집니다. git bisect, 자동 롤백을 더 명확하고 예측 가능하게 만들 수 있습니다.
• 플래그가 있는 마이그레이션된 커밋이 있는 브랜치를 게시해야 합니다. --force 풀 요청과 함께 사용될 때.

일반적으로 팀은 변경 사항을 병합해야 할 때 항상 동일한 전략을 사용하는 데 동의합니다. 이는 "순수한" 병합 또는 상단의 "순수한" 커밋일 수도 있고, 대화식으로 상단에서 커밋을 수행하는 것과 같이 그 사이의 것일 수도 있습니다(git rebase -i) 공용 저장소에 게시되지 않은 분기의 경우 로컬이지만 "공용" 분기의 경우 병합됩니다.

여기서는 병합을 사용하겠습니다.

️과제

1. 코드가 로컬 지점에 있는지 확인하세요. master 원격 저장소에서 업데이트되었습니다.
2. 지점으로 전환 feature.
3. 브랜치와 병합 시작 master. 경쟁 변경 사항으로 인해 병합 충돌이 발생했습니다. ci.md.
4. CI 단계 목록과 그에 대한 참고 사항이 모두 텍스트에 남아 있도록 충돌을 해결합니다.
5. 원격 브랜치에 병합 커밋 게시 feature.
6. GitHub UI에서 풀 요청 상태를 확인하고 병합이 해결될 때까지 기다립니다.

팀

# Убедитесь, что код в локальное ветке `master` обновлён из удалённого репозитория.
git checkout master
git pull

# Переключитесь на ветку feature
git checkout feature

# Инициируйте слияние с веткой master 
git merge master

# A merge conflict related to concurrent changes to ci.md will be reported
# => Auto-merging ci.md
#    CONFLICT (content): Merge conflict in ci.md
#    Automatic merge failed; fix conflicts and then commit the result.

# Разрешите конфликт так, чтобы и наш список шагов CI, и замечание о нем остались в тексте.
# отредактируйте ci.md чтоб он не содержал маркеров конфликта слияния
git add ci.md
git merge --continue
# при коммите можете оставить сообщение по умолчанию

# Опубликуйте коммит слияния в удаленную ветку feature.
git push

# Проверьте статус запроса на изменения в пользовательском интерфейсе GitHub, дождитесь пока слияние не будет разрешено.

잘 했어!

목록 작업이 완료되었으며 이제 끌어오기 요청을 승인해야 합니다. master.

️ 작업: 풀 요청 승인 "단계 검토"

1. 끌어오기 요청을 엽니다.
2. "풀 요청 병합"을 클릭하세요.
3. "병합 확인"을 클릭하세요.
4. 더 이상 필요하지 않으므로 "브랜치 삭제"를 클릭하세요.

현재 귀하의 저장소입니다.

제품 오류

"테스트를 통해 오류가 있음을 보여줄 수는 있지만 오류가 없음을 보여줄 수는 없습니다." 테스트를 했고 오류가 없는 것으로 나타났음에도 불구하고 교활한 버그가 프로덕션에 침투했습니다.

이와 같은 시나리오에서는 다음을 처리해야 합니다.

• 프로덕션에 배포되는 항목
• 스레드의 코드 master 오류가 발생하면 개발자가 새 작업을 시작할 수 있습니다.

다음 버전에서 롤백해야 할까요, 아니면 수정해야 할까요?

롤백은 알려진 양호한 이전 버전을 프로덕션에 배포하고 오류가 포함된 커밋을 되돌리는 프로세스입니다. "앞으로 수정"은 다음에 수정 사항을 추가하는 것입니다. master 가능한 한 빨리 새 버전을 배포하세요. API와 데이터베이스 스키마는 코드가 프로덕션에 배포됨에 따라 변경되고 지속적인 전달과 우수한 테스트 적용 범위를 갖기 때문에 일반적으로 롤백은 다음 버전에서 수정하는 것보다 훨씬 더 어렵고 위험합니다.

우리의 경우 롤백은 위험을 수반하지 않으므로 이 경로를 따르겠습니다.

• 가능한 한 빨리 제품의 오류를 수정하십시오.
• 코드를 작성하다 master 새로운 일을 시작하는 데 즉시 적합합니다.

️과제

1. 지점으로 전환 master 장소 상에서
2. 원격 저장소에서 로컬 저장소를 업데이트합니다.
3. PR 병합 커밋 되돌리기 단계 검토 в master.
4. 원격 저장소에 변경 사항을 게시합니다.

병합 커밋을 되돌린 저장소의 기록입니다.

팀

# Переключитесь на ветку master.
git checkout master

# Обновите локальный репозиторий из удалённого репозитория.
git pull

# Отмените коммит слияния PR Steps review в master.
# Мы отменяем коммит слияния, поэтому нам нужно выбрать ветку истории, которую мы захотим оставить
git show HEAD

# предположим, что коммит, который был последним в ветке master до слияния, был отображён предыдущей командой первым
git revert HEAD -m 1
# можете не менять сообщения коммитов

# Опубликуйте изменения в удалённый репозиторий
git push

️ 자가 테스트

확인 ci.md 병합 커밋을 되돌린 후 더 이상 "sneaky bug"라는 텍스트가 포함되지 않습니다.

CI 단계 목록을 수정하여 마스터로 반환

우리는 브랜치의 병합 커밋을 완전히 되돌렸습니다. feature. 좋은 소식은 이제 오류가 없다는 것입니다. master. 나쁜 소식은 우리의 소중한 지속적 통합 단계 목록도 사라졌다는 것입니다. 따라서 이상적으로는 다음의 커밋에 수정 사항을 적용해야 합니다. feature 그리고 그들을 돌려 보내십시오 master 수정과 함께.

우리는 다양한 방식으로 문제에 접근할 수 있습니다:

• 병합을 취소하는 커밋을 되돌리기 feature с master;
• 이전에서 커밋을 이동합니다. feature.

이 경우 개발 팀마다 다른 접근 방식을 사용하지만 유용한 커밋을 별도의 브랜치로 이동하고 이 새 브랜치에 대한 별도의 풀 요청을 생성합니다.

️과제

1. 라는 스레드를 만듭니다. feature-fix 그것으로 전환하십시오.

2. 이전 분기에서 모든 커밋 마이그레이션 feature 새로운 스레드로. 마이그레이션 중에 발생한 병합 충돌을 해결합니다.

   

3. 회귀 테스트를 추가합니다. ci.test.js:

   it('does not contain the sneaky bug', () => {
   expect( /.*sneakys+bug.*/gi.test(fileContents)).toBe(false);
   });

4. 로컬에서 테스트를 실행하여 실패하지 않는지 확인하세요.
5. "비밀한 버그 포함"이라는 텍스트를 제거하세요. ci.md.
6. 테스트 변경 사항과 단계 목록 변경 사항을 인덱스에 추가하고 커밋합니다.
7. 원격 저장소에 분기를 게시합니다.

다음과 비슷한 결과가 나올 것입니다.

팀

# Создайте ветку под названием feature-fix и переключитесь на нее.
git checkout -b feature-fix

# Перенесите все коммиты из бывшей ветки feature в новую ветку. Разрешите конфликты слияния, которые возникли при переносе.
# используйте историю чтобы узнать хэши коммитов:
# - предшествующего коммиту с первой частью списка: C0
# - добавляющего последние элементы списка: C2
git log --oneline --graph
git cherry-pick C0..C2
# разрешите конфликты слияния
# - отредактируйте ci.md и/или ci.test.js
# - добавьте файлы в индекс
# - выполните "git cherry-pick --continue", можете не менять сообщение коммита

# Добавьте регрессионный тест в ci.test.js
# Запустите тесты локально, чтобы убедиться, что они не завершаются успешно.

# Удалите текст " with a sneaky bug" в ci.md.

# Добавьте в индекс изменения тестов и в списке шагов и закоммитьте их.
git add ci.md ci.test.js
git commit -m "Fix the bug in steps list"

# Опубликуйте ветку в удалённый репозиторий.
git push --set-upstream origin feature-fix

풀 요청을 생성합니다.

제목이 포함된 풀 요청 만들기 기능 수정... 설치 feature-fix "본점"과 같은 master "기본 지점"과 같습니다.
테스트가 완료될 때까지 기다려 주십시오. PR 토론 하단에서 테스트 상태를 확인할 수 있습니다.

설치했는지 확인하세요. master 그의 저장소를 포크하다 "기본 분기"로서 저는 강의 자료 저장소 변경 요청에 응답하지 않습니다.

풀 요청 승인 "기능 수정 중"

수정해주셔서 감사합니다! 변경사항을 승인해 주세요. master 풀 요청에서.

️과제

1. "풀 요청 병합"을 클릭하세요.
2. "병합 확인"을 클릭하세요.
3. 더 이상 필요하지 않으므로 "브랜치 삭제"를 클릭하세요.

이것이 바로 지금 당신이 가져야 할 것입니다.

축하해!

지속적 통합 중에 사람들이 일반적으로 수행하는 모든 단계를 완료했습니다.

강좌에 문제가 있거나 개선 방법을 알고 있다면 다음에서 문제를 만들어 주세요. 강좌 자료가 있는 저장소. 이 코스에는 또한 대화형 버전 GitHub Learning Lab을 플랫폼으로 사용합니다.

출처 : habr.com