[코드잇] Git으로 배우는 버전 관리 (완강)

수강일자

 

• 2022년 7월 27일 수요일 ~ 2022년 7월 29일 금요일 (3일)

 

수강후기

 

• 혼자서 이것저것 뚝딱 만들 때는 상관없는데 확실히 협업할 때 Git 중요성을 절실히 느낀다.
• 예전에 스파르타코딩클럽 Git 강의를 들었을 때는 소스트리 GUI 환경으로 해서 개념만 짚고 넘어갔었다.
• CLI 환경에서는 사실 push, pull, branch, merge 등만 사용했었다. (맨날 쓰던 것들)
• 이번에 원티드 프리온보딩에 참여하면서 Git flow가 꼬여있을 때 구글링이나 다른 팀원 분 도움으로 긴급처치는 했지만
• 제대로 된 개념을 익히지 않을 채로 적용하다 보니 따로 공부가 필요했다.
• 그래서 듣게 된 Git 강의였다. 총 강의 시간은 3시간 정도였는데, 정리하고 하다 보니 3일이나 걸렸다.
• 아마 주말에 들었다면 반나절만에 끝낼 수 있었을 듯하다.
• 확실히 Git을 실제로 써보고 강의를 들어보니 훨씬 이해가 잘됐다. Git의 흐름을 알 수 있었다.
• fetch, blame, reflog, cherry-pick은 프로젝트 하면서 한 번도 안 써봤는데, 나중에 실무에서 유용할 것 같다.
• 이제 Git 사용할 때 뚝딱거리지 말기~~

 

---

  토픽 1. Git  

  1-1. Git 시작하기  

 

01. Git이란?

 

• Git: 버전 관리, 동시 협업을 가능하게 해주는 툴
• 버전 관리: 파일의 변화를 시간에 따라서 기록했다가, 나중에 특정 시점에 버전을 꺼내올 수 있는 시스템.
• 버전관리 장점 1: 최종본을 만들기까지 어떤 과정을 거쳤는지 확인할 수 있음.
• 버전관리 장점 2: 잘못된 부분이 생기면 이전에 만든 버전의 과제로 돌아갈 수 있음.

 

02. [설명] Git의 역사

 

• Git 만든 사람: 리누스 토발즈(운영체제 리눅스 만든 사람)
• 리눅스 만든 뒤 BitKeeper이라는 툴로 버전 관리하다가 사이 안 좋아져서 버전관리 프로그램 하나 만듦.

 

03. GitHub란?

 

• 버전 관리, 동시협업툴
• 백업본 저장 가능: 작업 내용을 자신의 컴퓨터가 아니라 다른 곳에도 저장 가능하게 함.
• Git: 버전 관리하는 프로그램 (소프트웨어 자체)
• Github: Git으로 관리하는 프로젝트를 올려둘 수 있는 사이트
• 외부에 컴퓨터를 대신 만들어주는 서비스. 즉 원격 저장소를 대신 제공해주는 서비스임.
• 정리하면, Git으로 관리하는 프로젝트의 복사본을 저장하는 서버를 제공해주고,
• 협업을 위한 편의 기능을 제공해주는 서비스.

 

04. [설명] Git 설치하기(Mac 사용자)

 

• 패스

 

05. [설명] Git 설치하기(Window 사용자)

 

• 1. Git 홈페이지에서 'Download 2.26.1 for Windows' 버튼 클릭
• 2. Git 설치 프로그램 실행 후, Git Bash 항목에 체크 후 설치.

 

06. [설명] Sublime Text 설치하기(Mac 사용자)

 

• 패스

 

07. [설명] Sublime Text 설치하기(Window 사용자)

 

• 1. Sublime Text 설치 페이지에서 DOWNLOAD FOR WINDOWS 클릭
• 2. 설치 프로그램 실행

 

08. [퀴즈] Git 시작하기 퀴즈

 

• 통과~

---

  1-2. Git 써보기  

 

01. repository와 commit

 

• 프로젝트 디렉토리: 작업하는 디렉토리
• 레포지토리: 프로젝트 디렉토리 안의 .git 폴더 의미. 커밋이 저장되는 곳
• 커밋: 프로젝트 디렉토리의 특정 모습을 하나의 버전으로 남기는 행위, 결과물

 

02. repository 만들기

 

mkdir Mathtool # 프로젝트 디렉토리 생성
cd Mathtool/
git init # 레포지토리 생성
ls -al
cd .git
ls -al

 

03. 첫 commit 해보기

 

• 제일 첫 커밋은 제일 먼저 사용자 이름과 이메일을 등록해줘야 함.
• git config user.name "codeit"
• git config user.email "code@codeit.kr"
• git add .
• git commit -m "커밋메시지"

 

