종류는 GitHub, GitLab, Git Bash, TortoiseSVN, Unity Devops(UVCS) 등..
팀 프로젝트 중 코드 수정 사항이 발생하면 팀원들에게 수정 내용을 뿌려줘야 함
그런데 동시에 수정 사항이 발생하면? 난리남
그래서 팀원들 사이에 컨트롤 타워를 놓은 게 Git Bash. 클라우드 공간에다 작업한 것을 올려 놓는 것
기능은 commit, push, pull, undo, amend, revert, branch, cherry-pick, checkout 등이 있다.
GitHub과 GitLab의 차이
GitHub: 버전 컨트롤을 위한 무료 오픈 소스. GitLab과는 형상관리를 위해 중앙 서버를 어디에 두었고 또 어떻게 서비스하냐의 차이가 있다.
GitHub이 유료고 GitLab이 무료이던 시절에는 public한 소스, 오픈 소스를 배포하기 위해 GitHub(공유형), private한 소스 또는 상업용을 관리하기 위해 GitLab을 쓰는 게 대표적인 개념이었다. 요즘은 상업용을 위해서 꼭 GitLab을 사용하진 않지만 현존하는 기업의 시스템은 대부분 GitLab을 따라가고 있다.
GitLab이 GitHub보다 나중에 출시되어 UI와 CI가 조금 더 낫다. 그리고 private 서버를 로컬이나 나스에 설치해 자신만의 버전관리 서버를 만들 수도 있다.
CI: 개발자가 각각 개발한 소스코드를 모아서 한꺼번에 통합 빌드의 과정을 특정 시점이 아니라 주기적으로 수행함으로써, 통합에서 발생하는 오류를 사전에 해결하고 이러한 과정들에 소요되는 시간을 줄이기 위한 기법. 예로 CI 툴인 젠킨스가 있다.
GitHub의 구조
Local Main Branch에서 Feature Branch를 생성하고 Feature Branch에서 작업한 결과물을 Commit한다.
그 후 작업물을 Push해주고, 원격 저장소 Feature Branch에서 Merge를 거쳐 Main Branch로 옮겨주는 것.
Git Flow
일반적으로 말하는 Git Flow 전략. 다만 기업마다, 프로젝트 마나 상이한 부분이 있음. 이 기본 틀을 가져와서 조금씩 변형된다.
Main(전 Master): 운영 관리 브랜치. 클라이언트에 가장 가까운 브랜치. 여기는 웬만하면 가볍게 건들지 말자.
Hotfixes: 운영 중 치명적인 버그가 발생했을 때, 해당 브랜치를 생성하여 cherry-pick과 같은 기능을 사용해 Merge 및 관리를 하는 브랜치
Release Branches: 새로운 출시 버전을 관리하는 브랜치. 출시된 기존 버전 외에 해당 브랜치에서 작업을 하다 Main 브랜치로 병합이 될 수 있다.
Feature Branches: 기능 개발을 위한 브랜치. 주로 새로운 작업을 위한 브랜치로 생성된다.
Branch
Branch: 독립적인 작업을 이루기 위한 개념.
독립적으로 다른 소스를 작업하고 싶을 때 브랜치를 하나 생성한다.
Merge
생성된 브랜치에서 작업을 하다가 작업이 종료되는 시점에 Merge(병합)을 하는데, GitHub에는 Pull Request로 병합 요청을 보내고 요청이 수락되기 전까지 코드 리뷰라는 과정을 거치게 된다.
Rebase
주로 병합 간의 충돌 시 사용한다.
서로 다른 브랜치 간의 병합시, 같은 파일을 수정하거나 공통된 수정사항이 있을 경우 사용함
단, Rebase는 History를 변경하기 때문에 반드시 혼자 작업하는 브랜치에서만 사용해야 하며 Rebase 진행 후 강제 푸쉬 해주어야 함
Rebase하기를 원하는 브랜치를 선택하고 Rebase 대상이 되는 브랜치를 우클릭(fork tool 기준)하면 Rebase '브랜치' to Here이 있다. 클릭하면 Merger Confilct 경고가 뜨는데 당황하지 말고 충돌을 해결해주면 된다.
'<<<<<HEAD', '====', '>>>>> 커밋 메세지'
위 세 가지 요소가 충돌 구간에 보이게 된다.
HEAD는 현재 바라보는 브랜치이고, ====를 기준으로 하여 >>>>>커밋 메세지를 가진 브랜치로 병합이 됨을 의미한다. 원하는 소스의 구간을 적절히 해결하면 된다.
Amend
커밋은 했지만 추가적으로 커밋을 하고 싶을 때 사용한다.
Fork tool 기준으로 commit 버튼의 좌측 Amend 체크박스 체크 시, 이전에 커밋한 내역과 함께 현재 Staging한 파일을 커밋할 수 있다.
Cherry-Pick
원하는 커밋만을 가져올 때 사용한다. 원하는 수정 부분만 가져오고 싶을 때 사용
예를 들어, 운영 중인 서비스(Main Branch)에 버그가 발견되고 해당 버그를 수정하기 위해 브랜치를 개발 소스 브랜치에서 feature를 생성한다.
해당 버그에 대한 수정은 됐지만 기존에 개발 소스는 운영중인 서비스에 반영하고 싶지 않을 경우에 Cherry-Pick을 사용한다.
Reset & Revert
Reset은 말 그대로 다시 되돌리는 것
Reset과 Revert은 '옛날 커밋으로 브랜치를 되돌리겠는가'와 '해당 커밋을 취소하겠는가'의 차이가 있다.
Reset은 세 가지가 있다.
Mixed: 변경은 하지만 기존에 푸쉬해 놓았던 부분은 남겨놓는다. Stage에 남겨놓는다. (e.g. 복권은 샀지만 복권 번호는 머리속에 남겨놓고 과거로 돌아간다)
Hard: 그냥 깔끔하게 되돌린다.
Soft: Mixed와 비슷하지만 Stage 아래에 있다.
Default로 Mixed를 사용한다.
Revert의 경우 푸쉬를 해도 Revert가 가능하며 Commit 이력에 남는다.
또한 [A <- F1 <- B <- F2 <- C] 와 같은 작업이 있을 경우, F1과 F2의 커밋을 제외하고 싶을 때 Revert를 사용한다.
[A <- F1 <- B <- F2 <- C] <- F1 Revert <- F2 Revert (제거)
Stash
임시 저장을 하는 기능.
개발 중인 내역을 잠시 중단하고 다른 개발을 해야할 때 사용한다.
Stash를 만들어 놓고 다른 개발 건을 진행 완료한 후, 기존의 Stash를 불러와 Apply하는 방식으로 사용함
Fork tool 기준 좌측 상단에 Stash를 만드는 버튼이 있다. 만들어진 Stash는 Box 모양으로 표시된다.
GitHub Desktop
튜토리얼을 진행해 보자.
desktop-tutorial 레포지토리에서 New Branch 'develop'을 생성
튜토리얼의 'README.md' 파일을 열어 경로를 desktop-tutorial로 지정
'Git 레포지토리를 찾았습니다. 열까요?'라는 문구가 뜬다. 열어줌
새로운 코드 'gee' 작성 후 저장
깃헙 데스크탑으로 가면 Changes에 작성한 'gee' 코드가 보임
Summary에 변경 내용을 입력하고 Commit to develop 클릭
그러면 History에 새 커밋이 추가됐다. Push origin을 눌러 publish
이러면 완료
Clone
Clone
원격 저장소에서 로컬 저장소로 내려받음을 말함.
SVN에서 checkout과 동일한 기능.
로컬 저장소 설정
따로 깃을 관리할 폴더를 만들어 준다. 나중에 레포지토리가 늘어날 수록 관리가 편해짐
원격 저장소 주소 복사
GitHub에서 Code를 클릭하면 HTTPS, SSH, GitHub CLI 이 세 가지 옵션이 보임. Fork 툴을 사용하여 클론하려면 Https 주소 사용. 복사하면 됨
Fork Clone
메뉴 -> File -> Clone 선택
팝업창이 뜨는데 Url을 Repository Url에 넣어줌
Parent Folder는 해당 레포지토리의 부모 폴더. 아까 따로 만들어놓은 깃을 저장하기 위한 로컬 저장소.
Name에는 생성하고 싶은 레포지토리의 로컬 이름 설정. 원격 저장소와 같게 해주면 편하다.
Clone이 되면 상단에 해당 레포지토리명이 생성됨. 완료
Fork에서 Branch 생성
Fork 툴 사이바에 Branch를 우클릭하면 'Create New Branch'가 보인다.
Branch name 'feature/Gee-수정'. feature라는 폴더 아래 'Gee-수정'이라는 브랜치를 만들겠다는 뜻
생성된 브랜치를 더블클릭 해주면 Check out(해당 브랜치로 이동)된다.
로컬 레포지토리에 새로운 feature 브랜치를 만들었다. 여기서 작업을 진행하면 되고 작업이 끝난 이후 원격 레포지토리로 push 및 Merge Request를 진행하면 된다.
