Git : branch, merge, github 자체기능.

● branch : git의 자체적 기능으로 분기라는 의미다. commit을 하다보면 version을 분기화 하는 것이다. (예: 배포/테스트/개발용 버전 구분을 위해)

 

branch    | commit log                                |  파일 상태

main       | commit1 > commit2 > commit3 | commit 1,2,3

develop  |                                 > commit4  | commit 1,2,4

 

위와 같이 브랜치 설정 후 서로 영향이 없는 걸 알 수 있다.(파일과 커밋 기록이 별도로 관리된다.)

 실무에서는 버그 픽스, 배포용, 기능 별로 브랜치를 생성해서 각각 개발을 진행하고 개발완료 후 브랜치를 한로 통합(merge)해서 서비스를 완성하는 방식으로 진행한다.

 

아래는 branch 관련 git 명령어 모음이다. 

main 을 고정 브랜치 이름으로 설정:  git config --global init.defaultBranch main

branch 이름 변경 : git branch -m main (-m은 이름 변경 옵션이다.)

branch 생성 : git branch (브랜치 명) 또는 git switch -c (브랜치 명) 

branch 확인 : git branch --list

기 생성된 브랜치로 변경 : git switch (브랜치 명)(switch는 chekout 명령어와 유사하지만 최근에는 switch만쓴다고 한다.)

branch 삭제 : git branch - d (브랜치 명)

 

위 처럼 기능 작업을 분업하기 위해 branch를 활용하여 각각 작업을 한 뒤, 뒤에나오는 merge를 통해 하나의 파일로 통합한다. 