04. [설명] calculator.py 파일에 작성했던 코드 설명

 

• 패스~

 

05. [설명] Git의 3가지 작업 영역

 

1. working directory: 작업을 하는 프로젝트 디렉토리
2. staging area: git add 한 파일들이 존재하는 영역. 여기 파일들만 커밋에 반영됨.
3. repository: working directory의 변경 이력들이 저장되어 있는 영역. 스냅샷처럼 커밋들이 저장됨.

 

06. [퀴즈] Git 써보기 퀴즈 1

 

• working directory 안에 있는 .git 디렉토리가 repository임. 커밋이 저장되는 장소.

 

07. git add 더 자세히 알아보기

 

• git status: 깃이 인식하고 있는 프로젝트 디렉토리의 현재 상태를 보여줌
• 디렉토리 add 하면 디렉토리 안의 모든 파일이 스테이징 됨.

 

08. [설명] Git이 보는 파일의 4가지 상태

 

• Git 파일은 2가지 상태를 가진다: Untracked (git add X), Tracked
• Tracked 상태는 3가지 상태로 나눌 수 있음: Staged, Unmodified, Modified

 

09. git add 취소하기

 

• git reset [파일명]: staging area에서 파일 제거하기
• 변경된 새 모습은 그대로 working directory에 남아있음

 

10. [설명] 특정 git 커맨드의 사용법을 알고 싶다면?

 

• git help [알고 싶은 커맨드 이름]
• man git-[알고 싶은 커맨드 이름]

 

11. [퀴즈] Git 써보기 퀴즈 2

 

• git status: 현재 Git이 인식하고 있는 프로젝트 상태를 보여줌
• git reset [파일명]: staging area에서 내리기

 

12. [설명] Git 써보기 정리 노트

 

• git init: 현재 디렉토리를 Git이 관리하는 프로젝트 디렉토리(working directory)로 설정.
• 안에 레포지토리(.git 디렉토리) 생성
• git config user.name 'codeit': 현재 사용자 아이디를 'codeit'으로 설정 (커밋할 때 필요한 정보)
• git config user.email 'teacher@codeit.kr': 현재 사용자 이메일 주소를 'teacher@codeit.kr'로 설정
• git add [파일 이름]: 수정사항 있는 특정 파일을 staging area에 올리기
• git add [디렉토리]: 해당 디렉토리 내에서 수정사항이 있는 모든 파일들을 staging area에 올리기
• git add . : working directory 내의 수정사항이 있는 모든 파일들을 staging area에 올리기
• git reset [파일 이름]: staging area에 올렸던 파일 다시 내리기
• git status: Git이 현재 인식하고 있는 프로젝트 관련 내용들 출력
• git commit -m "커밋메시지": 현재 staging area에 있는 것들 커밋으로 남기기
• git help [커맨드 이름]: 사용법이 궁금한 Git 커맨드의 공식 매뉴얼 내용 출력

---

  1-3. GitHub 시작하기  

 

01. GitHub 계정과 Remote Repository 만들기

 

• 로컬 레포지토리에는 버전별 프로젝트 모습, 버전별 변경 내역이 담겨있음.
• 깃허브 회원가입 및 레포지토리 생성

 

02. Local Repository의 내용을 Remote Repository로..

 

• 로컬 레포지토리를 만들고 커밋한 후에 깃허브에 업로드 하기

git init
git add README.md
git commit -m "first commit"
git remote add origin [깃허브 레포 주소]
git push -u origin main

 

• 이미 생성된 로컬 레포지토리를 깃허브에 업로드 하기

git remote add origin [깃허브 레포 주소]
git push -u origin main

 

03. Local Repository에서 바뀐 내용을 Remote Repository

 

• git push: 로컬 레포지토리에서 변경된 내용을 리모트 레포에 반영함.

 

04. Remote Repository에서 바뀐 내용을

 

• git pull: 리모트 레포지토리에서 변경된 내용을 로컬 레포에 반영함.

 

05. [퀴즈] GitHub 퀴즈 1

 

• 로컬 레포지토리 내용을 처음으로 Github 리모트 레포로 보낼 때
• git push --set-upstream origin main
• 위 커맨드를 한번 실행하고 난 이후에 또 로컬 레포 내용을 Github 리모트 레포로 보낼 때
• git push

 

06. [설명] 아무나 git push를 할 수 있는 건 아닙니다.

 

• settings > manage access 에서 사용자 초대함
• 원칙적으로 자신의 리모트 레포지토리에는 자신만 git push 가능함
• 다른 사용자도 git push 할 수 있게 하려면 해당 리모트 레포지토리의 collaborator로 지정

 

07. 다른 프로젝트 가져오기

 

