[Git] - Branch & git flow

오늘 강의에서 배운 내용은 다음과 같다.

• Branch 사용법
• Branch 전략: git flow
• 상황별 되돌리기
• github issue와 projects 사용하기
• 협업 하는 법: Forking Workflow

개인 작업을 할 때는 별로 사용을 안하던 것이어서 배울 때 git에 이런 기능이 있었는 지 너무나 신기했고 재미있었다. 오늘 배운것을 정리해 보겠다.

---

gitignore.io

branch를 사용하기 전, 새로운 repositiory를 만들면서 .gitigonre에 대한 설명을 들었다. .gitignore는 아시다시피 github에 올리지 않을 파일을 설정하는 것인데 이를 위한 유용한 사이트로 gitignore.io 을 알려 주셨다. 확실히 os, 개발환경, 프로그래밍 언어까지 설정하여 .gitignore를 만들어 주어서 나중에 프로젝트 할 때 사용하면 좋을 것 같다.

Branch 사용법

branch 사용법은 생각보다 간단하다.

우선

git branch {new branch}

이 명령어로 새로운 branch를 생성한다.

나는 로컬에서 git branch practice명령어로 생성 하였는데 생성하면 다음과 같은 화면을 볼 수 있다.

다음의 화면에선 git switch(checkout) practice로 하면 자신이 생성한 branch로 넘어 갈 수 있다.

checkout의 경우 구 버전에서 사용되고 최신 git은 switch를 사용한다!

여기서 작업을 막 하다가 작업이 완료 되었으면 원래의 branch로 가서(나의 경우 main또는 develop)

git merge practice

명령어로 merge를 해주고

git branch -D practice

로 작업이 완료된 branch를 삭제해 준다.

branch에서 작업 중 add와 commit을 하지 않고 switch를 하게 되면 main이나 자신의 기존 branch에 반영되어 위험한 결과를 초래할 수 있다
꼭 add 와 commit 해주기!!!

branch를 사용하여 마블 유니버스의 스파이더맨 시리즈를 github의 network graph로 실습해 보았다.

소니에서 만든 토비 맥과이어의 스파이더맨, 그 이후의 앤드류 가필드의 어메이징 스파이더맨, 마지막으로 마블의 톰 홀랜드 스파이더맨 홈커밍이다.

Trailing comma

branch 작업을 하면서 동시에 이 trailing comma에 대해서도 알게 되었다.

이 trailing comma는 javascript나 다른 언어에서 객체나 배열의 마지막 부분에 comma를 찍을 수 있는 것이다

예시

animals = [
    'rabbit',
    'dog',
]

git을 사용할 때 이 콤마가 중요한 이유는 git은 파일변경 이력을 볼 때 다음과 같은 상황이 생긴다.

trailing comma 없이

trailing comma 사용 시

차이를 알겠는가? git은 변경이력을 보여줄 때 위의 경우에는 'dog'옆에 콤마 하나만 붙였을 뿐인데 기존 'dog'가 사라지고 'dog', 가 새로 생겼다고 표시한다. 하지만 트레일링 콤마가 있는 경우 변경되는 그 부분만 추가 되기 때문에 여럿이서 협업할 시에 이러한 변경사항을 보여줄 때 좀 더 보기 편하게 해준다고 한다.

---

Branch 전략: git flow

다음으로는 현업에서 사용하는 branching model과 git flow 전략에 대해서 알아 보았다.

branch model의 경우

• git flow
• github flow
• gitlab flow

이렇게 총 3가지가 있는데

각각의 모델마다 장단점이 있다는 것을 알게 되었고 실습은 git flow 이 Vincent Driessen의 브랜칭 모델을 이용하여 진행되었다.

여기서의 git flow 전략을 도식화한 그림이다. 일반적인 기능같은 경우 작업한 후 develop에 코드를 merge한 뒤, develop에서 release 하고 release의 코드를 main(master)로 옮긴다.

사용법은 페이지에도 나와 있지만 간략하게 요약하면 다음과 같다.

우선 새로운 레포지토리를 만들고 클론을 해온 뒤 터미널에서 다음과 같이 입력한다.

git flow init

그러면 main branch와 develop브런치가 생긴다. 그 이후 기능을 작업할 feature branch 를 만들 기 위해

git flow feature start {featureName} 

을 생성한다. 작업을 하면서 feature branch에서 add와 commit을 하고, 작업이 다 완료 되면

git flow feature finish {featureName}

을 통해 feature branch 삭제와 동시에 develop에 merge를 한다. develop branch에서 한번 푸시를 하기 위해

git push -u origin develop

위의 명령어를 쳐준다.

develop까지 푸시가 된 상태에서 릴리스를 하려면

git flow release start {versionName}

