CO:SSION Week2 - Git

Git 개념

git

• 버전 관리 시스템(VCS : version control system)
• 파일의 변화를 시간에 따라 기록하고, 나중에 특정 시점의 버전을 불러올 수 있는 시스템

git의 용도

• 이력 관리
  • 소프트웨어의 history를 남길 수 있음
  • 특정 시점의 작업 위치로 돌아갈 수 있음
• 협업
  • 다른 사람의 작업 내용을 확인할 수 있음
  • 여러 사람이 효율적으로 소프트웨어를 개발하도록 함

github

• 로컬 저장소
  • 내 PC에 파일이 저장되는 개인 전용 저장소
  • .git 파일
• 원격 저장소
  • 파일이 전용 서버에서 관리되며, 여러 사람이 함께 공유하기 위한 저장소
  • Github

CLI vs GUI

깃을 사용하는 두 가지 방법

• CLI(Command-Line Interface)
  • 키보드로 명령어를 입력하면서 사용하는 방법
• GUI(Graphical User Interface)
  • 아이콘, 버튼, 메뉴, 그래픽 요소를 통한 방법
  • 세부적인 명령은 GUI를 통해 내리기 힘듦

Git 시작하기

1. 프로젝트 디렉토리 경로로 이동
2. 사용자 이름과 이메일 정보 입력(git 처음 시작할 때만)
   • git config --global user.name "username"
   • git config --global user.email "user-email”
3. git init 명령어를 통해 현재 경로의 파일들을 git으로 관리하도록 지정
   • git init이 성공하면 현재 디렉토리에 로컬 저장소(.git 폴더)가 추가

Git과 Commit

Working Directory

• 사용자가 작업하는 공간 (디렉토리/폴더)

Staging area

• 로컬 저장소(Local Repository)에 이력을 저장하기 전에 거치는 중간 단계
• git add {폴더/파일 경로}
  • 저장하고 싶은 파일 변경 이력들을 working directory에서 staging area로 이동
• git commit
  • staging area의 이력들을 모아서 하나의 이력으로 로컬 저장소에 저장
  • git commit -m “commit message”

• git status
  • working directory에서 이전 commit과 달라진 파일의 이름을 확인
  • staging area에 담기지 않은 파일의 이름은 빨간색으로 칠해짐
  • git add 명령어로 staging area로 파일을 이동하면 초록색으로 칠해짐
• git log
  • 커밋 ID, 커밋한 사람(Author), 날짜, 커밋 메시지 확인 가능

git에서의 파일 상태

1. Working Directory에서 파일을 수정
2. Staging Area에 파일을 stage해서 commint할 스냅샷을 생성
3. Staging Area에 있는 파일들을 commit해서 git 디렉터리에 영구적인 스냅샷으로 저장

파일의 라이프 사이클

HEAD

• 현재 보고 있는 commit의 포인터
• 커밋을 하면, HEAD의 위치에서 새로운 이력이 생성되고 HEAD가 이동한다

커밋은 언제 해야할까?

• 커밋의 범위는 최소 작업 단위로 한다
  • 커밋의 기본 원칙은 1 Action 1 Commit
  • 나중에 특정 이력으로 쉽게 되돌아가도록 하기 위함
• 커밋 메시지 한 줄로 설명할 수 있는 행동을 단위로 한다
  • 커밋 메시지만 보고, 어떤 파일이 변경되었는지 추측하기 쉬워야 한다
    • e.g. “CSS 수정” → “footer의 font-dize 12px로 수정”
  • 하나의 Action만이 커밋 메시지에 드러나도록 커밋을 쪼개야 한다
    • e.g. “랜딩 페이지의 HTML 및 CSS 작성” → 여러 개의 커밋으로 분리

Commit Message Convention

• 팀원들 간의 협업을 원활하게 관리하기 위하여 팀끼리 정하는 커밋 메시지 규칙

커밋 취소하기 (reset)

 

• 로컬 저장소에서 작업하던 도중 이전에 커밋한 코드에 에러가 있는 것을 발견한 상황
• 다른 사람들과 협업하는 상황, 특히 에러가 발생한 커밋이 Github에 올라가있는 상황에는 절대 사용하면 안됨

우리가 원하는 해결법

1. 에러가 발생한 커밋을 수정

Git이 제공하는 해결법

1. 에러가 발생하기 이전까지 커밋을 되돌리기