• git clone [깃허브 레포 주소]: 깃허브 프로젝트의 레포지토리를 그대로 복제함

 

08. [설명] 오픈 소스 프로젝트란?

 

• 오픈소스 프로젝트(open source project): 소스코드가 공개되어 있는 프로젝트
• 1983년 리차드 스톨만: 자유 소프트웨어재단 설립
• 소스 코드가 공개되고 누구나 코드를 자유롭게 가져다 사용하고 수정할 수 있어야 한다는 정신.
• 이어서 오픈소스 소프트웨어 명칭 제시됨.
• 오픈소스에도 여러 종류의 라이선스가 있어서 제약도 존재함.
• 오픈소스 라이센스 참고 링크

 

09. [설명] README.md를 더 예쁘게

 

• 마크다운: 간단한 텍스트만으로 어떤 표시를 해두면 자동으로 HTML 태그로 변환되도록 약속한 문법(.md)

 

10. [퀴즈] GitHub 퀴즈 2

 

• 통과~

 

11. [설명] GitHub 시작하기 정리 노트

 

• git push -u origin master: 로컬 레포지토리 내용을 처음으로 리모트 레포지토리에 올릴 때 사용.
• git push: 로컬 레포지토리의 내용을 리모트 레포지토리에 보내기
• git pull: 리모트 레포지토리의 내용을 로컬 레포지토리로 가져오기
• git clone [프로젝트의 Github 상 주소]: Github에 있는 프로젝트를 내 컴퓨터로 가져오기

---

  1-4. 커밋 다루기  

 

01. 커밋 히스토리 살펴보기

 

• 커밋 히스토리: 지금까지 한 커밋 기록
• git log: 커밋 히스토리 확인 가능
• 커밋 아이디 (=커밋 해시): 앞의 4자리 정도만 쳐줘도 확인 가능 (중복 있으면 안 됨)
• 커밋 히스토리 깔끔하게 보기: git log --pretty=oneline
• 커밋 히스토리 자세하게 보기: git show [커밋 아이디]

 

02. m 옵션 없이도 커밋 메시지를 남길 수 있어요

 

• git commit 만 입력하면 각 텍스터 에디터가 나와서 커밋메시지 길게 작성할 수 있음.
• 메시지 입력하고 상세 내용은 한 줄 엔터 치고 입력함.
• 다 작성했다면 저장은 esc 누르고 :wq + enter 입력하면 됨.

 

03. 최신 커밋 수정하기

 

• git commit --amend: 최신 커밋을 수정해서 다시 새로운 커밋으로 만들기

 

04. [설명] 커밋 생성, 커밋 메시지 작성 가이드라인

 

커밋 메시지 작성 가이드라인

 

• (1) 커밋메시지 제목(title)과 상세설명(body) 사이에는 한 줄 비워두기
• (2) 커밋메시지 제목 뒤에 온점(.) 붙이지 말기
• (3) 커밋메시지 제목 첫 번째 알파벳은 대문자로 작성하기
• (4) 커밋메시지 제목은 명령조로 작성하기 (예: Fix it (O), Fixed it (X))
• (5) 커밋메시지 상세 내용은 이런 내용이 들어가면 좋음.
• 예: 왜 커밋을 했는지, 어떤 문제가 있었고, 적용한 해결책이 어떤 효과를 가지는지
• (6) 다른 사람들이 자신의 코드를 바로 이해할 수 있다고 가정하지 말고 최대한 친절하게 작성하기

 

커밋할 때 알아야 할 가이드라인

 

• (1) 하나의 커밋에는 하나의 수정사항, 하나의 이슈를 해결한 내용만 남기기
• (2) 현재 프로젝트 디렉토리 상태가 내부 전체 코드 실행했을 대 에러 발생하지 않는 경우만 커밋하기

 

05. [설명] 긴 커맨드에 alias 설정하기

 

• Git에는 길이가 긴 커맨드 전체에 별명을 붙여서 사용할 수 있도록 하는 기능이 있음.
• 이때의 별명을 alias라고 하고, 별명 붙이는 행위를 aliasing이라고 함.
• git log --pretty=oneline → git history
• git config alias.history 'log --pretty=oneline'
• .gitconfig 파일 위치: Window에서는 C:\Users\사용자\.gitconfig

 

06. 두 커밋 간의 차이 보기

 

• git diff [이전 커밋 아이디] [이후 커밋 아이디]

 

07. [퀴즈] 커밋 퀴즈 1

 

• 통과~

 

08. HEAD의 의미

 

• HEAD: 보통 가장 최근에 한 커밋을 가리킴
• HEAD가 가리키는 커밋에 따라 working directory 구성됨.

 

09. 이전 커밋으로 git reset 하기

 