(브랜치 명은 일반적으로 기능별로 작성한다. feature/#5와 같이 github내에서 issue로 주어진 작업내용을 브랜치 명으로 생성한다.)

 

● merge 

merge는 branch로 나뉘어진 기능 (feature)들을 합치는 것이다.

merge를 실행할 경우 git의 관리하에 있는 로컬저장소의 기록들이 하나로 합쳐진다. 또한 파일의 내용역시 합쳐진다.

때문에 merge는 신중히 실행해야할 것임을 명심해야한다.

 

아래는 merge와 연관된 명령어이다.  

rm -rf .git : .git 폴더를 지워 해당 로컬저장소의 git에 관한 정보를 초기화한다. (기록을 초기화시켜 merge 실습을 하기위해 사용했다.)

git merge (브랜치 명) : 현재 브랜치(head)에 따로 작업한 브랜치 작업파일을 합친다.

git log : 상세한 git 기록 내역을 불러온다.

git log --oneline : 한줄로 git 기록내역을 불러온다. 

git log --oneline --graph --decorate : git 기록 내역들이 분기에 따라 나뉘었다가 머지로 합쳐진 것을 그래프로 보여준다.

 

!. merge를 하다보면, 코드라인이 겹치는 경우 comflict(충돌)가 발생한다. 이런상황에서 VSC는 어떤 방향으로 합칠지 선택 옵션을 제공하게되고, 선택을 하고 나면 정상 merge가 이루어지게 된다. 

주의할 점은 이후 Etc: Merge develop to main 과 같은 형태로 재 커밋해야 한다는 점.(로컬 저장소 내에서 이뤄지는 머지 컴플릭트는 머지를 목적으로 행한것이기에 컴플릭트와 관련된 내용은 커밋메세지에 기재하지 않는다.)

 

*꿀팁으로 이러한 상황을 방지하기 위해 각자 다른 파일을 맡아서 작업하거나, 같은 파일을 작업할 경우 함수를 다르게 작성하여 헷갈리는 일이 없도록 해야한다고 한다.

 

● fast-forward 

한 줄로 나열시키는 머지방법인데, 추천되지 않는다고 한다. 

이유는 한줄로 나열시키면, 어떤 브랜치에서 누가 작업했는지 등의 로그가 사라지기 때문에 확인하기가 힘들다는 것이다.

 

branch    | commit log                                |  파일 상태

main       | commit1 > commit2                   | commit 1,2

develop  |                                 > commit3  | commit 1,2,3

 

이와 같은 형태일때 merge를 실행하면 패스트 포워드가 일어나 한줄로 로그를 정리시켜 버린다. 

때문에 git merge develop --no-ff 옵션을 사용해 패스트 포워드가 일어나지 않도록 방지해야한다.

 

● rebase 

특정 브랜치를 기준으로 놓고 커밋 이력을 일렬로 정렬 시키는 명령어다. 

일반적으로 복잡한 로그의 경우 적용하여 정렬시키는 목적으로 사용되며, 머지하는 경우가 아니어도 사용한다고 한다.

실제 사용은 특정 프로젝트에 FORK할때 주로 사용한다고 하는 데 현재의 내 수준에선 사용할 일이 적을것이라고 배웠다.

리베이스에도 머지와 같은상황에 컴플릭트가 발생하는데 

git add . > git rebase --continue 를 사용하여 컴플릭트를 해결할 수 있다고 한다.

 

● pull request

앞서 설명한 개념들은 로컬 저장소 내 git에서 사용하는 것 위주였다면 풀리퀘스트 부터는 github로 이동한다. 

이미 브랜치도 생성했고,  깃허브와 연결도 된상태고, 각 브랜치의 작업을 끝내서 깃허브로 푸쉬하게 되면 이 풀 리퀘스트의 형태로 main(실무에선 시니어 개발자) 브랜치에 도달하게 된다. 

즉, 작업이 완료되었으니, 병합을 요청하는 것.

이 때 리퀘스트를 작성하는 원칙은 아래와 같다.

 

## 담당 기능 

-이름 (이 옆에 Close issue 넘버를 적으면 issue와 연동되어 머지수락 시 이슈도 해결된다.)

##변경 사항

-[ ]세부내용

 

풀 리퀘스트를 요청받게 되면, 해당 코드를 리뷰할 수 있고 검토/수정을 거쳐 머지에 이르게 된다.

코드리뷰는 file changed 항목에서 각 코드마다 리뷰할 수 있으며, 리뷰를 끝낼땐 finish (comment, approve 등) 세가지 선택지에서 선택해야한다.(자신의 풀리퀘스트는 코멘트밖에 달 수 없다)

이후 머지된 main의 레포를  각 브랜치 담당자들이 git pull 명령어를 사용하여 내려받을 수 있다.

주의할 점은 리퀘스트에 사용된 브랜치는 머지이후 즉시 삭제해주는것이 혼란을 방지할 수 있는 예방책이라는 것이다.

실습때 나도 까먹었지만, 꼭 잊지말자.

사용된 브랜치는 git fetch --prune으로 로컬저장소에 정보를 내려받고, 앞서 배운 git branch -d (브랜치 명)옵션으로 로컬내에서도 브랜치를 삭제할 수 있다.

 

풀리퀘스트 역시 머지와 같이 컴플릭트 상황이 발생하는데, 그럴 경우 에디터로 다시 pull하여 작업한 브랜치에서 main의 코드를 머지하여 해결한다.  그 이후 다시 push 하면 컴플릭트가 해결된다.

(이 때에 commit메시지에 for resoved comflict와 같이 부연을 달아주는데, 머지만 하려고 한것이 아니라 컴플릭트를 해결하기 위해 머지를 행한것이기 때문이다.)

 

머지와 풀리퀘스트 개념들은 협업을 위해 꼭 필요한 개념이지만, 서로 공유하는 방식이 늘 궁금했어서 그런지 굉장히 재밌게 수강할 수 있었다.

 

< github 자체 기능활용>  

● issue / label / milestone

 

이슈는 할일 정리의 용도로 사용된다. (구현할 기능/ 버그 필스 등) 오픈소스일 때와 일반적인 사용에서 차이가 있지만, 일반적으로 사용할 때 굉장히 유용한 기능이다.(할일 체크리스트) 

앞서 말했듯 각 브랜치 명을 이 이슈에서 할당된 번호로 작성하는 만큼, 프로젝트를 시작할 때 먼저 협의하고 작성해야하는 항목이다. 

이슈내에는 라벨과 마일스톤을 선택할 수 있는데, 라벨은 이슈가 어떤 카테고리(ex. bug, feat 등)에 속해있는지 알려주는 역할을 하고, 마일스톤은 이슈들의 집합으로서 현재 프로젝트 진행도가 얼마나 진행되었는지 확인할 수 있는 카테고리이다.(일반적으로 버전별로 마일스톤을 나누고 이슈에 필요한 라벨을 만든 후 이슈를 만든다)

 

● wiki 

프로젝트 관련하여 버전에 관한 정보, 라이센스에 관한 정보, 프로젝트에 기여하는 방법 등을 기재하는 기능이다. 

실습과정에서는 팀 끼리의 커밋 메시지 타입을 올려둔다(이름규칙)

 

●github actions

연차가 쌓일 수록 필요해지는 기능으로써 자동 배포설정, 테스트 브랜치에 푸쉬되면 자동 테스트 등의 기능을 갖고있다.

 

●github pages 

github.io 주소로 자신의 웹사이트를 배포할 수 있는 기능이다. 

레포를 만들 때 유저명.github.io 로 생성하면되고 사이트 내부 디자인 등은 VSC에 해당 폴더를 만들어 작업하면된다.

이때 index파일로 html, css등이 작업 가능하다.

선생님의 추천은 hexo로 깃헙 블로그를 만드는 것이었다.

 

git 강의는 전체적으로 프로그래밍이 협업을 전제하고 각 기능별로 따로 작업한다는 것을 확실하게 알려주었다.

팀 실습을 진행할 때 서로가 각자의 파트로 나뉘어져 작업한 후 최종본으로 내려받을 때 짜릿한 즐거움이 있다는 걸 알게되었다. 본인 업무를 개인적으로 작업하는 것도 좋지만 레고처럼 딱딱 맞아떨어지는 협업에서 오는 즐거움이 있는것 같다.

 

오늘 많은 내용을 다뤘지만, 그래도 뺄것하나 없이 다 실무에서 필요한 것들로 구성되어있어 굉장히 만족스러웠다.

내일도 실습이 있다니 기대되는 부분이다.

 

위 내용은 2022.12.14에 공부한 내용입니다.

링크 : https://dudwls3278.tistory.com/12