으로 release 버전을 생성한다. 여기서도 작업을 하면서 최종적으로 릴리스 배포를 위해 다음과 같이 입력한다

git flow release finish {versionName}

그러면 최종적으로 총 3개의 vi가 켜지는데 우선 첫번째는 main과 머지하는 것으로 그냥 저장 후 종료를 누르면 되고, 두 번째는 태깅하는 vi로 메시지를 잘 적어주어야하며, 세번째 vi는 develop branch로 재 병합하는 메시지이다. 다 입력하고 저장 후 나오게 되면 main branch에서

git push origin main
git push --tags

를 통해 main branch에 코드와 tag를 push한다.

버전명

v1.11.5 다음과 같은 버전이 있다고 하였을 시, 버전의 맨 앞자리는 기능의 큰 개선이 있을 때 바뀌는 것이고 소소한 개선은 그 다음자리, 마이너한 개선은 마지막 세 번째 자리에 입력하는 것이 보통이라고 한다.

상황별 되돌리기
github issue와 projects 사용하기
협업 하는 법: Forking Workflow

파일의 연속성

git안에 있는 파일의 이름을 바꿀때

mv 기존파일명 새로운파일명

다음과 같이 바꾸게 되면 파일 자체가 없어지고 새로 생기는 개념으로 인식되어서 파일의 연속성이 끊어지게 된다. 따라서 파일의 이력을 이름 바꿀때에도 유지하기 위해 다음의 커맨드를 사용한다

git mv 기존파일명 새로운파일명

---

상황별 되돌리기

최신의 커밋으로 되돌리기

구버전 == checkout
신버전 == restore

git checkout -- helloworld.py // (파일 1개)

git checkout -- . (파일 전체)

git add하여 스테이지에 올라간거 되돌리기

git reset HEAD {helloworld.py}

git commit 한 거 되돌리기(push하기 전 상황) --> 가급적 안하는게 좋다.(why? --> 역사는 지우지않고 있는 그대로 적는게 좋다)

git reset -- hard HEAD~3

hard의 경우 파일까지 다 날라감

커밋한거는 내버려 두지만 그 전의 상태로 가는거

git revert // 여기서 --no-commit HEAD~3 을 주면 최신으로부터 3개를 되돌리고 커밋 하나만 적겠다 라는 의미

---

함께 협업하는 방법

collaborator 추가 방법

자신의 레포지토리의 setting의 manage access에 들어가 collaborator를 넣어 주면 함께 관리할 수 있지만 실제 협업할 때는 이렇게 하지 않음!

보통 코드리뷰나 이슈나 프로젝트 관리하는 사람이 따로 있고, 본 코드와 관련 없는 사람에게 collaborator 권한을 줌

Forking workflow

팀장(나) - 레포 생성 -> 본인의 레포를 복사해서 git clone후 git flow init을 통해 develop 브런치 만들어서 git push -u origin develop으로 push!

위의 작업을 다 하고나면 다음과 같은 모습을 확인할 수 있다.

팀원들에게 자신의 레포지토리 주소를 공유

https://github.com/hustle-dev/collaborator

를 하고나서 각자 자신의 레포지토리로 포크를 떠감

팀원들 자신들은 각자 자신의 포크한 레포지토리를 clone으로 가져와서 자신의 로컬 저장소에 복제함.

그 후 git flow init으로 자신의 로컬에도 main 과 develop branch가 생기도록 함

github issue와 projects 사용하기

여기까지 다 왔으면 팀장은 이슈와 프로젝트를 만들어 관리할 수 있음

이슈의 경우 팀원이 직접 올리지 않는경우 팀장이 이슈를 만들었을 때 팀원의 반응이 있어야 assign을 할 수 있다!
Project의 경우 template을 automated kanban으로 만들어야 To do, in progress, Done 같은것이 생성되어 관리하기 편함!

issue로 각자 팀원들은 역할을 배분 받고 자신이 포크한 레포지토리에서 git flow feature start {featureBranch} 로 브런치를 만들어서 작업 후에 git add. git commit을 한 후 완료 되면 git flow feature finish {featureBranch}로 푸쉬하면서 자신의 develop 브런치로 넘어오는 동시에 merge!

그 이후 git push -u origin develop을 통해 포크된 레포지토리에 올리기

그럼 깃허브에서 자동적으로 compare & pull request를 할 수 있음

이후 팀장이 올린 사람의 pull request를 보고 제안을 요청하거나 merge하는 등 여러 작업을 할 수 있음

이후 팀장의 레포지토리에 풀 리퀘스트이후 머지 된 것을 가져 올 때에는 git fetch upstream develop을 이용하고 가져온 이후 자신의 파일과 merge하기 위해 git merge FETCH_HEAD를 사용!

---