• git reset --hard [원하는 커밋아이디]: 원하는 곳으로 워킹디렉토리 상태가 변함
• HEAD가 과거의 커밋을 가리키게 할 수 있음
• working directory 내용도 과거 커밋 모습으로 돌아감
• 한 시점 이후의 커밋이 마음에 안 들 때 사용하면 된다.

 

10. [설명] git reset의 옵션을 배우기 전에 확실히 알아야 할 부분

 

• 1. git reset을 쓸 때 --hard는 뭐였을까?
• git reset에는 3가지 옵션이 있음 (--soft, --hard, --mixed)
• git reset에서 어느 옵션을 쓰든 HEAD가 과거 커밋을 가리키게 되는 결과는 동일함
• working directory 내부도 과거 커밋 모습처럼 변경되는 건 --hard 옵션을 사용했기 때문임.

 

• 2. staging area에 있던 것들은 커밋하고 나면 어떻게 될까?
• git add를 할 때마다 새로운 파일이 추가되거나, 원래 있던 파일이 새로운 버전으로 교체될 뿐임.
• staging area에 있던 것들은 커밋을 하더라도 그것과 상관없이 계속 남아있음. 이걸 기억하기!

 

11. git reset의 3가지 옵션 1

 

git reset [옵션] eea5	working directory	staging area	repository
--soft	안 바뀜	안 바뀜	HEAD가 eea5 커밋 가리킴
--mixed	안 바뀜	eea5 커밋처럼 변경	HEAD가 eea5 커밋 가리킴
--hard	eea5 커밋처럼 변경	eea5 커밋처럼 변경	HEAD가 eea5 커밋 가리킴

• --hard: 커밋 이후로 한 작업이 전부 사라짐. 권장되지 않음. (나중에 reflog로 복구될 수도)
• --mixed: 워킹 디렉토리가 가장 최근에 작업한 그대로임

 

12. git reset의 3가지 옵션 2

 

• 테스트 해봤음.
• 다시 복구하려면 git pull 하면 됨. (리모트 레포에서 받아온다.)

 

13. [설명] HEAD를 기준으로 git reset 하기

 

git reset [옵션] [커밋아이디]

 

• git reset [옵션] HEAD^ : HEAD가 가리키고 있는 커밋의 바로 이전 커밋 나타냄
• git reset [옵션] HEAD~2 : HEAD가 가리키고 있는 커밋보다 2단계 전 커밋 나타냄
• git reset [옵션] HEAD~x : HEAD가 가리키고 있는 커밋보다 x단계 전 커밋 나타냄

 

14. [설명] 커밋에 tag 달기

 

git tag [태그 이름] [커밋 아이디]

 

• 예시: git tag Version_1 84ab
• git tag : 프로젝트 디렉토리 내의 모든 태그 조회하기
• git show [태그 이름] : 각 태그와 연결된 커밋 조회하기
• 의미가 중요한 커밋들은 태그를 달아주면 나중에 프로젝트 이력 파악할 때 도움된다.

 

15. [퀴즈] 커밋 퀴즈 2

 

• 통과~

 

16. [설명] 커밋 다루기 정리 노트

 

• git log: 커밋 히스토리를 출력
• git log --pretty=oneline: --pretty 옵션을 쓰면 커밋 히스토리를 다양한 방식으로 출력
• git show [커밋 아이디]: 특정 커밋에서 어떤 변경사항이 있었는지 확인
• git commit --amend: 최신 커밋을 다시 수정해서 새로운 커밋으로 만듦
• git config alias.[별명] [커맨드]: 길이가 긴 커맨드에 별명 붙이기
• git diff [커밋 A 아이디] [커밋 B 아이디]: 두 커밋 간의 차이 비교
• git reset [옵션] [커밋 아이디]: 옵션에 따라 하는 작업이 달라짐
• (1) HEAD가 특정 커밋을 가리키도록 이동시킴 (--soft)
• (2) staging area도 특정 커밋처럼 리셋 (--mixed)
• (3) working directory도 특정 커밋처럼 리셋 (--hard)
• git tag [태그 이름] [커밋 아이디]: 특정 커밋에 태그 붙임

---

  1-5. 브랜치 사용하기  

 

01. 브랜치란?

 

• main: 레포지토리를 만들고 커밋을 하면 자동으로 생기는 기본 브랜치
• git branch [브랜치명]: 브랜치 생성하기
• git checkout [브랜치명]: 브랜치 이동하기

 

02. 브랜치 다뤄보기

 

• git branch: 모든 브랜치 조회하기
• git branch -d [브랜치명]: 브랜치 삭제하기
• git checkout -b [브랜치명]: 브랜치 만들고 바로 이동하기
• git switch [브랜치명]: 브랜치 이동하기

 

