Git & GitHub 활용하기

GitHub 활용법

1. CLI 방법 : Git Bash에서 command를 이용해 접근
2. GUI 방법 : LinkTree에서 접근

5. Branch

5-1. Branch란?

• 사용자가 독립적으로 작업을 진행할 수 있도록 돕는 작업 흐름, 독립적인 개발 라인
• 동일 브랜치에서 두 개의 새로운 커밋이 동일 커밋을 가리키면 오류가 난다. 그래서 이런 충돌을 방지하기 위해 브랜치를 파서 운영한다.
• 커밋은 이전 커밋을 가리키고 있다.

5-2. Master or Main

• Git이 제공하는 기본적인 브랜치의 이름이다.
• 기능에 따라 브랜치 이름 작명 해서 분화
• head : 내가 지금 현재 보고 있는 커밋

5-3. Git Branch 전략 예시 - git flow

• Master (Main)
  • 당장 배포해서 서비스 가능한 브랜치
• Develop
  • 개발 완료된 최신 브랜치
  • 신규 개발된 내역이 처음 합쳐지는 브랜치
• Feature
  • 기능 구현하는 부분만 개발하는 브랜치
• Release
  • Develop 브랜치에서 생성됨
  • 개발이 완료되어 출시를 위해 준비하는 브랜치
• Hotfix
  • 웹에 배포된 버전에서 발생한 버그를 수정하는 브랜치

💡

Git flow가 필요한 경우?

엄격한 버전 관리가 필요한 경우 다음과 같이 이중으로 관리

앱 어플리케이션, 오픈소스, IDE 등이 해당됨.

웹 같은 경우 제공된 도메인에 들어갔을 때 항상 최신 버전이 배포 되어있기 때문에, 버전 관리가 필요하지 않음. 그래서 웹 어플리케이션에 git flow 전략은 필요하지 않음

5-4. Git Branch 전략 예시 - github flow

💡

GitHub flow가 필요한 경우?

빠른 수정 빠른 배포가 필요한 경우 필요. 단일 브랜치를 사용하여 개발함. 내려받아서 버전을 계속 최신화시키면서 진행하는 것이 중요함.

• 빠르게 개발해서 배포하는 것이 목표
• pull이 중요

5-5. Branch를 만드는 규칙

• main 브랜치에는 직접 커밋을 올리지 않는다.
• 기능 개발을 하기 전에 master 브랜치를 기준으로 새로운 브랜치를 만든다.
•  
• 브랜치 이름은 feature/기능이름 형식으로 하고 한 명만 커밋을 올린다.
• feature/기능이름 브랜치에서 기능 개발이 끝나면 master 브랜치에 이를 합친다.

5-6. B 브랜치 가져와서 C브랜치 만드는 법

$ git branch -r : 기존 브랜치 확인하기
$ git checkout -b c b : b 리모트 브랜치를 c 로컬 브랜치로 가져오고, c 브랜치로 이동

... 작업 수행 ...

# 작업을 새 리모트 브랜치로 업데이트
$ git add newfile.txt
$ git commit -m 'test2 branch added'
$ git push origin c

6. Merge

6-1. Merge란?

merge : 두 버전의 합집합을 구하는 것, 세 가지 상황이 일어날 수 있다.

• 빨리 감기(fast-forward) : 단순히 main의 head만 최신 커밋으로 넘어감.
• 병합 커밋 : 분기가 일어나서 A, B에서 변경된 내용이 각각 다를 때, 둘을 병합하며 새로운 커밋이 만들어짐.
• 충돌 : 같은 파일에 대해 두 커밋 모두 변경이 일어났을 때, 어떤 부분을 살리고 어떤 부분을 죽일지 git 사용자가 직접 해당 내용을 소스코드에서 수정해야함.

6-2. 빨리 감기(Fast-forward)

• 단순히 main의 head만 최신 커밋으로 넘어감. 새 커밋이 생성되지 않음

6-3. 병합 커밋(Merge Commit)

• 분기가 일어나서 A, B에서 변경된 내용이 각각 다를 때, 둘을 병합하며 새로운 커밋이 만들어졌을 때 사용

6-4. 충돌(Conflict)

• 다른 브랜치에서 같은 파일에 수정을 진행했을 때.

6-5. Merge 실습

• merge를 chewon에서 진행했을 때 main이 chewon으로 merge됨

$ git merge [브랜치명]
$ git merge --abort
// 파일이 충돌났을 때, 충돌난 부분의 소스코드가 변경된다.
// 변경되기 이전의 소스코드를 확인하고 싶을 때, merge 이전으로 돌리고 싶을 때 사용.

7. Pull Request

작업 flow

1. main : 완성본
2. feature branch 생성
3. 소스코드 작성

3-1. 소스코드 add 및 commmit : commit message에 이슈 번호 등록 close #2

3-2. fetch origin main을 해서 main의 변경사항 확인

3-3. origin main을 해서 main의 변경사항 반영

3-4. push origin [브랜치명]을 해서 해당 브랜치의 변경사항 올림

1. pr 올림 : close #1
   1. 이슈 닫기

$ git branch -D "이름"
$ git checkout "이름"

소스코드 작성
$ git add .
$ git commit -m "@@ 풀이"

문제 하나 풀 때마다 한 번의 커밋

$ git pull origin "이름"

-----
github 페이지 가서
pull request "@일차 과제 제출"

8. Tag & Release

• Tag : 특정 커밋을 가리키는 참조 포인터로,

Tag를 통해 배포 버전을 간편하게 압축파일로 관리할 수 있다.

Release를 통해 배포 노트를 작성할 수 있다.