우리 회사에서 나와 박대리님이 함께 정리한 문서. 박대리님 정리 정말 잘하신당...
1. Git 사용에 필요한 개념
1) branch 개념
- branch란 같은 소스를 동시에 개발하기 위한 개념입니다. 일반적으로 master branch는 배포 가능한 상태의 소스만을 가지고 있습니다. 기능 별로 branch를 생성하여 작업을 하고 완료되면 작업 내용이 최종적으로는 master branch에 합쳐지고(merge), master branch의 소스로 배포를 하게 됩니다.
- branch를 어떻게 관리할지는 정해져 있지 않고 구성원들의 협의에 의해 정할 수 있습니다. master branch에서만 작업할 경우 SVN과 사용법이 크게 다르지 않지만, git의 장점을 살릴 수 없기에 일반적으로는 최소 master, develop, feature 3가지 branch를 사용합니다.
- 기본적으로 branch 관리는 local에서 이루어지기 때문에 무한히 만들 수 있으며 commit도 자유롭게 할 수 있습니다. remote repository에 push하지 않으면 작업 내용은 공유되지 않습니다.
- branch 간 소스 병합은 Merge 명령어를 사용합니다. 사용자가 직접 merge를 할 수도 있고, Pull Request를 만들어 git 관리자에게 merge를 부탁할 수 있습니다. 보통은 작업자가 직접 merge하지 않고 코드 리뷰 과정을 거쳐 문제가 없다면 관리자가 Merge를 진행합니다. Pull Request 및 merge는 remote repository에서 일어나는 개념입니다.
2) local repository - remote repository 개념
- Git을 생성한 local Directory 내에 .git이라는 directory가 생성되면서 그 안에 버전 컨트롤의 모든 history가 저장 됩니다.
- Git에는 SVN과 달리 local(PC), remote(Server)에서 모두 소스 버전 관리가 가능합니다. 이는 local에도 다양한 버전의 소스가 존재할 수 있다는 것을 의미합니다. Local의 소스는 다른 구성원과 공유되지 않으며 개발자들간의 협업을 위해서는 remote repository를 사용합니다.
- Remote repository에는 bitbucket, github, azure devops repo 등이 있으며 그 중에서 저희는 azure devops를 사용하기로 하였습니다. remote repository들간의 차이는 별로 없으며, 서로 간의 수정 내용을 확인하는 용도로 많이 사용합니다.
- local repository에서 remote repository로 내보낼 때는 git push라는 명령어를 사용합니다.
3) add, commit, push 개념 (로컬 git repository가 있을 때에만 가능)
- Git 에는 SVN과는 달리 staging area라는 게 있어서, commit을 하기 전에 담아두는 공간이 있습니다.
① 수정한 소스를 staging 상태로 만듬
git add [파일/디렉토리]
참고)보통 수정한 파일을 모두 staging 하려면 [파일/디렉토리] 경로에 .을 입력 ex) git add .
② staging 상태의 소스를 commit
git commit -m "[commit message]"
참고) staging area 에 있는 차이점을 commit 하는 커맨드 왠만하면 -m 해서 커밋 메시지 넣어주는 게 좋습니다. 커밋 메시지는 수정 내용을 요약하여 시하는게 좋습니다.(나중에 코드리뷰하기 훨씬 편리함)
③ add와 commit 을 동시에 할 수 있는 명령어
git commit -a -m "[commit message]"
④ remote repository에 소스를 반영
git push origin [branch name]
참고) (origin) 은 remote 를 말합니다(거의 항상 origin. 하지만 구성에 따라 2개 이상의 remote 가 있을수 있음).
4) merge
- merge란, 두 개의 branch를 합치는 것을 말합니다. 설명을 위해 master branch만 존재한다고 가정하고, ‘welcome_page’를 추가하는 요구사항이 존재한다고 가정하겠습니다.
① Master branch 소스를 기반으로하여 ‘welcome_page’라는 이름의 branch를 새로 만듭니다.
② welcome_page branch로 전환하여 소스를 수정합니다.
③ merge할 branch로 전환하여(이 경우 master) merge 명령어를 실행합니다.
git merge welcome_page 를 치면 welcome_page branch의 수정 내용이 master branch에 반영됩니다.
- Git에서 merge는 굉장히 중요한 개념이고 꼭 알아야 하는 개념입니다. 만약 개인 프로젝트라면, 아무렇게나 merge해도 되지만, 협업을 하는 경우 merge는 위험할 가능성이 있기 때문에, merge하기 전에 검사를 도입하는데, 그게 바로 pull request 입니다.
5) pull request (remote repository에서 행해짐)
- merge에서 말한듯이, 개인프로젝트가 아닌 협업에서는 merge가 위험하기 때문에(문제가 있는 코드가 배포될 가능성이 높음), code review를 한 이후에 merge를 허용하는 방법을 많이 활용합니다. 이 과정을 Pull Request라고 하며(줄여서 PR), senior developer 라고 해도 reviewer가 한명 이상 있는 것이 권장됩니다.
- Pull Request를 만드는 법: master, 또는 develop 등에서 나온 다른 branch( 편의상 newBranch라고 부르겠음) 에서 모든 작업을 마친 후 commit하고 push 까지 합니다. 그 이후 remote repository (github, bitbucket, azure devops repo) 등으로 가서 make pull request를 누르면 어떤 branch를 merge 하고싶은지 선택할 수 있습니다. newBranch를 선택하시고 reviewer를 등록합니다. reviewer가 approve(승인)을 한 이후, merge가 가능합니다.
6) branch 관리 전략
- master & feature
① Master branch 하나만 관리. SVN 사용 시와 큰 차이점이 없으며, 여러 기능을 동시에 개발할 경우 소스가 꼬일 수 있습니다.
- master & develop & feature
① Master branch는 배포용으로 오류가 없는 소스만을 관리. Develop branch는 테스트용 소스 관리. Feature branch는 개별 작업자들이 기능 개발할 때 사용.
② 작업자는 Develop branch에서 분기하여 Feature branch를 만들고 기능 개발을 합니다. 작업이 완료되면 Develop branch에 push, pull request를 만들고 develop branch에 merge합니다. Merge된 develop branch 소스는 테스트 서버에 배포되고, 테스트 진행 후 문제가 없으면 develop 소스를 master branch에 merge합니다.
③ Master branch에는 통합 테스트가 완료된 소스만이 유지되므로 서버에 잘못된 코드가 배포될 확률이 적어지게 됩니다(code review를 한다고 해도 새로운 업데이트를 할 때마다 master에 직접 반영하는 방식은 위험하다고 볼 수 있습니다. 특히나 CI/CD를 적용했을 경우에는 더욱 그러합니다. 새로운 기능을 개발했을 때 develop branch를 거쳐 통합 테스트를 진행하는 것이 바람직합니다(통상 2주). 특히, 테스팅 환경이 잘 구축되어 있는 경우(CI/CD) develop을 테스팅 환경이 구성이 되어 있다면 배포에 대한 부담도 줄어들게 됩니다.
ex) repository 별 branch->develop, develop->master merge를 담당할 사람 지정(정,부): 보통 부는 정을 reviewer로 입력하고, 정도 누군가 review를 할 사람이 있으면 좋습니다. Develop 에서 master로 merge는 정이 담당하고, CI/CD를 build하는 경우 devops가 추가로 있는 것이 바람직합니다.
- branch 생성 네이밍 룰(논의 필요): ex) 날짜_사용자명_기능: jira 를 사용하는 경우 티켓넘버로 branch name을 사용할 수 있습니다.
- hotfix
① 일반적으로 기능 개발 시 Develop branch 소스를 기준으로 Feature branch를 생성하여 진행하게 되지만, Master 소스에 버그가 발견되어 급하게 수정이 필요한 경우에는 develop -> master flow를 거치지 않고 master에 곧바로 수정해야 합니다. 이러한 경우에는 master branch 소스를 기준으로 hotfix branch를 생성하여 개발 진행하고 Master branch에 merge합니다.
② Master branch에서 hotfix branch를 만드는 경우, 꼭 develop branch에서도 hotfix를 업데이트를 해주어야 합니다. 그렇지 않으면 소스가 불일치하기 때문에 나중에 develop에서 master로 merge 할 때 충돌이 일어날 수 밖에 없습니다.
- 소스 개발 흐름
① 일반 적인 소스 개발 흐름: local repository에 Develop branch에서 branch out하여 Feature branch 생성 -> 소스 수정(add, commit) -> remote repository로 push -> Develop branch에 pull request 생성 -> 코드 리뷰 후 remote feature branch를 remote develop branch에 merge -> 테스트 서버 반영 -> 테스트 완료 -> develop branch를 master에 merge -> 운영 서버 반영
② hotfix 소스 개발 흐름: local repository에 Master branch에서 branch out하여 hotfix branch 생성 -> 소스 수정(add, commit) -> remote repository로 push -> Master branch에 pull request 생성 -> 코드 리뷰 후 remote hotfix branch를 remote master branch에 merge -> 운영 서버 반영 -> remote hotfix branch를 remote develop branch에 merge -> 테스트 서버 반영
6) Git ignore 파일
- 때로는 우리가 git에 올리고 싶지 않은 파일이 있을 수 있습니다. 그런 파일들을 디렉토리 별로 지정할 수가 있고, 또는 파일명 별로 지정할 수 있습니다. 예를 들어, bin/ directory안의 파일들은 git 에 저장하지 않는다든지, .metadata 는 저장하지 않는 등이 있습니다. IDE 설정 관련 파일, package 관리 파일(노드, pip, maven, gradle 등), build 파일(target), 민감한 정보(DB connection 정보) 등은 기본적으로 포함시키지 않는 것이 좋습니다. gitignore파일은 git 저장소의 root에 .gitignore라는 파일을 생성하시고 거기다가 관련된 파일이나 디렉토리를 넣으시면 됩니다.
- 참고(java spring 관련 gitignore): https://integer-ji.tistory.com/185
2. Git 사용 방법
1) 설치
- 설치 파일: https://git-scm.com/
- git-cli 설치를 권장합니다. Git-gui는 설치하지 않아도 상관 없습니다.(더 좋은 gui들이 많고 IDE 연동 시 GUI를 제공하는 경우가 많음)
2) remote repository 생성 방법(Azure DevOps)
- Git은 기본적으로 오픈 소스를 지향합니다. 소스 유출이 염려되는 경우에는 private repository로 생성하여야 합니다.
- Git repository 담당자를 정하여 관리하는 것이 좋습니다.
3-1) Git 주요 명령어(cli 기준)
- git remote repository 설정(원격 저장소 설정)
① git remote set-url origin [url]
② 계정 정보 입력이 필요할 수 있습니다: https://awesometic.tistory.com/128
- git repository 생성: Local에 존재하는 소스를 git repository로 만들어 공유하는 경우 사용합니다.
① git init (directory에 .git directory 생성)
- clone repository: remote repository에 존재하는 소스를 받아와서 local에 세팅할 경우
① git clone [url]
- branch 관리
① branch 목록확인
remote: git branch -r
local: git branch -a
② branch 생성
git branch [branch 이름]
③ branch 전환
git checkout [branch 이름]
참고) commit 하지 않은 소스가 있는 경우에는 checkout 명령어를 사용할 수 없습니다. commit까지 하고 checkout을 하든가, 수정한 소스를 rollback하여야 합니다.
④ branch 생성 및 전환
git checkout -b [branch 이름]
⑤ branch 삭제: 기능 구현이 끝나 master에 merge된 feature branch들은 주기적으로 삭제가 필요합니다.
git checkout -d [branch 이름]
- 소스 관리: 소스 관련 작업 전에 항상 현재 작업 중인 branch를 확인해야 합니다.
① remote repository에서 local repository로 소스 받기
git pull
참고) conflict가 발생하면 해당 부분을 수동으로 수정해 주어야 합니다.(GUI를 사용하거나 IDE를 연동하면 pull 전에 변경될 부분 확인 가능).
② 수정한 소스 rollback(checkout이 안되는 경우 작업한 파일은 따로 백업 필요)
git stash (수정한 소스 내용을 휴지통으로 이동. 나중에 되돌릴 수 있음)
git reset --hard HEAD (소스를 가장 최근의 커밋 상태로 되돌림)
git checkout HEAD 파일명 (파일명만 가장 최근의 커밋으로 돌아감)
③ commit, push, merge는 상단 설명을 참고
④ 그 외 유용한 커맨드들
git log (모든 커밋을 볼수 있음)
git checkout SHA123 (git log 에서 찾아낸 commit으로 돌아가려면 사용. 다시 최신 소스로 돌아가려면 git checkout HEAD 사용하면 됨)
git diff sha123 sha345 두 개의 commit을 비교 ( git log를 통해 commit id 확인)
git diff --staged (현재의 소스코드와 staging area의 소스코드 비교)
git diff (현재의 소스코드와 HEAD의 소스코드 비교)
git status (가장 많이 쓰이는 커맨드 중 하나. HEAD와 어떤 파일들이 다르고, 어느 파일이 staging area에 있는지 확인 가능)
3-2) 이클립스(STS)
- 기본적인 사용법은 cli와 동일. 설정 방법은 링크로 대체
- https://freehoon.tistory.com/139
3-3) IntelliJ
- 기본적인 사용법은 cli와 동일. 설정 방법은 링크로 대체
- https://goddaehee.tistory.com/249
3-4) Visual Studio Code
- 기본적인 사용법은 cli와 동일. 설정 방법은 링크로 대체
- https://evols-atirev.tistory.com/14
4) pull request 방법(Azure DevOps)
- reviewer 등록
- reviewer 등록자 확인 후 accept
- 모든 reviewer가 accept하면 merge
5) merge 방법(Azure DevOps)
3. source 배포
1) CI/CD 구성이 가능한 경우
- DevOps에서 파이프라인 구성
- 자동 배포 or 확인 후 배포 등 정책 결정 필요
2) CI/CD 구성이 불가능한 경우
- master branch로 전환
- master source pull
- 수동으로 빌드하여 배포
4. 참고
1) Git cookbook
- https://gist.github.com/weiland/831677d42ab356b73a7f
'Utils > Program' 카테고리의 다른 글
| nssm을 사용하여 node.js를 windows 서비스로 만들기(+ log) (0) | 2021.11.08 |
|---|---|
| ffmpeg 소개와 동영상 사이즈 줄이는 법 (0) | 2020.12.02 |
| Parallels Desktop (Mac용 VM)과 Ubuntu 18.04 (0) | 2020.10.28 |