03. [퀴즈] 브랜치 퀴즈 1

 

• 통과~

 

04. 브랜치 merge 하기

 

• git merge [브랜치명]: 현재 있는 브랜치에 병합함
• merge commit 편집기에서 새로 입력할 수 있음.

 

05. merge 할 때 conflict가 날 수도 있어요!

 

Conflict 해결방법

 

• 1. 컨플릭트가 발생한 파일 열기
• 2. 머지 결과가 되었으면 하는 모습대로 코드 수정
• 3. 커밋

 

06. [설명] conflict가 났을 때 merge 자체를 취소해도 됩니다

 

• git merge --abort: 머지를 시도하기 이전의 상태로 돌아가려면 그냥 머지 자체를 취소함

 

07. [설명] 여러 파일에서 conflict가 났을 때는?

 

• 모든 파일의 conflict를 다 해결하고, git add . 커맨드로 한 번에 staging area에 올리고 커밋함.

 

08. [퀴즈] 브랜치 퀴즈 2

 

• 통과~

 

09. [설명] Remote Repository의 브랜치는 이렇게 보입니다!

 

(1) Origin 이란?

 

• git remote add origin [리모트 레포지토리 주소]: [리모트 레포지토리]를 origin이라는 이름으로 등록함

 

(2) Remote Repository에 있는 브랜치

 

• git push -u origin main: 현재 로컬 레포 main 브랜치의 내용을 origin 이라는 리모트 레포로 보낸다.
• 같은 이름의 브랜치로 전송하게 되는데, 만약 origin 리모트 레포에 main 브랜치 없으면 새로 생성하고 푸시.
• -u : --set-upstream 옵션의 약자. 로컬 레포의 main 브랜치가 origin main 브랜치를 tracking 하는 것으로 설정.
• tracking: 로컬 레포의 한 브랜치가 리모트 레포의 한 브랜치와 연결되어 계속 바라보는 상태라고 생각하면 됨.
• tracking connection이 한번 설정되면 자동으로 main 브랜치에 있을 때 main으로 git push, git pull 이 실행됨.
• 이 옵션 안 주면 나중에 git push origin main:main 이런 식으로 지정해야 함.

 

(3) origin / main 의 의미

 

• (main): 로컬 레포지토리의 main 브랜치
• (origin/main): 리모트 레포지토리의 main 브랜치

 

10. master 브랜치와 premium 브랜치 둘 다 push 하기

 

• git checkout premium
• git push --set-upstream origin premium
• 이렇게 하면 리모트 레포에도 premium 브랜치 생성됨

 

11. HEAD와 브랜치의 관계

 

• HEAD: 어떤 커밋 하나를 가리킴. 워킹 디렉토리 내용이 변경됨.
• branch: 코드를 관리하는 하나의 코드 흐름. 얘도 어떤 커밋을 가리키는 존재(포인터)라고 할 수 있음.
• HEAD는 직접적으로 커밋을 가리키는 게 아니라, 브랜치를 통해 가리킨다.
• Merge: 헤드가 가리키던 커밋에 다른 브랜치가 가리키던 커밋을 합쳐서 새로운 커밋을 만드는 작업

 

12. [설명] git reset의 비밀

 

• 사실 브랜치(branch)는 커밋을 가리키는 존재 (포인트)
• HEAD는 이런 브랜치를 통해 커밋을 간접적으로 가리키는 존재 (포인트)

 

git reset

 

• 1. HEAD는 여전히 같은 브랜치를 가리킴
• 2. HEAD가 가리키는 브랜치가 다른 특정 커밋을 가리킴
• 3. 이 때문에 결국 HEAD가 간접적으로 가리키던 커밋도 변경됨

 

git reset을 한다고 그 이후의 커밋이 사라지는 건 아닙니다.

 

• git reset은 꼭 과거의 커밋으로만 할 수 있는 것은 아님.
• 과거의 커밋으로 git reset를 한다고 그 이후가 커밋들이 삭제되는 게 절대 아님.
• 현재 HEAD가 가리키고 있는 커밋 이후의 커밋으로도 리셋할 수 있음.

 

13. [설명] git reset과 git checkout의 차이점(심화)

 

이전 노트의 내용(git reset) 복습

 

• HEAD는 보통 직접 커밋을 가리키는 게 아니라 브랜치를 통해 간접적으로 커밋을 가리킴

 

git checkout이 하는 일

 

• HEAD가 커밋을 직접적으로 가리키게 하기
• Detached HEAD: 브랜치를 통해서 커밋을 가리키는 게 아니라 본인이 직접 커밋을 가리키는 상태의 HEAD
• HEAD가 특정 커밋을 직접 가리키게 하는 이유: 과거의 특정 커밋에서 새로운 브랜치 만들 때
• git branch premium
• 1. 위의 명령어를 하면 premium이라는 브랜치가 새로 생성됨
• 2. premium 브랜치는 HEAD가 가리키던 커밋을 똑같이 가리킴

 

