지금부터는 우리가 배운 브랜치 개념을 소스트리에서 직접 적용해 실습을 진행해 보도록 하겠습니다. 우리는 git의 사용법을 알아보면서 ME와 John 두 사람이 파일 작업을 하는 상황을 가정하고 로컬/원격 저장소 생성 및 소스트리 적용을 진행했었습니다. 아래 과정까지 완료했었죠?
[Chapter 2] Sourcetree 처음 사용해보기 - repository 생성, origin과 master
지금부터는, 앞서 만들었던 로컬 저장소와 github에 생성해 연결한 repository를 CLI가 아닌 소스트리를 통해서 실행해 보도록 하겠습니다. 일단, 기본적으로 소스트리 다운로드 및 설치와 Atlassian 계
nozeroslope.tistory.com
지금까지의 상황을 정리해 보겠습니다.
· 작업자는 ME와 John 두 명입니다.
· ME와 John은 한 대의 PC에 \study_git 과 \study_git_john 두 개의 폴더로 작업하고 있습니다. 우리는 PC가 한대이고, 사람도 혼자이다 보니 두 사람이 작업하는 환경을 비슷하게 꾸민 것이지요.
· 해당 작업물은 readme.txt, feature-list.md, readme.txt 현재까지 총 세 개의 파일이 있습니다.
· ME가 만든 세 개의 파일을 push까지 진행했고, John은 본인의 폴더에서 $git pull origin master를 실행해 동일한 최신 상태로 업데이트해두었습니다. 실제로 계정은 한 개이기 때문에, John은 git bash를 통해서 진행했습니다.
· 브랜치는 [master] 한 개만 있습니다. ME와 John이 모두 각각 작업해서 업데이트는 가능하지만, 실습 환경 특성 상 실제로 사용자는(github 계정은) 1개입니다. 폴더로 사용자를 구분하여 실습합니다.
해당 repository의 상태는 아래와 같습니다. 현재는 [master] 브랜치만 존재하고 있으며 폴더에 세 개의 파일이 업로드 되었습니다. 자, 이제 ME와 John의 폴더가 모두 똑같은 버전으로 업데이트되었는지 까지 확인한 다음 브랜치 실습을 진행하겠습니다.
소스트리에서 본격적으로 브랜치를 만들어 보겠습니다. 통상적으로 개발 브랜치는 관리하는 조직이나 집단에 따라 관리 원칙이 다르기는 하지만, 그래도 관례적으로 지켜지는 몇 가지 법칙이 있습니다. 우리의 실습 과정에서는 다음 합의된 원칙을 적용하겠습니다.
- [master] 브랜치에는 직접 커밋하지 않는다(최종 버전이 꼬이는 것을 방지!)
- 새로운 기능 개발을 진행 시, [master] 브랜치를 바라보는 기준으로 새로운 브랜치를 생성한다.
> 이 브랜치는 [feature/name] 형식으로 이름을 정하고, 담당자 한 명만 커밋한다.
- [feature/name] 브랜치에서 기능 개발이 끝나면 [master] 브랜치에 이를 합친다.
위에서 피처 브랜치에 대한 설명이 나왔는데, ME와 John이 [master] 브랜치를 기준으로 각자 다른 피처 브랜치에서 작업을 한 이후에 그 결과물들을 [master] 브랜치에 일괄적으로 병합할 예정입니다.
우선 소스트리 상단의 [브랜치] 메뉴를 클릭합니다. 그리고 팝업 창에서 '현재 브랜치'가 master인지 확인합니다. 이 브랜치를 기준으로 새로운 브랜치가 생성되기 때문이죠. 그리고 새 브랜치의 이름을 [feature/detail-page]로 정합니다. 참고로 feature/이름 형태로 브랜치의 이름을 정하면, feature를 기준으로 자동 하위분류가 되니 참고해 주세요. 그리고 일단 하단의 '새 브랜치 체크아웃' 기능은 해제해 봅시다.
이제 왼쪽 브랜치 리스트를 보면 feature 하단에 detail-page가 존재합니다. 물론 브랜치 명은 [feature/detail-page]인데, 자동으로 분류하는 기능이 적용되었습니다. 이제 detail-page를 더블클릭하여 브랜치를 체크아웃 해봅시다. 아직 다른 변화는 없고, master를 기준으로 작업된 "피처리스트, 굿즈리스트 생성" 커밋에 새 브랜치 태그가 출력되기 시작했습니다. 자, 우리는 해당 커밋의 버전을 기준으로 여기부터 'detail-page'라는 기능을 개발을 시작하는 것입니다. 기억해 두세요!
이제 ME가 [feature/detail-page] 브랜치에서 작업하여 몇 가지 커밋을 실제로 진행해 보겠습니다. 일단 소스트리에서 [feature/detail-page]로 잘 체크아웃 되었는지 확인한 다음, ME의 폴더에서 "detail-page.md"를 생성하고 내용은 적당히 한 줄을 적도록 하겠습니다. 그리고 해당 변경사항을 커밋합니다.
push는 아직 진행하지 않고, 커밋을 완료해 보았습니다. [feature/detail-page] 브랜치가 한 단계 앞서 나간 것을 확인할 수 있습니다.
자, 여기서(ME가 [feature/detail-page] 브랜치에 상에서) 기존에 있던 파일 'feature-list.md'에 디테일 페이지 추가로 인한 변경 사항을 추가로 작업했습니다. '_상세 페이지 관리'라는 텍스트를 한 줄 추가했네요.
자, 마찬가지로 위 변경 사항도 커밋을 생성해 줍니다. '상세 페이지 관리 추가' 정도로 커밋 내용을 기록하고, 커밋을 완료해 줍니다. 이제 [feature/detail-page] 브랜치에 두 개의 커밋이 생성되어 앞서 나가고 있습니다.
이제 여기서 push까지 완료해 보겠습니다.
이제 현재 상태는 ME의 로컬 저장소에는 디테일 페이지 생성이 완료되었고, repository의 [feature/detail-page] 브랜치에 해당 변경 사항까지 적용된 상태가 되었습니다. github 페이지로 가서 직접 확인해 볼까요?
이제 좌상단의 브랜치를 클릭하여 [feature/detail-page]로 변경해 봅시다.
위에 보시면, 'This branch is 2 commits ahead of master.'라고 표시되어 있습니다. master 브랜치를 기준으로 두 개의 커밋이 생성되어 있다는 얘기겠죠? detail-page.md와 관련된 커밋 내용도 확인할 수 있습니다.
'Project Management > Git & Github' 카테고리의 다른 글
| [Chapter 3] repository 협업(4) - 브랜치 병합하기 개념 (0) | 2023.03.18 |
|---|---|
| [Chapter 3] repository 협업(3) - 새로운 branch 추가 생성하기 (0) | 2023.03.13 |
| [Chapter 3] repository 협업(1) - branch 개념 (0) | 2023.03.12 |
| [Chapter 2.5] git의 기본 작동 원리 - 파일 관리 status (0) | 2023.03.11 |
| [Chapter 2.5] git의 기본 작동 원리 - stage, commit, 그리고 스냅샷 (0) | 2023.03.09 |
