이제까지 대략적인 깃 사용법을 정리해 보았습니다. 하지만 주로 다루지 않았지만 중요한 명령어들과 사용법들을 이번 글에서 정리하겠습니다.

git fetch

이 명령어는 가장 많이 사용하게 될 명령어중 하나입니다. 아침에 출근해서 컴퓨터를 키면 먼저 실행하는 명령어!. 하는일은 로컬 저장소에 원격 저장소의 정보들을 새로 업데이트 주는 일입니다. 그래서 원격 저장소에 무엇인가 업데이트가 되었다면 로컬저장소에 받아야 할게 있다고 알려줍니다. 이렇게 내려 받아야 할 정보들은 pull 항목에 표시됩니다. 깃허브에서 직접 몇가지 커밋을 한 후에 fetch를 실행한 화면을 같이 보시면 이해하기 더 쉬울겁니다.


source control에서 pull 표기가 저렇게 나오네요. 해당 버튼을 클릭하면 원격저장소에 저장되어 있던 변화들이 로컬에 적용됨을 알수 있습니다.

git pull

바로 위에서도 나왔던이 원격 저장소에 있는 변화된 내용을 로컬 저장소에 가져오는 명령어입니다. 사시 이 명령어를 바로 실행하면 git fetch는 안해도 됩니다.
내부적으로 git fetch, git checkout 명령어가 실행되기 때문입니다. 하지만 저는 git

fetch를 많이 사용하는게 좋다고 생각합니다. 어떤 변화가 있는지 확인 후
git pull로 받는것을 선호하기 때문입니다.

git cherry-pick commit-id

이 명령어는 주로 다른 브랜치에서 특정한 커밋들만 모을때 사용합니다. 배포 관련 이슈로 특정한 내용만 모아야 할때 많이 사용하곤 했습니다.
git log –oneline –all –graph 명령어로 원하는 commit-id를 확인하신후 git cherry-pick commit-id으로 특정한 커밋 내역만 현제 브랜치에 가져올수 있습니다.

깃 정책들

여러사람이 작업을 하다보면 git log가 복잡해지고 지저분해 보이기 때문에 개발하는 회사, 혹은 팀마다 다양한 깃 정책들을 적용해서 관리를 합니다.
git flow, github flow, gitlab flow, trunk-based등 정책들이 유명한 정책들입니다. 제 경험으로는 git flow를 가장 많이 사용했었습니다.

1. 이 정책은 운영을 하다가 개발 사항이 생기면 develop 브랜치에 feature 아래에 브랜치를 만듭니다.
2. 개발이 완료되면 develop에 머지 후 테스트
3. 개발에서 테스트가 완료되면 release branches에 머지(보통 stage라는 브랜치입니다)
4. release branches에서 테스트가 완료되면 master에 배포해서 운영에 반영합니다.
5. 그리고 운영에서 긴급하게 수정해야 할경우 hotfixes라는 브랜치를 만들어서 수정을하고 바로 master에 배포합니다. 그 후 master를 develop에 병합합니다.
이게 가장 일반적인 정책이지만 팀마다 다를수 있기에 그팀의 정책에 맞게 작업하거나 팀의 리더라면 팀상황에 적합한 정책을 만들어서 적용하는게 좋습니다.

github에서 pull request(PR) 요청하기

위의 정책들을 적용하다보면 develop, stage, master에는 개발자들이 직접 merge, push를 못하게 권한이 제한되어 있는 경우가 많습니다.
그럴때는 깃허브에서 직접 PR을 요청하면 관리자가 보고 승인을 해주면 해당 브랜치에 머지가 됩니다.

new pull request를 클릭합니다.

compare에 반영할 브랜치를 선택합니다. base에는 배포할 브랜치를 선택합니다. 그리고 아래의 비교화면을 보고 잘 된건지 확인후 create pull requst를 눌러서 요청을 마무리합니다.

그리면 관리자가 해당 내용을 보고 위처럼 승인을 해주면 main에 머지가 됩니다.

오늘은 깃에서 중요하지만 다루지 않았던 내용들을 다루어보았습니다.