git checkout 커맨드

 

• 1. HEAD가 커밋을 직접적으로 가리키게 할 수 있음
• 2. 커밋 아이디나 브랜치 이름을 줘서 브랜치를 직접 가리키게 만들 수 있음
• git checkout premium 하게 되면 HEAD가 브랜치를 가리키게 됨

 

git checkout master

 

• = master 브랜치로 이동하가
• = HEAD가 master 브랜치를 가리키도록 하라
• = HEAD가 master 브랜치가 가리키던 커밋을 간접적으로 가리키게 됨으로써
• = working directory의 내부도 그 커밋에 맞게 변함으로써
• = master 브랜치로 이동한 것을 사용자는 실감하게 됨

 

git reset vs git checkout

 

git reset	git checkout
HEAD가 가리키던 브랜치가 다른 커밋을 가리키도록 함	HEAD 자체가 다른 커밋이나 브랜치를 가리키도록 함
HEAD도 결국 간접적으로 다른 커밋을 가리키게 되는 효과	브랜치를 통하지 않고,커밋을 직접적으로 가리키는 HEAD를 Detached HEAD라고 함

 

14. [설명] 새로운 커밋을 만들지 않는 merge도 있습니다(심화)

 

• 머지 커밋(merge commit): 머지를 통해 생겨난 커밋
• git merge premium
• 머지를 한다고 해서 항상 새로운 커밋이 생기는 것은 아님
• 머지에는 2가지 종류가 있음. Fast-forward, 3 way merge

 

Fast-forward 머지

 

• 커밋 히스토리에서 같은 선상에 있는 브랜치를 머지할 때 발생함

 

3-way-merge

 

• (1)번 : 두 갈래로 갈라지기 전 공통 조상이 되는 커밋
• (2)번 : 한 브랜치가 가리키는 커밋
• (3)번 : 다른 브랜치가 가리키는 커밋

 

• base에서 변화가 발생한 것을 우선 채택함
• 두 브랜치에서 둘 다 변화가 일어났을 때는 Conflict를 발생시켜 사용자가 스스로 선택하게 함

 

15. [퀴즈] 브랜치 퀴즈 3

 

• 통과~

 

16. [설명] 브랜치 정리 노트

 

• git branch [새 브랜치명] : 새로운 브랜치 생성
• git checkout -b [새 브랜치명] : 새로운 브랜치 생성하고 그 브랜치로 바로 이동
• git branch -d [기존 브랜치명] : 브랜치 삭제
• git checkout [기존 브랜치명] : 브랜치 이동
• git merge [기존 브랜치명] : 현재 브랜치에 다른 브랜치 머지
• git merge --abort : 머지하다가 conflict 발생했을 때, 일단 머지 작업 취소하고 이전 상태로 돌아감

---

  1-6. Git 협업하기  

 

01. [설명] 지금부터 배울 Git 실무 지식

 

• 앞으로 실제로 개발 환경에서 Git을 쓸 때 자주 만나는 상황과 그 상황에서 써야 할 커맨드를 배울 것임.

 

02. git push 전에 git pull을 해야 하는 경우가 많을 겁니다

 

• 로컬 레포지토리와 리모트 레포지토리 내용이 다를 경우에는 push 전에 git pull 부터 해야 함
• conflict 나면 수정하고 다시 커밋해준다.
• 리모트 레포지토리를 가져와서 로컬 레포지토리에 반영하는 것과 동일함
• 브랜치를 가져온다는 것은 브랜치가 가리키고 있는 커밋 이전에 이루어진 모든 커밋들을 가져온다는 의미

 

03. git pull 말고 git fetch도 있어요

 

• git fetch: 리모트 레포지토리에 있는 브랜치 내용을 일단 가져와서 살펴온 후에 머지하고 싶을 때 사용
• 리모트 레포지토리에서 가져온 브랜치 내용을 머지하기 전에 점검해야 할 필요가 있을 때 사용
• 또는 리모트 레포지토리에 있는 브랜치 내용과 내가 작성한 코드를 비교해서 잘못된 부분 검토할 때 사용
• git pull = git merge + git fetch
• git fetch
• git diff premium origin/premium
• git merge origin/premium

 

• 리모트 레포지토리 브랜치에 문제가 있을 때 해결방법
• 1. 잘못된 코드를 추가한 개발자에게 함수를 지우고 다시 리모트 레포지토리에 올려달라고 하기
• 2. 잘못된 부분을 알아서 해결하고 다시 git push 하기

 

04. 이 코드는 누가 작성했을까?

 

 

