목차
- Branch 기본
- Branch의 merge
- Branch의 rebase
- Github에서의 Branch
- Github 기능 : issue, milestone
- Github Pages로 사이트 만들기
1. Branch 기본
파일을 별도로 관리하기 위한 기능
일반적인 브랜치 생성 기준
- 배포 브랜치 : main
- 개발 브랜치 : develop
- 테스트 브랜치
- 버그 픽스를 위한 브랜치
- 기능별 브랜치
기본 브랜치 : master or main
최근에는 master에서 main으로 변경하도록 유도한다.
원본 브랜치가 존재해야 하며, 분기를 수행하면 분기 이전의 히스토리는 가지고 분기가 된다.
브랜치 관련 명령어
- git switch -c (브랜치 명) : 새로운 브랜치를 만들어 전환
- git switch (브랜치명) : 브랜치 명으로 이동
- git branch (브랜치 명) : 브랜치만 생성
- git branch -m (브랜치 명) : 현재 브랜치 명을 변경
- git branch -D (브랜치명) : 브랜치 삭제
- git branch --list : 브랜치 목록 출력
- git config --global init.defaultBranch main : 기본 브랜치명을 master를 main으로
실무에서의 브랜치를 이용한 버전 관리
: 버전마다 브랜치를 파서 관리하거나, 릴리즈라는 브랜치 하나를 만들어서 거기서 업데이트를 수행한다.
브랜치 실습
- main : hello.txt 존재
- develop : main을 기준으로 브랜치로, 작성중인 readme.md이 존재한다.
- repo 생성
- 원격 저장소와 로컬 저장소 연결
- main 브랜치 내용 push
- main 브랜치를 이용해 develop 브랜치 생성
- develop 브랜치에서 readme.md 작성
- develop 브렌치에서 push
2. Branch의 merge
기능 별 브랜치를 합치는 기능
대규모 서비스에서는 하나의 브랜치에서 관리가 어렵기 때문에, 브랜치를 나눠서 통합하는 방식으로 관리
1. 깃 관리파일 초기화
rm -rf .git : 현재 폴더의 git을 관리하는 폴더를 제거
2. main 브랜치에서 작성
3. develop 브랜치에서 작성
4. merge 수행
git merge develop : main 브랜치와 develop 브랜치를 병합하는데, 커밋 기록까지 병합
vim 편집기를 이용해 커밋메시지 작성
5. 로그 기록으로 확인
git log --oneline --graph --decorate : 한줄로 그래프을 이용해 브랜치 개수와 어떤 브랜치에서 만들고, 어떤 브랜치로 병합되었는지 확인
병합 충돌 (Merge Conflict)
: 내용이 충돌되는 경우
일반적으론 터미널 상에서 merge하지 않는다.
커밋 메시지에는 컴플릭트와 같은 부수적인 행위보다는 Merge를 작성한다.
협업 시에, 같은 파일의 같은 부분은 작성하지 않도록 역할 분담
fast-forward 방식의 Merge
하나의 브랜치로 병합해 하나의 커밋기록을 남기는 방식으로 기본값이다.
git merge develop --no-ff : non fast-forward 형태로 병합하기 위한 명령어로 기록을 남기기 위해 일반적으로 사용하는 방식
비어있는 main 브랜치에서 각각의 브랜치 만들어 병합하기
- git branch name
- git branch email
- git branch desc
- git switch name
- git switch email
- git switch desc
- git merge name --no--ff
- git merge email --no--ff
- git merge desc --no--ff
3. Branch의 rebase
- 기준점을 다시 배치하기 위해 특정 브랜치 기준으로 일렬로 정렬
- 커밋이력을 브랜치 기준으로 정렬
git rebase develop : 줄기가 나뉘지 않고, 커밋 이력만을 정렬하면서 병합 (메인 브랜치 사이에 개발 브랜치 이력이 들어간다)
rebase conflict 발생
직접 원하는 방식으로 수행할지 명시
- git rebase --continue
- git rebase --skip
- git rebase --abort
rebase와 merge 차이
- rebase : 커밋 이력을 단순히 관리하고 싶을 때 사용한다.
- merge : 변경 이력을 모두 남기고 싶을 때 사용한다.
하지만 커밋 이력을 남기는 것이 굉장히 중요하므로,
일반적으로는 merge를 사용하고 커밋 이력을 정렬할 때만 사용한다.
4. GitHub에서 Branch를 활용한 Pull Request
바로 merge를 하면 안되는 이유
- 실제 서비스 코드를 안전하게 관리하는게 중요하다.
- 실제 서비스 코드를 안전하게 유지하면서 기능을 추가하기 위한 시스템
- merge하기 전에 리뷰하고, 테스트한 이후에 merge를 수행
실제 수행 순서
- 기능 개발 서버 -> develop 서버-> main 서버
브랜치 이름 규칙
: 종류/기능명
각각의 브랜치별로 모두 push가 진행된다.
: git push --all
-> pull request 요청
일반적인 Pull request 작성 기준
- 현재 PR 요약/개요
- 코드 변경 이유 (작성 이유)
- 관련 스크린샷
- 테스트 내용
- 리뷰 관련 요청사항
Pull Reqeust 처리 과정
- Pull request 요청
- 요청 사항 작성
- Files Changed를 통해 코드리뷰를 수행한다.
- 피드백을 남길 수 있다.
- 피드백 부분에 대해 해결 되었으면 conversation resovle
- Finish your review에서 세가지 답변이 가능하다. (comment / approve / request changes)
- Merge pull request 수행
- Merge된 브랜치의 경우에는 Pull requests 탭에서 Closed 된 브랜치 남아있다
- Closed 된 브랜치에 들어가면 Delete branch 버튼으로 삭제가 가능하다.
- Pull request한 브랜치를 pull을 이용해 다운을 받는다.
원격 저장소 브랜치와 로컬 저장소 브랜치의 관리
git fetch --prune : 원격 저장소 브랜치와 로컬 저장소 브랜치 동기화 (원격만 삭제)
git branch -D feature/desc feature/email feature/name : 로컬 브랜치는 직접 삭제
Pull request의 Merge Conflict
1. Merge Conflict 발생 시, 깃허브에서 Can’t automatically merge 알림
2. This branch has conflicts that must be resolved 알림
(Merge pull request 하기 위해 Resolve Conflict 버튼을 통해 해결하는건 권장되지 않는다.)
3. hotfix/name2 브랜치 (head 브랜치라고 하겠습니다)를 main 브랜치 (base 브랜치라고 하겠습니다)에 병합하는 것이 목적으로
Conflict 해결을 위해서 IDE에서 반대로 병합한다.
git switch (base 브랜치)
git pull origin (base 브랜치)
git switch (head 브랜치)
git merge (base 브랜치)
순서대로 터미널에서 입력해, IDE 상에서 conflict 를 해결한다.
4. conflict에 해결을 한 후에 깃허브에서 Merge Pull request를 이용해 머지를 완료한다.
5. Github 기능 : issue, milestone
- issue : 보통 앞으로 구현할 기능 / 버그 fix 등의 할일을 정리해놓는 용도로 사용한다.
-> pull request를 merge한 경우 해당 issue를 해결한다! - Label : 이슈의 종류를 나타낸다. (기본 9개의 라벨)
- milestones : 릴리즈를 위한 목표를 정해둔다. (이정표)
- Project : 최근엔 Notion으로 이동
- Actions
- Wiki
특정 목표를 위한 마일스톤 작성
- Label : 어떤 종류의 이슈인지 라벨링
- Milestone : 릴리즈
- Issue : 목표를 달성하기 위해 해결해야할 사안들
- Assignees : 참여자
이슈와 Pull request의 연동
1. git branch feature / (이슈번호) : 이슈 해결을 위한 브랜치 생성
2. 해당 브랜치에서 이슈를 해결하고, push
3. Pull request를 통해서 내용에 Close (이슈번호)를 입력하면 해당 이슈가 자동으로 Close 된다.
Wiki
오픈 소스의 경우 일반적으로 라이센스와 기여하는 방법에 대해 적는다.
프로젝트를 할 경우에는 커밋 메시지 타입과 같은 이름규칙을 적는다.
Actions
Workflow를 작성하는 부분으로
메인 브랜치에 Merge발생 시 -> 빌드부터 테스트, 자동 배포(CI/CD)까지의 과정을 지원한다.
6. Github Pages로 사이트 만들기
1. (사용자 이름).github.io라는 리포지토리 생성
2. 해당 리포지토리를 클론
3. 클론한 프로젝트를 이용해 사이트 생성
4. 단, github.io의 경우 static으로 DB와 같은 서비스를 제공할 수 없다.
'Server Programming > BackEnd Project' 카테고리의 다른 글
| 4일차. TIL (0) | 2022.12.16 |
|---|---|
| 4일차. Git 관리 전략을 활용한 협업 (0) | 2022.12.15 |
| 2일차. TIL (0) | 2022.12.13 |
| 2일차. 버전 관리 툴 - Git (0) | 2022.12.13 |
| 1일차. TIL (0) | 2022.12.12 |
