고급 Git 워크플로 및 사용
게시 됨: 2022-06-30최근에 우리는 프로젝트에서 소스 제어를 위해 Git을 사용하여 시작하는 기본 사항을 살펴보았습니다. 이것이 훌륭한 출발점이기는 하지만 일상적인 코딩 작업에서 Git을 사용하는 데 도움이 되는 다른 명령과 Git 워크플로가 많이 있습니다.
Git 워크플로
Git을 사용하기 시작했을 때 Git을 올바르게 사용하는 방법을 알고 있다고 생각했습니다. 내 이상적인 접근 방식은 분기 없이 한 곳에서 모든 변경을 수행한 다음 저장소에 커밋하고 계속 작업하는 것이었습니다.
버전 관리를 사용하지 않는 것보다는 낫지만 Git이 제공하는 대부분의 기능을 사용하지 않는다는 것을 깨닫는 데 시간이 걸렸습니다. Git을 사용하려면 변경 사항을 분기하고 병합하는 전략이 필요했습니다.
그런 다음 git-flow가 나왔고 이를 전략으로 채택했습니다. 커튼 뒤에서 놀라운 개발자들이 있는 곳을 엿보고 있었던 것 같은 느낌이 아직도 기억납니다. 나는 이제 그들이 어떻게 일하고 그들 중 하나가 될 수 있는지에 대한 통찰력을 얻었습니다.
그러나 git-flow는 모든 시나리오에 적합하지 않으므로 살펴보는 동안 외로운 개발자로서 내 프로젝트를 관리하는 방법을 포함하여 Git 프로젝트를 구성하는 몇 가지 다른 방법도 살펴보겠습니다.
자식 흐름
지금 git-flow를 보면 소프트웨어 환경이 10년 동안 크게 바뀌었고 git-flow가 팀에 가장 적합한 옵션이 아닐 수도 있음을 인정합니다. git-flow가 작성되었을 때 애플리케이션을 하루에 여러 번 배포하는 경우는 거의 없었습니다. 그 대신, 특히 민첩한 팀에 속했다면 몇 달 또는 몇 주에 한 번씩 메이저 버전 번호와 릴리스를 수행했을 것입니다.
git-flow가 무엇인지 살펴보겠습니다.
Git Flow에 대한 차트 및 Git 명령에 대한 자세한 설명을 보려면 이 게시물을 읽어야 합니다.
git-flow에서 두 가지의 수명은 무한합니다. 첫째, 라이브/프로덕션 환경에 배포할 준비가 된 코드를 반영해야 하는 메인입니다.
둘째, 개발 분기가 있습니다. 이 분기에는 소프트웨어의 다음 릴리스를 위해 준비된 최신 변경 사항이 있어야 합니다. 개발 변경 사항이 라이브 애플리케이션에 배포될 준비가 되면 기본 분기에 병합하고 릴리스 번호에 해당하는 버전 번호로 태그를 지정합니다.
두 가지 주요 가지 외에 세 가지 유형의 지원 가지가 있습니다.
1. 기능
기능 분기는 개발 분기에서만 만들 수 있습니다. 개발 브랜치로 다시 병합되어야 합니다. 이름은 작업 중인 기능을 설명하는 모든 것이 될 수 있습니다.
작업이 다음 릴리스를 위해 준비되면 릴리스 시간을 기다리는 개발 분기로 다시 병합됩니다.
2. 릴리스
릴리스 분기는 개발 분기에서 만들어지며 개발 및 기본 둘 다에 다시 병합되어야 합니다. 릴리스 x 규칙을 사용하여 릴리스 분기의 이름을 지정합니다. 실제로 이것은 일반적으로 다음과 같이 사용하려는 릴리스 번호로 분기 이름을 지정한다는 것을 의미합니다.
릴리스 분기를 사용하여 소프트웨어를 릴리스하기 위한 최종 준비를 수행합니다. 여기에는 파일의 버전 번호 범핑, 번역이 완료되었는지 확인 또는 최종 코드 검사가 포함될 수 있습니다.
3. 핫픽스
핫픽스 분기는 메인 분기에서 만들어지며 라이브 애플리케이션에서 즉시 처리해야 하는 변경 사항을 포함하는 데 사용됩니다. 이것은 수정해야 하는 버그이거나 처리해야 하는 보안 문제일 수 있습니다.
문제가 수정되고 메인 브랜치에 배포되면 적절한 버전 번호로 코드에 태그를 지정합니다.
팀이 지금 git-flow를 사용하지 않는 가장 큰 이유는 소프트웨어 릴리스 방식이 변경되었기 때문입니다. 더 큰 릴리스를 덜 자주 릴리스하는 대신 하루에 몇 번 응용 프로그램에 대한 변경 사항을 릴리스할 수 있습니다. 작업이 준비되는 대로 일주일에 여러 번 클라이언트의 사이트로 작업을 푸시한다는 것을 알고 있습니다. 우리는 사이트의 버전 번호를 지정하지 않고 계속 개선하고 있습니다.
표준 git-flow는 이것을 수용하기 위한 것이 아닙니다.
Github 흐름
많은 사람들이 사용하는 두 번째 옵션은 Github Flow입니다.
Github Flow의 큰 규칙 중 하나는 메인 브랜치에 있는 코드가 무엇이든 프로덕션 준비가 되었기 때문에 언제든지 배포할 수 있다는 것입니다.
모든 분기는 수행 중인 작업에 대한 설명이 포함된 이름으로 기본 분기에서 생성됩니다.
변경 사항이 준비되면 pull 요청을 만듭니다.
pull 요청은 동일한 코드에서 작업하는 다른 사람들에게 변경 사항이 기본 코드에 병합되기 전에 수행 중인 작업을 검토할 준비가 되었음을 알려줍니다.
풀 리퀘스트를 제출하면 함께 작업하는 팀에서 변경 사항을 검토하고 피드백을 제공할 수 있습니다. pull 요청이 병합할 준비가 된 것으로 간주되면 프로젝트의 기본 분기에 병합됩니다.
단일 개발자 또는 매우 작은 팀을 위한 Github 흐름의 한 가지 단점은 pull 요청을 관리하면 프로젝트 관리에 추가 오버헤드가 발생할 수 있다는 것입니다. 이것이 내가 작업에서 그것들을 사용하지 않는 이유입니다.
클라이언트 프로젝트에서 Git 워크플로를 사용하는 방법
내 클라이언트 작업에서 나는 일반적으로 프로젝트에 대해 매일 코드를 작성하는 유일한 사람입니다. 내 클라이언트는 WordPress 플러그인을 업데이트하거나 일부 CSS를 변경할 수 있지만 주요 코딩 작업은 수행하지 않습니다. 즉, Github 흐름을 사용하는 경우 추가 관리 골칫거리만 생성하는 끌어오기 요청을 검토하게 됩니다. 내가 사용하는 시스템을 살펴보겠습니다. 이 시스템은 git-flow 및 Github 흐름과 어느 정도 유사합니다.
메인과 스테이징이라는 두 가지 주요 분기가 있습니다. 메인 브랜치는 현재 프로덕션 사이트에서 실행 중인 코드를 추적합니다. 스테이징 분기는 변경 사항을 라이브 사이트로 푸시하기 전에 변경 사항을 테스트하는 데 사용하는 스테이징 사이트에서 테스트 중인 모든 항목을 추적합니다.
모든 분기는 기본 분기에서 생성됩니다. 새 기능에는 다음과 같은 이름이 지정됩니다. feature/32-new-feature. 이 맥락에서 숫자 32는 프로젝트 관리 시스템의 티켓 번호에 해당하고 그 뒤에 오는 단어는 현재 진행 중인 작업에 대한 간략한 설명입니다. 버그 수정 이름은 bug/20-bug-name과 유사하게 지정됩니다.
생성된 모든 분기는 먼저 스테이징 분기에 병합된 다음 클라이언트가 승인하거나 직접 테스트하면 마스터 분기에 병합됩니다. 해당 워크플로는 다음과 같을 수 있습니다.
# 스테이징 브랜치에 기능 병합
자식 병합 기능/32-새로운 기능
# 기능 배포 및 테스트
자식 체크 아웃 메인
자식 병합 기능/32-새로운 기능
# 라이브 사이트에 기능 배포
내 프로젝트에는 지속적인 배포가 설정되어 있습니다. 즉, 코드를 메인에 푸시할 때마다 라이브 사이트에 자동으로 푸시됩니다. 스테이징 분기에 대해 동일한 프로세스가 설정됩니다.
내가 풀 리퀘스트 워크플로에서 내 코드를 확인할 수 있는 팀과 함께 일하고 있다면 팀에서 잘 작동하기 때문에 이 시스템을 사용할 것입니다. 대부분 스스로 작업하는 개발자의 경우 워크플로 속도를 늦추는 것은 단순히 관리 오버헤드입니다.
내가 사용하는 고급 Git 명령
이제 실용적인 워크플로에서 Git을 사용하는 방법에 대한 아이디어를 얻었으므로 이를 수행하는 데 필요한 고급 명령을 살펴보겠습니다. 나는 고객의 코드로 작업할 때 이러한 각 명령을 일주일에 몇 번 이상 사용합니다.
GUI 응용 프로그램을 사용하더라도(Git에 대한 지난 게시물에서 몇 가지 좋은 것을 언급했습니다) 백그라운드에서 무슨 일이 일어나고 있는지 이해하는 것이 여전히 중요합니다. 여러 번 Git GUI 응용 프로그램에서 생성된 문제를 해결하기 위해 터미널을 통해 작업해야 했습니다.
라인별 변경사항 추가
터미널 클릭을 통해 Git을 사용하게 만든 명령은 git add -p였습니다. 이 명령을 배우기 전까지는 GUI 응용 프로그램을 사용했는데 코드를 변경했지만 특정 행을 다른 커밋으로 분리하여 변경한 이유를 설명할 수 있기를 원했기 때문입니다. 이를 위해 GUI를 사용하여 행을 선택했지만 git add -p는 청크에 변경 사항을 추가하는 대화형 인터페이스를 안내합니다.
나는 이것을 매일 여러 번 사용합니다.
원격 Git 분기 추적
기존 리포지토리를 풀다운하고 추적해야 하지만 이미 존재하는 기본 및 스테이징과 같은 분기가 있는 경우 해당 분기의 원격 버전을 추적하도록 분기의 로컬 버전에 지시해야 합니다.
몇 가지 방법이 있습니다.
# 원격으로 푸시할 때 업스트림 설정
git push -u 오리진 스테이징
# 업스트림 설정
# 현재 원격으로 추적하려는 지점에 있다고 가정합니다.
git 브랜치 -u 오리진/스테이징
자식 분기 --set-upstream-to=origin/staging
# 추적하려는 분기에 있지 않은 경우 끝에 분기를 지정합니다.
git 분기 --set-upstream-to=origin/staging 스테이징
커밋하지 않고 변경 사항 저장
때때로 당신은 아직 커밋할 준비가 되지 않은 어떤 작업의 한가운데에 있을 것입니다. 그러나 당신은 그 상태를 저장해야 합니다. git stash가 유용한 곳입니다. 이 명령은 변경 사항을 제거하여 변경 사항을 숨깁니다. git stash pop을 사용하여 다시 가져올 수 있습니다. stash를 유용하게 만드는 몇 가지 명령이 더 있지만 이 두 가지가 제가 정기적으로 사용하는 두 가지입니다.
특정 Git 커밋 가져오기
때로는 특정 커밋을 현재 작업으로 가져와야 합니다. 깨끗한 HEAD(아직 변경하지 않음)를 사용하면 git cherry-pick 으로 특정 커밋을 가져올 수 있습니다. 여기에서 git cherry-pick에 대한 전체 문서를 찾을 수 있습니다.
각 커밋에 대해 Git은 Git 개체라고 하고 일반적으로 SHA라고 하는 긴 문자와 숫자 시퀀스를 빌드합니다. 각 커밋이 하나씩 가져오기 때문에 SHA 값으로 커밋을 참조할 수 있습니다. Git 개체에 대해 자세히 알아보세요.
필요하지 않은 변경 사항은 버리세요
프로젝트의 어느 시점에서 우리는 변경을 하고 작동하지 않는다는 것을 깨닫고 단순히 스크랩하고 다시 시작해야 합니다. 원하는 위치로 돌아올 때까지 실행 취소를 시도하는 대신 다음 Git 명령을 사용하여 아직 추적되지 않은 변경 사항을 제거할 수 있습니다.
자식 재설정 --하드
위의 명령은 현재 작업 중인 분기의 가장 최근 커밋으로 코드를 재설정합니다. 최신 커밋 이전 상태로 돌아가고 싶다면 이 명령과 함께 <#commitSHA>를 사용하여 특정 커밋으로 재설정할 수도 있습니다. 전체 분기 작업 가치가 유지하고 싶은 것이 아니지만 일부 작업은 이미 추적했기 때문에 이것을 사용하여 초기 분기 체크아웃으로 재설정할 수 있습니다.
한 단계 더 나아가 git clean 명령을 사용하여 아직 git에서 추적되지 않은 파일이나 디렉토리를 버릴 수 있습니다.
git clean -fd: f 및 d 플래그는 추적되지 않는 파일과 디렉토리를 버리도록 git에 지시합니다.
가지 제거
매주 한두 주에 git status 명령의 결과를 보고 저장소에서 무슨 일이 일어나고 있는지 합리적으로 이해하기에는 너무 많은 분기가 있음을 발견했습니다. 즉, 다음 명령으로 해결된 티켓에 해당하는 모든 분기를 제거할 수 있습니다.
# 로컬 버전을 제거합니다.
자식 분기 -d $ 분기 이름
#리모컨에서 분기를 제거합니다.
git push $remotename --delete $branchname
버전 관리 사용
사용할 모든 Git 명령에 대한 전문가는 아닐 수도 있지만 기억해야 할 중요한 사항은 버전 제어를 사용해야 한다는 것 입니다. 프로젝트에서 작업하는 유일한 사람이더라도 Git과 Git 워크플로를 사용하면 프로젝트를 정리하는 데 도움이 됩니다. 작동하지 않는 코드를 작성한 후 작업을 재설정할 때까지 CTRL + Z를 누를 필요가 없습니다.
시스템을 신뢰하고 프로젝트를 위한 작업을 계속 생성할 수 있습니다.
완전 관리형 WordPress 호스팅 사용해 보기
WordPress에 최적화된 호스팅이 필요하십니까? 지금 Nexcess의 완전 관리형 WordPress 호스팅 계획을 확인하십시오.