• git blame: 어떤 파일의 특정 코드를 누가 작성했는지 찾아내기 위한 커맨드
• 해당 파일 내용의 한줄한줄이 어떤 커밋에 의해 생겨났는지 알 수 있음
• 즉 어떤 커밋인지 안다는 것은 특정 코드를 누가 작성했는지도 알 수 있다는 것임
• git blame caculator.py
• git show [커밋아이디] : 작성자, 내용 확인 가능

 

05. 이미 Remote Repository에 올라간 커밋을 취소해야 한다면?

 

• git revert [돌리고 싶은 커밋아이디] : 내용 수정하고 다시 커밋, 푸시하면 된다. 
• 최신 커밋에서 한 작업을 되돌리고 다시 커밋을 해주는 커맨드임
• 로컬 레포지토리가 리모트 레포지토리보다 더 앞서있다면 push 해도 문제 X. (git reset이 어려운 이유)
• git revert 하면 Revert "커밋메시지" 이런 커밋이 새로 생긴다. (이전 상태를 가진 채로)

 

• git commit --amend : 커밋메시지만 수정
• git revert : 커밋을 수정하는 새로운 커밋 추가
• git reset : 이전 커밋으로 이동 (로컬 레포지토리에서만 작업한다면 이거 써도 괜찮음)

 

06. 여러 커밋 취소하기

 

• git revert [시작하는 커밋 아이디 이전]..[마지막 커밋 아이디] : 범위 지정해주고 push 하면 끝

 

07. [퀴즈] Git 실전 퀴즈 1

 

• 통과~

 

08. [설명] Git 협업하기 정리 노트

 

• git fetch : 로컬 레포에서 현재 HEAD가 가리키는 브랜치 업스트림 브랜치로부터 최신 커밋 가져옴
• (가져오기만 한다는 점에서 가져와서 머지까지 하는 git pull과는 차이가 있음)
• git blame : 특정 파일의 내용 한줄한줄이 어떤 커밋에 의해 생긴 것인지 출력
• git revert : 특정 커밋에서 이루어진 작업을 되돌리는(취소하는) 커밋을 새로 생성

---

  1-7. Git 자유자재로 활용하기  

 

01. git reset을 하고 나서 돌아오려면?

 

• reset을 해도 그 이후의 커밋들이 삭제되는 것은 아님
• git reflog : reference log의 줄임말. 헤드가 이때까지 가리켜왔던 커밋들의 id 확인하기
• HEAD 위치가 변경될 때마다 한 줄씩 생성됨
• 예시: git reset --hard HEAD@{1}

 

02. 커밋 히스토리를 보는 다양한 방법

 

• git log --pretty=oneline --all
• git log --pretty=oneline --all --graph

 

03. [설명] Git GUI 환경에서 사용할 수 있게 해주는 프로그램

 

• CLI(Command Line Interface) 환경에서 Git을 사용했음
• GUI(Graphic User Interface)
• 소스트리(Source Tree)

 

04. [퀴즈] Git 실전 퀴즈 2

 

• 통과~

 

05. 깔끔한 커밋 히스토리를 원할 땐 git merge 대신 git rebase

 

• 테스트 브랜치에 작성한 기능을 프리미엄 브랜치에도 추가하고 싶다면?
• 프리미엄 브랜치로 이동해서 git merge test 한 뒤에 커밋하면 됨 (A+B, 새로운 커밋 생성)
• 이 방법 외에도 git rebase를 통해 진행할 수 있음.
• 프리미엄 브랜치에서 git rebase test 하면 된다.
• 프리미엄 브랜치가 테스트 브랜치를 거쳐온 것처럼 커밋 히스토리 구조 자체가 변경됨
• git rebase test: 프리미엄 브랜치의 베이스를 테스트 브랜치로 재지정함
• git rebase --continue: conflict가 발생해서 제대로 진행되지 못한 리베이스를 계속 진행함

 

merge와 rebase 차이

 

• 1. rebase는 새로운 커밋을 만들지 않음
• 2. rebase로 만들어진 커밋 히스토리는 merge로 만들어진 커밋 히스토리보다 좀 더 깔끔함
• 사실 merge, rebase 결과물은 동일함
• 커밋 히스토리를 깔끔하게 만들기 위해 rebase를 사용하는 것임.
• merge: 두 브랜치를 합쳤다는 정보가 커밋 히스토리에 꼭 남아야 하는 경우 사용
• rebase: 커밋 히스토리를 깔끔하게 유지하는 게 더 중요한 경우 사용

 

06. 작업 내용 임시 저장하기

 

