测验：基于主干的开发与分支保护

장수 브랜치에서 가장 다루기 어려운 통합 문제는?

• 같은 줄을 동시에 고쳐 생기는 텍스트 충돌이 누적되는 것
• 깨끗하게 병합되지만 동작이 달라지는 의미 충돌이 생기는 것
• 브랜치가 많아져 저장소 크기와 참조 수가 늘어나는 것
• 리뷰 대기가 길어져 코드 리뷰 품질이 떨어지는 것

로컬 git 훅을 규칙 강제 수단으로 삼을 수 없는 이유는?

• 훅은 복제로 따라오지 않아 각자의 사본에 저절로 생기지 않는다
• 훅은 실행 권한이 없으면 오류 없이 무시되어 신뢰할 수 없다
• 훅은 종료 코드를 무시하므로 작업을 막을 수단이 없다
• 훅은 기본 브랜치에서만 실행되도록 제한되어 있다

pre-receive 훅이 0이 아닌 값으로 끝나면 어떻게 되는가?

• 문제가 된 레퍼런스만 거부되고 나머지는 정상 갱신된다
• 갱신은 그대로 진행되고 경고만 푸시한 쪽에 표시된다
• 어떤 레퍼런스도 갱신되지 않고 푸시 전체가 거부된다
• 훅이 다시 실행되며 정해진 횟수만큼 재시도한다

GitHub 브랜치 보호 규칙에서 자주 놓치는 기본값은?

• 필수 상태 검사는 기본적으로 모든 워크플로를 자동 등록한다
• 선형 이력 요구를 켜면 풀 리퀘스트 병합이 함께 금지된다
• 보호 규칙은 새로 만든 브랜치에는 하루 뒤부터 적용된다
• 보호 규칙이 기본적으로 관리자에게는 적용되지 않는다

병합 대기열이 푸는 문제는?

• 리뷰어가 배정되지 않아 풀 리퀘스트가 오래 열려 있는 문제
• 검사 수가 많아 러너가 동시에 확보되지 않는 문제
• 브랜치의 검사 결과가 병합된 뒤의 트렁크를 보증하지 못하는 문제
• 병합 커밋이 쌓여 이력이 읽기 어려워지는 문제

기능 플래그로 장수 브랜치를 대신할 때 함께 정해야 하는 것은?

• 플래그를 지우는 시점을 만들 때 같이 정해 두는 것
• 플래그 값을 이미지 빌드 시점에 박아 넣는 방식
• 플래그마다 별도의 릴리스 브랜치를 함께 만드는 규칙
• 플래그가 켜진 동안에는 배포를 멈추는 정책