• git reset --soft HEAD~n

• git reset --hard HEAD~n
• git reset HEAD ~n
  • HEAD 위치에서 n번째 이전 커밋으로 이동한다
  • 기존의 커밋이 사라진 게 아니라 보이지 않는 것!
• git reset --soft
  • Working Directory와 Staging Area에 존재하는 파일 변경 내역(uncommitted changes)을 유지한다
• git reset --hard
  • Working Directory와 Staging Area에 존재하는 파일 변경 내역 모두 손실 (uncommitted changes)이 된다
  • 손실된 uncommitted changes는 되돌릴 수 없기 때문에 사용에 주의할 것

1. 에러를 해결한 커밋 생성
2. 에러 이후에 커밋한 이력들도 다시 생성

커밋 취소하기(reset)의 문제점

• 에러가 발생한 커밋이 Github(원격 저장소)에 이미 올라가 있는 경우 커밋 취소(reset)로 로컬 저장소의 커밋 내역을 바꾸면 원격 저장소와 커밋 내역이 틀어져서 문제 발생

1. 로컬에서 원격으로 커밋 내역 올라가지 않음(push 불가)
2. 원격에서 로컬롤 커밋 내역 내려받지 못함(pull 불가)
3. 만약에 팀원 A가 5번 커밋부터 작업한 내용이 있는 경우 push가 성공하면 A의 작업 내용이 전부 소실됨

커밋 되돌리기 (revert)

• git revert 명령어는 특정 커밋으로 되돌아간 후에 되돌아 갔다는 커밋을 생성한다

자주 쓰는 명령어

• Staging area에 추가
  • git add {파일/폴더 경로}
  • git add {파일/폴더 경로} {파일/폴더 경로}
  • git add .
• Staging area에서 삭제
  • git restore {파일/폴더 경로}
• 새로운 커밋 생성
  • git commit -m “commit message”
• 마지막 커밋 수정하기
  • git commit --amend
• 개발 이력을 로그로 확인하기
  • git log
    • 자세한 로그
    • 커밋 아이디가 길게 나옴
  • git log --oneline
    • 간략한 로그
    • 아이디가 짧게 나옴 (6자리)
  • git show {커밋 ID}
    • 특정 커밋의 상세 정보 (브랜치 지정 가능)
  • git reflog
    • HEAD가 가리켰던(ref) 커밋의 이력(log)를 보여줌
  • git reflog {브랜치명}
    • 브랜치별로 reflog를 보여줌
• 커밋 취소하기
  • git reset HEAD ~n
    • HEAD 위치에서 n번째 이전 커밋으로 이동한다
    • 기존의 커밋이 사라진 게 아니라 보이지 않는 것!
  • git reset --soft
    • Working Directory와 Staging Area에 존재하는 파일 변경 내역(uncommitted changes)을 유지한다
  • git reset --hard
    • Working Directory와 Staging Area에 존재하는 파일 변경 내역 모두 손실 (uncommitted changes)이 된다
    • 손실된 uncommitted changes는 되돌릴 수 없기 때문에 사용에 주의할 것

Git과 Branch

브랜치 (Branch)

• 분기점
• 커밋을 가리키는 포인터
• 기본적으로 main 브랜치 제공

HEAD vs Branch

• HEAD는 브랜치가 아님
• HEAD : 현재 바라보고 있는 커밋을 가리키는 포인터
• 브랜치 : 커밋을 가리키는 포인터

브랜치 관련 명령

• 새 브랜치 생성
  • git branch {브랜치명}
  • 어떠한 기능을 개발하기 위해 브랜치를 따로 생성
• 특정 브랜치로 이동
  • git checkout {브랜치명}
  • HEAD의 위치를 {브랜치명}으로 이동
• 브랜치에서 새 커밋 생성
  • 커밋은 HEAD 위치에서 생성
  • HEAD와 브랜치가 함께 생성된 커밋 위치로 이동
• 브랜치 병합(merge)
  • git merge {브랜치명}
  • 두 브랜치가 가지고 있는 커밋을 합치는 작업
  • git checkout main → git merge dev 를 하면, main 브랜치의 현재 커밋에 dev 브랜치를 합침

merge conflict

 

• 합치려는 두 커밋에서 서로 같은 부분을 변경한 경우 충돌(conflict) 발생
• 둘 중 어느 코드를 적용해야 할 지 몰라서 충돌 발생
• 충돌이 발생한 부분을 고쳐서 커밋해야 merge 가능