• git stash : working directory에서 작업하던 내용을 깃이 따로 보관함 (이때 보관하는 장소를 stack 이라고 함)
• stack : 어떤 데이터를 저장하는 구조
• 최근 커밋 이후 작업했던 내용은 모두 스택에 옮겨지고 working directory 내부는 다시 최근 커밋 상태로 초기화.
• 어떤 브랜치에서 작업을 아직 커밋하지 않았는데 다른 브랜치로 가야 하는 상황에서 작업 내용을 임시로 저장할 때.
• 로컬 레포지토리(.git)에서 관리됨. push를 통해 공유할 수 없음
• git stash list : stack에 있는 작업한 내용들을 확인할 수 있음
• git stash apply : 지금 stack에 있는 내용을 working directory로 가져와서 적용함.

 

07. 잘못된 브랜치에서 작업하고 있었다면?

 

• 프리미엄 브랜치에서 해야 했는데 마스터 브랜치에서 작업했었다면?
• git stash 로 저장한 다음, 프리미엄 브랜치로 넘어가서 git stash apply stash@{0} 적용함.
• git stash drop [작업 내용 아이디] : stash 쌓이지 않게 제거해준다.

 

08. [설명] 적용한 작업 내용은 스택에서 없애기

 

• git stash : 작업 내용 저장
• git stash list : 작업 내용 조회 (=스택 살펴보기)
• git stash apply [작업 내용의 아이디] : 작업 내용 적용 (작업내용을 나중에 또 쓸 일이 있다면 사용)
• git stash pop [작업 내용의 아이디] : 특정 작업 내용을 적용하면서 스택에서 제거 (나중에 쓸 일 없을 때)
• git stash drop : 가장 최근의 stash 삭제
• git stash drop [작업 내용의 아이디] : 작업 내용 제거
• git stash clear : 전체 삭제

 

09. [퀴즈] Git 실전 퀴즈 3

 

• 통과~

 

10. 필요한 커밋만 가져오는 git cherry-pick

 

• git cherry-pick [커밋 아이디] : 자신이 원하는 작업이 들어있는 커밋들만 가져와서 현재 브랜치에 추가

 

11. 여러 커밋을 하나의 커밋으로 만들기 (심화)

 

• 기능을 하나 추가했는데 보완된 더 좋은 기능이 생각났음. 그래서 커밋을 중복해서 하게 됨.
• 이럴 때 working direct 상태는 유지하고 git reset --soft [커밋 아이디] 함
• HEAD는 이전 커밋을 가리키지만 working directory는 그대로 유지하며 새롭게 하나의 커밋을 함.
• 이렇게 하면 쓸데없는 커밋들을 없앨 수 있음. git reset --mixed or --soft
• git commit --amend의 경우 마지막 커밋을 수정하는 상황에서 유용하게 사용됨.

 

12. [설명] git이 무시하는 파일들

 

.gitignore

 

• working directory 내에 존재하는 파일들 중에서 마치 존재하지 않는 것처럼
• Git이 인식해야 할 파일들의 목록이 적힌 파일임.

 

• *.py[cod] : .pyc / .pyo / .pyd로 끝나는 파일명
• *$py.class : $py.class로 끝나는 파일명
• *.so : .so로 끝나는 파일명

 

13. [퀴즈] Git 실전 퀴즈 3

 

• ㅇ

 

14. [설명] Git 토픽 내용 총정리

 

• git reflog : HEAD가 그동안 가리켜왔던 커밋들의 기록을 출력함
• git log --all --graph : 모든 브랜치의 커밋 히스토리를, 커밋 간의 관계가 잘 드러나도록 그래프 형식으로 출력
• git rebase [브랜치 이름] : A, B 브랜치가 있는 상태에서 HEAD가 A 브랜치 가리킬 때, git rebase B를 실행하면 공통 커밋 이후로부터 존재하는 A 브랜치 상의 커밋들이 그대로 B 브랜치의 최신 커밋 이후로 이어 붙여짐.
• (git merge와 같은 효과를 가지지만 커밋 히스토리가 한 줄로 깔끔하게 된다는 차이점이 있음)
• git stash : 현재 작업 내용을 스택 영역에 저장
• git stash apply [커밋 아이디] : 스택 영역에 저장된 가장 최근의 (혹은 특정) 작업 내용을 working directory 적용
• git stash drop [커밋 아이디] : 스택 영역에 저장된 가장 최근의 (혹은 특정) 작업 내용을 스택에서 삭제
• git stash pop [커밋 아이디] : 위와 동일한 작업 내용을 working directory에 적용하면서 스택에서 삭제
• git cherry-pick [커밋 아이디] : 특정 커밋의 내용을 현재 커밋에 반영
• git push, git pull은 작업 단위가 브랜치임. (git push --all 이라는 옵션을 주면 모든 브랜치 내용 전송은 가능)

---