[Swift] 팀프로젝트 세팅부터 마무리까지 (깃헙 & 터미널 사용법) - git, branch, merge

🔗 왕초보를 위한 Git 명령어 모음집 (링크)

---

🟥 프로젝트 처음 시작할 때 팀장이 세팅할 것

1단계: git 세팅

1. 프로젝트 폴더 생성

 

2. 초기 코드 작성

 

3. 깃 초기화, 저장

git init
git add .
git commit -m "메시지"

 

4. 깃헙 레포지토리 생성

 

5. 깃헙 업로드

git remote add origin <깃헙 레포지토리 주소> // 깃헙 주소를 origin이라는 이름으로 저장
git branch -M main         // 현재 브랜치명(master)을 main으로 바꾼다(관례)
git push -u origin main    // 'git push'라고만 해도 git push origin main이 실행되도록 함

 

2단계: 브랜치 세팅

1. 로컬에서 dev 브랜치 생성 (main은 최종본이므로 dev에서 개발한다)

git switch -c dev

 

2. 깃헙에 반영

git push origin dev

 

3. 깃헙에서 dev브랜치를 default로 설정

경로 : settings > Default branch 

 

 

🟧 깃헙 공유 (collaborator 등록)

팀장 : Git collaborator 등록

> Settings > Collaborators > Add people

 

팀원: 메일 링크로 초대장 수락

 

🟨 git clone 하기

팀원은 레포지토리 주소를 복사하여 터미널에서 클론한다.

git clone 깃헙 주소

 

🟩 각자 맡은 기능 개발 (기능 브랜치 생성)

각자가 개발하는 기능의 브랜치를 생성하여 개발을 시작한다.

 

1. 기능 브랜치 생성 및 이동

git switch -c 기능브랜치명
// 참고: 기능브랜치명 예시 -> feature/signup

 

2. 코드 작성(수정)

 

3. 코드 저장

git add .
git commit -m "메시지"

 

4. 코드 업로드

git push origin 기능브랜치명

 

 

🟦 코드 머지하기 (dev브랜치 <- 기능브랜치)

1. Pull request 생성

: 기능 브랜치를 dev 브랜치로 머지하도록 설정한다.

 

2. 리뷰 요청 & 작성하기

리뷰 요청 : Pull requests > Conversation > 우측에 reviewers

리뷰 작성 : Pull requests > Files changed > Start a review > [리뷰 작성] > Submit review

 

3. 로컬에서 충돌 해결 및 테스트

3-1. 기능브랜치에서 dev브랜치 땡기기

git pull origin dev

 

3-2. 기능브랜치에서 충돌 해결(수정) 및 저장, 기능브랜치로 업로드

git add .
git commit -m "메시지"
git push origin 기능브랜치명

 

4. 깃헙에서 머지하기

* 기능브랜치를 dev브랜치로 머지

 

5. 로컬 dev브랜치에도 머지 내용 반영하기

git switch dev
git pull origin dev

 

 

---

 

💭 머지 관련 질의응답

Q1. 머지 대신 pull 한다면?

브랜치가 main, dev, feature 이렇게 세 개 있고, feature를 dev에 머지하려는 상황이라면
1. pull request 생성
2. feature 브랜치에서 git pull origin dev -> 충돌 해결 -> 다시 업로드
3. 깃헙에서 merge
이렇게 하는거라고 배웠잖아요, 그런데 혹시 merge를 사용하는 대신dev에서 feature를 pull해도 되는걸까요?

git switch dev
git pull origin feature
<충돌 해결>
git add .
git commit -m "메세지"
git push origin dev​

 

이렇게 해도 dev로 feature에서 개발한 내용을 끌어올 수 있을텐데요...merge를 사용하는 건 개발 현황 파악에 용이하기 때문일까요?

 

 

답변:

안녕하세요!
질문 주신 상황에서는 pull을 통해서도 같은 동작이 가능할 것 같네요! 또 PR에서 merge시 더이상 사용되지 않는 feature 브랜치를 삭제할 수 있는 기능도 제공한답니다.

 

또 말씀하신대로 깃헙에서 트리구조로 현황을 파악하기 쉬워진다는 장점도 있기 때문에 일반적으로는 merge를 활용합니다!
이미지로 된 트리구조 예시도 함께 첨부합니다 ㅎㅎ

트리구조

단순히 pull을 통해 다른 branch의 작업 내용을 가져오게 된다면 위 그림과 같이 합쳐지는 흐름은 보이지 않을것 같네요! 

---

Q2. PR이란?

오호... 그렇군요...!! 자세하게 설명해주셔서 감사합니다!
PR에서 merge시 더이상 사용하지 않는 feature 브랜치를 삭제할 수 있다고 하셨는데요, 혹시 PR이 뭔지 알 수 있을까요..?ㅎㅎ

 

답변:

pr은 pull request의 줄임말입니다! 일반적으로 사용되는 용어라 미리 알아두시면 좋습니다!

---

 

Q3.  트리구조 확인 방법

트리구조는 github에서 확인할 수 있는건가요? 저도 제 프로젝트를 확인해보고 싶어서요!

답변:

https://bloodstrawberry.tistory.com/987 이 블로그를 참고해보면 좋을것 같은데요!

터미널로 만들거나 깃헙에서도 확인이 가능합니다!

이외에 GUI라고 하는 소스트리, 깃크라켄 등의 조금 더 편리한 툴을 활용하셔도 됩니다!