코드 흐름 전략 선택
팀의 작업 방식에 맞는 코드 흐름 전략을 선택해야 합니다. 고려해야 할 몇 가지 전략이 있습니다. 모듈의 끝 부분에서 옵션을 탐색할 수 있습니다. Tailspin 웹 팀은 Git과 GitHub를 기반으로 하는 코드 흐름 전략을 개발하기로 결정합니다.
Mara가 Azure Boards를 설정했을 때 팀과 Mara는 처리해야 할 몇 가지 초기 작업을 파악했습니다. 그중 하나는 Git 기반 워크플로를 만드는 작업입니다.
더 나은 협업 방법을 과정에서 이 팀의 이야기에 귀를 기울여 보겠습니다. 현재는 중앙 집중식 버전 제어 시스템을 사용하고 있지만 분산 시스템인 Git으로 이동할 계획입니다.
Andy가 들어올 때 Mara는 할당된 기능과 관련된 작업을 하고 있었습니다.
Andy: 안녕하세요, Mara. 오늘 아침 리더십 미팅에서 우리 팀과 게임 개발 팀이 서로 다른 버전 제어 시스템을 사용하고 있다는 문제가 제기되었습니다. 팀 간에 리소스를 공유하는 방법을 간소화하기 위해 협업을 더 잘 처리할 수 있는 분산된 버전 제어 시스템으로 이동하라는 요청을 받았습니다.
Mara: 다행이네요. 기억하실지 모르겠는데, 이전에 보드에 이 문제를 이미 올렸어요. 현재는 중앙 집중식 버전 제어 시스템을 사용하고 있습니다. 지금은 아무런 문제가 없지만 팀 간에 공유가 시작되고 팀이 점점 더 커지면 분산 버전 제어 시스템이 더 낫다는 데 동의합니다. 또한 이 작업은 보드에 올려서 모든 이해 관계자가 모든 사람이 하고 있는 일을 더 잘 파악할 수 있도록 해야 합니다. Git과 같은 분산 소스 제어 시스템도 도움이 될 것이라고 생각합니다.
Andy: 한동안 Git을 사용해 보고 싶었는데 시간이 없는 것 같습니다. Git에 대해 배우고 설정하는 것이 어렵나요? 괜찮다면 당장 해볼 수 있을까요. 뒤로 미루는데 이제 넌덜머리가 나네요. 모두가 수행 중인 작업을 파악하고 전체 리포지토리에 액세스할 수 있으면 좋을 것 같아요. 자, Git이 뭐죠?
Mara: 제가 Git에 관해 설명해 드리면 그다음에 지금 우리가 구현하고자 하는 것과 같은지 직접 결정할 수 있을 거예요.
Mara와 Andy는 버전 제어에 관해 이야기를 나누기 위해 화이트보드 쪽으로 이동합니다.
Git과 분산 버전 제어란?
Mara: 왼쪽 그림은 현재 사용 중인 것과 같은 중앙 집중식 버전 제어입니다. 모두가 사용하는 TFVC(Team Foundation 버전 제어)에 코드베이스 
의 중앙 버전이 있습니다. 각자 변경이 필요한 파일에서 작업한 다음 작업을 마치면 마스터 리포지토리로 다시 병합합니다.
Andy: 맞습니다. 그것이 우리가 지금 작업하는 방식입니다. 그런데 차단된 경우를 제외하고는 호환성이 손상되는 변경이 중앙 리포지토리로 병합되었습니다.
Mara: 맞아요! 사용자는 차단되었습니다(
). 차단 문제를 해결하기 위해 TFVC와 함께 분기 전략을 사용할 수 있지만 현재 구성에서는 병합이 좀 더 복잡해질 수 있습니다. 호환성이 손상되는 변경 
이 있으면 해결될 때까지 아무런 작업도 수행할 수 없습니다. 모두 동일한 코드 복사본을 사용하고 있기 때문에 언제든지 이와 같은 문제가 발생할 수 있습니다.
오른쪽은 분산 버전 제어를 보여 주는 그림입니다. 여전히 안정적인 코드베이스 버전인 중앙 리포지토리 
를 갖고 있지만 각 개발자는 작업할 자신의 복사본 
을 가지고 있습니다. 이렇게 하면 중앙 리포지토리에 영향을 주지 않으면서 다양한 방법을 실험하고 시도할 수 있습니다.
분산 버전 제어에서는 작업 중인 코드 
만 중앙 리포지토리에 병합된다는 장점도 있습니다. 코드를 검토할 때까지 코드를 병합할 수 없도록 설정할 수도 있습니다.
Azure DevOps가 좋은 점은 중앙 집중식 버전 제어 시스템과 분산 버전 제어 시스템 둘 모두에서 잘 작동한다는 사실입니다.
Andy: 두 명 이상의 사용자가 같은 파일을 변하면 어떻게 되나요?
Mara: 일반적으로 Git에서는 여러 변경 내용을 자동으로 병합할 수 있습니다. 변경 조합이 제대로 작동하는 코드가 되는지 항상 확인하고 싶은 것은 당연합니다. Git에서 변경 내용을 자동으로 병합할 수 없는 경우에는 사용자가 허용할 변경 내용을 선택할 수 있도록 파일에 직접 충돌을 표시합니다.
Andy: 이제 코드가 자체 서버에 저장되었습니다. 분산 버전 제어를 사용하여 이동하는 경우 코드는 어디에 저장되나요?
Mara: 좋은 질문이네요. 바로 이 지점에서 호스팅이 등장합니다.
내 리포지토리는 어디에서 호스트할 수 있나요?
Mara: 리포지토리를 호스트할 위치를 결정할 때 몇 가지 옵션을 사용할 수 있습니다. 예를 들어 로컬 서버, Bitbucket 또는 GitHub에서 리포지토리를 호스트할 수 있죠. Bitbucket과 GitHub는 웹 기반 호스팅 솔루션입니다. 어디에서나 액세스할 수 있습니다.
Andy: 우리는 둘 중 하나를 사용했나요?
Mara: 이전에는 GitHub를 사용했습니다. 여기에는 명령줄 또는 온라인 포털에서 변경 로그 및 버전 제어 기능에 쉽게 액세스할 수 있는 등 개발자에게 중한 기능이 포함되어 있습니다.
Andy: 그렇다면 Git은 어떻게 작동하나요?
Git은 어떻게 사용하나요?
Mara: 앞서 말씀드린 것처럼 분산 시스템에서 개발자는 리포지토리의 자체 복사본을 보유하고 있으므로 다른 개발자의 작업에 영향을 주지 않고 필요한 모든 파일에 자유롭게 액세스할 수 있습니다. 리포지토리의 로컬 복사본을 복제본이라고 하죠.
기능 또는 버그 수정 작업을 수행하는 경우 일반적으로 최상의 솔루션을 찾을 때까지 다른 방법을 사용해 볼 수 있습니다. 하지만 기본 코드 베이스의 복사본에 코드를 시험해 보는 것은 좋은 방법이 아닙니다. 왜냐하면 처음 몇 번의 시도는 유지하고 싶지 않을 수 있기 때문입니다.
더 나은 옵션을 제공하기 위해 Git은 분기라는 기능을 제공하는데, 원하는 만큼 복사본을 유지 관리하고 유지할 복사본만 다시 병합할 수 있는 기능입니다. 이렇게 하면 기본 분기가 안정적으로 유지됩니다.
Andy: 지금까지 개념을 알아보았어요. 코드는 어디서 확인할 수 있나요?
로컬 변경 내용이 기본 코드베이스에 어떻게 적용되나요?
Mara: Git에서는 기본 분기(트렁크)를 일반적으로 main이라고 합니다.
모든 개발자가 공유하는 중앙 리포지토리의 main 분기로 코드를 병합할 준비가 되었다고 느끼면 끌어오기 요청을 만듭니다. 끌어오기 요청을 만드는 것은 다른 개발자에게 코드가 검토 준비를 마쳤고 코드를 main 분기로 병합하고 싶다고 알리는 것입니다. 끌어오기 요청이 승인된 다음 병합되면 중앙 코드 베이스의 일부가 됩니다.
분기 워크플로는 무엇과 같나요?
1단계: 새 기능 또는 버그 수정 작업을 시작할 때 가장 먼저 해야 할 일은 안정적인 최신 코드 베이스로 시작하는 것입니다. 이렇게 하기 위해 main 분기의 로컬 복사본을 서버 복사본과 동기화할 수 있습니다. 이렇게 하면 마지막 동기화 이후 서버의 main 분기에 푸시된 다른 모든 개발자 변경 내용을 로컬 복사본으로 끌어옵니다.
2단계: 코드 복사본에서만 작업하려면 해당 기능 또는 버그 수정만을 위한 새 분기를 만듭니다. 짐작할 수 있듯이, 수행하는 모든 작업에 대한 분기가 많으면 기억하기 쉽지 않기 때문에 여기에서 적절한 명명 규칙을 사용하는 것이 중요합니다.
파일을 변경하기 전에 다른 분기가 아니라 해당 분기에서 파일에 대해 작업하고 있음을 알 수 있도록 새 분기를 체크 아웃합니다. 분기를 체크 아웃하여 언제든지 분기를 전환할 수 있습니다.
3단계: 변경 내용은 분기 내에만 적용되기 때문에 원하는 대로 변경해도 안전합니다. 작업할 때 분기에 대한 변경 내용을 커밋하여 모든 작업이 손실되지 않도록 하고 이전 버전의 변경 내용을 롤백하는 방법을 제공할 수 있습니다. 변경 내용을 커밋하려면 먼저 Git에서 커밋할 준비가 된 변경 내용을 알 수 있도록 파일을 준비해야 합니다.
4단계: 다음 단계는 다른 사용자가 내가 진행 중인 작업을 볼 수 있도록 원격 리포지토리(예: GitHub)에 로컬 분기를 푸시하거나 업로드하는 것입니다. 걱정하지 마세요. 이렇게 한다고 해서 변경 내용이 병합되지는 않습니다. 작업은 얼마든지 자주 푸시할 수 있습니다. 실제로 이는 작업을 백업하거나 여러 컴퓨터에서 작업할 수 있는 좋은 방법입니다.
5단계: 이 단계는 일반적이지만 필수는 아닙니다. 코드가 원하는 대로 작동하는 것을 확인했으면 원격 main 분기를 로컬 main 분기로 다시 끌어올(병합) 수 있습니다. 원격 master 분기에는 로컬 main 분기에 아직 없는 변경 내용이 있습니다. 원격 main 분기를 내 분기와 동기화한 후에는 로컬 main 분기를 작업 분기에 병합하고 빌드를 다시 테스트합니다.
이 프로세스를 통해 최신 코드를 사용해도 기능이 잘 작동하는지 확인할 수 있습니다. 또한 끌어오기 요청을 제출할 때 작업을 원활하게 통합할 수 있습니다.
6단계: 이제 로컬 코드를 커밋하고 호스트된 리포지토리로 푸시해야 합니다. 이 단계는 3단계, 4 단계와 동일합니다.
7단계: 원격 main 분기에 대한 변경 내용을 제안하기 위한 준비가 완료되었습니다. 제안하려면 끌어오기 요청을 시작합니다. Azure Pipelines 또는 다른 CI/CD 시스템에서 구성된 경우 이 단계를 실행하면 빌드 프로세스가 트리거되고 변경 내용이 파이프라인을 통해 이동하는 것을 볼 수 있습니다. 빌드가 성공하고 다른 사용자가 끌어오기 요청을 승인한 후에는 코드를 원격 main 분기에 병합할 수 있습니다. (변경 내용 병합은 여전히 사용자가 직접 수행합니다.)
Andy: 복잡하고 배우기 어려워 보이는데요.
Mara: Git은 너무 강력하기 때문에 위협적으로 보일 수 있지만, 흐름을 익히고 나면 자연스럽게 느껴지기 시작합니다.
매일 명령을 몇 개만 사용해 보세요. 다음은 요약입니다.
| 범주 | 원하는 작업 | 사용할 명령 |
|---|---|---|
| 리포지토리 관리 | Git 리포지토리 만들기 | git init |
| 원격 리포지토리 다운로드 | git clone |
|
| Branch | 분기 만들기 | git checkout |
| 변경 내용 준비 및 커밋 | 어떤 파일이 변경되었는지 확인 | git status |
| 커밋할 파일 준비 | git add |
|
| 분기에 파일 커밋 | git commit |
|
| 원격 동기화 | 원격 리포지토리에서 분기 다운로드 | git pull |
| 원격 리포지토리에 분기 업로드 | git push |
Andy: 이렇게 시작하면 좋겠네요. 이제 잘해 나갈 수 있을 것 같아요. 필요하면 고급 명령을 더 배울 수도 있고요.