Github 협업 전략

Push

• git push origin {원격 브랜치명}
• 로컬 저장소의 변경 사항을 원격 저장소로 전송하는 작업
• 다른 팀원들과 원격 저장소(e.g. github)에서 변경 사항을 공유

Pull

• git pull origin {원격 브랜치명}
• 원격 저장소의 변경 사항을 로컬 저장소로 가져오는 작업
• 다른 팀원들이 push한 변경 사항을 로컬 저장소에 merge

브랜치 전략 (Branch Strategy)

• 여러 개발자가 하나의 저장소를 사용하는 환경에서 저장소를 효과적으로 활용하기 위한 work-flow
• 브랜치 생성에 규칙을 만들어서 협업을 유연하게 하는 방법론

Git Flow 전략

 

• main(master)
  • 제품으로 출시될 수 있는 브랜치
• develop
  • 다음 출시 버전을 대비하여 개발하는 브랜치
• feature
  • 기능을 개발하는 브랜치
• release
  • 이번 출시 버전을 준비하는 브랜치
• hotfix
  • main 브랜치에서 발생한 버그를 수정하는 브랜치

초기 상태

• 초기에는 main(master) 브랜치와 develop 브랜치 존재
• develop 브랜치에서는 상시로 버그를 수정한 커밋 추가 가능

feature 브랜치

• 새로운 기능 추가 작업이 있는 경우, develop 브랜치에서 feature 브랜치를 생성
• 기능 추가 작업이 완료되었다면 feature 브랜치는 develop 브랜치로 병합(merge)

release 브랜치

• develop에 이번 버전에 포함되는 모든 기능이 merge 되었다면 QA를 하기 위해 develop 브랜치에서 release 브랜치 생성
• QA를 진행하면서 발견한 버그들은 release 브랜치에서 수정

배포

• QA를 무사히 통과했다면 release 브랜치를 main과 develop 브랜치로 병합(merge)
• 출시된 main 브랜치에 버전 태그 추가

hotfix 브랜치

• main 브랜치에서 긴급하게 수정해야 할 버그가 발견된 경우에 hotfix 브랜치 생성
• 버그 수정 후 main과 develop 브랜치에 병합(merge)

Issues (Github)

 

• Github에서 프로젝트의 작업, 개선 사항 및 버그 등등을 작성하는 일종의 게시판
• 이슈에는 고유 번호가 붙음 (e.g. #1)
• Settings > General > Features > Issues > Set up templates 에서 이슈 템플릿 작성 가능

Pull Request(PR)

• 내가 작업한 내용을 특정 브랜치에 적용해주기를 요청(Request)하는 것
• 다른 팀원들이 내 커밋 기록과 코드를 리뷰하고 피드백을 남길 수 있음
• 문제가 없다면 해당 브랜치에 병합(merge)

PR에 들어가면 좋은 내용

• close #이슈번호
  • 특정 이슈에 대한 PR인 경우, 해당 이슈를 자동으로 완료시킴
• 무슨 이유로 어떻게 코드를 변경했는지
• 어떤 부분에 리뷰어가 집중해야 하는지
• 어떤 어려움이 있었고 어떻게 해결했는지
• 관련 스크린샷
• 참고자료

Pull Request Template

1. Add file > Create new file
2. .github 폴더 아래에 pull_request_template.md 파일 추가

Github Flow 전략

초기 상태

• 초기에는 main(master) 브랜치 존재

브랜치 생성

• 새로운 기능 추가 작업이 있는 경우, main 브랜치에서 feature 브랜치를 생성
• 체계적인 분류 없이 브랜치 하나에 의존하기 때문에, 의도를 명확하게 드러내는 브랜치 이름을 사용해야 한다.
• 혹은 Github의 Issues를 사용하여, 브랜치 이름에 이슈 번호를 넣을 수 있다. (e.g. feat/#1)

Pull Request 생성

• 기능 추가 작업이 완료되었다면 Github에서 Pull Request(PR)를 생성

리뷰 및 피드백

• 다른 개발자들이 PR을 통해 코드를 검토하고 피드백을 제공

QA

• QA를 하기 위해 테스트 환경에 feature 브랜치를 배포
• 배포 도중 버그가 발생한다면 테스트 환경에 main 브랜치 내용을 다시 배포하고, feature 브랜치에서 버그를 수정