Git

Git이란

버전관리와 동시협업을 가능하게 해주는 툴

장점

• 지난 과정 확인 가능
• 이전 버전으로 돌아갈 수 있음

작업영역

working directory

작업을 하는 프로젝트 디렉토리
= working tree

staging area

git add를 한 파일들이 존재하는 영역
커밋을 하게되면 staging area 안에 있는 파일들만 커밋에 반영

repository

working directory의 변경 이력들이 저장되어 있는 영역
커밋들이 저장된 곳

working directory 에서 작업을 하고,
작업한 파일들을 git add 해준 뒤 커밋을 하면
staging area에 있던 파일들의 모습이 스냅샷처럼 이 repository 에 저장됨 !

커맨드 모음

git의 시작

git init
: 현재 디렉토리를 Git이 관리하는 프로젝트 디렉토리(=working directory)로 설정하고 그 안에 레포지토리(.git 디렉토리) 생성

git add 취소하기

git reset
: staging area 에서 파일 제거
한번 staging area에 올린 파일을 다시 내리는 커맨드
but 변경된 새 모습은 그대로 working directory 에 남아있음

변경사항을 한 번에 git add

git add.
: 온점(period)을 git add 뒤에 붙이면 변경사항이 있는 모든 파일들을 staging area에 올리라는 뜻

리모트 레퍼지토리(origin) 사용 이유

1. 안전성

2. 협업가능

로컬 레퍼지토리 >> 리모트 레퍼지토리

git push

: 로컬 레포지토리의 내용을 리모트 레퍼지토리에 반영

git _____ --set-upstream origin master

: 처음 보낼 때 ( 트래킹 정보 설정을 위해! )

리모트 레퍼지토리 >> 로컬 레퍼지토리

git pull
: 리모트 레퍼지토리의 내용을 로컬 레퍼지토리에 가져온 뒤 merge
" fetch + merge "

리모트 레퍼지토리가 더 최신 자료일 경우에 사용

• GitHub 페이지에서 직접 내용을 수정할 때
• 다른 사람이 그 리모트 레포지토리를 자신의 컴퓨터로 가져가서 수정한 다음 다시 리모트 레포지토리에 git push했을 때

git fetch
: 리모트 레퍼지토리의 내용을 로컬 레퍼지토리에 가져오기만 함

• 리모트 레퍼지토리에서 가져온 브랜치의 내용을 머지하기 전에 점검해야할 필요가 있을 때 사용

다른 프로젝트 가져오기

git clone

커밋 히스토리

git log

최근에 한 커밋
..
..
오래된 커밋

git log --pretty=oneline
: 커밋 히스토리를 더 깔끔하게 출력

git log --pretty=oneline --all
: 현재 내가 위치한 브랜치 뿐만 아니라 프로젝트의 모든 브랜치를 출력

git log --pretty=oneline --all --graph
: 커밋 히스토리를 각 브랜치와의 관계가 잘 드러나도록 그래프 형식으로 출력

git show [커밋 아이디 앞자리 4자리]
: 해당 커밋(+)과 이전의 커밋(-)의 차이점을 출력

커멘드 공식 메뉴얼

git help [알고 싶은 커멘드]
man git-[알고 싶은 커멘드]

코드 작성자 찾기

git blame [파일이름] : 어떤 파일의 특정 코드를 누가 작성했는지 찾아내는 커맨드

git show [궁금한 커밋의 아이디] : 어떤 파일의 특정 코드를 누가 작성했는지 찾아내는 커맨드

상태 (status)

: git status
git 이 현재 프로젝트에 관해서 인식하고 있는 프로젝트의 상태를 볼 수 있음

git 파일

• untracked 상태
  파일이 Git에 의해서 그 변동사항이 전혀 추적되고 있지 않는 상태
  파일을 새로 생성하고 그 파일을 한 번도 git add 하지 않은 상태

• tracked 상태

  (1) Staged 상태

  파일의 내용이 수정되고나서, staging area에 올라와있는 상태를 Staged(스테이징된, stage area에 올려진) 상태

  새로 생성한 파일에 내용을 쓰고 git add를 해주거나
  한 번이라도 커밋에 포함됐었던 파일이라도 내용을 수정하고 git add를 해주면 이 상태이다!

  (2) Unmodified 상태

  현재 파일의 내용이 최신 커밋의 모습과 비교했을 때 전혀 바뀐 게 없는 상태면 그 파일은 Unmodified(수정되지 않은, 변한 게 없는) 상태

  커밋을 하고 난 직후에는 working directory 안의 모든 파일들이 이 상태가 된다!

  (3) Modified 상태

  최신 커밋의 모습과 비교했을 때 조금이라도 바뀐 내용이 있는 상태면 그 파일은 Modified(수정된) 상태

  추가 설명
  img https://images.app.goo.gl/xpybUqd4zvBMHYTa6

Git Hub란

git 으로 관리하는 프로젝트를 올려둘 수 있는 사이트
** 외부의 컴퓨터를 대신 만들어주는 서비스 (원격 저장소의 역할)

레포지토리

: repository, 커밋 저장소 (버전 별 프로젝트, 변경사항 설명), .git

커밋

: commit
프로젝트 디렉토리의 특정 모습을 하나의 버전으로 남기는 행위 & 결과물

커밋하기 전 꼭 해야할 일

• 커밋하는 사람 정보 (이름, 이메일)
• 커밋에 대한 정보, -m옵션 (커밋 메세지)
• 커밋할 파일을 git add로 지정

$ git config user.name "rora"
$ git config user.email "iadorora@gmail.com"
$ git add Calculator.py
$ git add License
$ git commit -m "Create Calculator.py and License"

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

• 제목과 상세설명 사이는 한 줄 비워서 작성
• 제목 뒤에 온점 X
• 제목의 첫 번째 알파벳은 대문자
• 제목은 명령조
• 커밋의 상세내용
  ( 커밋한 이유, 어떤 문제 발생했는지, 적용한 해결책이 어떤 효과를 가지는지 )
• 최대한 친절하게 작성

-m 옵션 없이 커밋 메세지 남기기

git commit 만으로 텍스트 에디터에 커밋 메세지 입력 가능

= 복잡하고 긴 커밋 메세지를 쉽게 남길 수 있음

텍스트 에디터

:wq +enter : 저장 후 나가기

태그

중요한 커밋에는 커밋메세지 뿐만 아니라 태그도 달아둠

git tag [태그 이름] [커밋 아이디] : 태그 다는 법

git tag : 프로젝트 디렉토리에 있는 모든 태그 조회

git show [태그이름] : 각 태그와 연결된 커밋 조회

최신 커밋 수정하기

git commit --amend

: 커밋 횟수를 유지하면서 수정 가능

두 커밋 사이의 차이점 출력

git diff

옵션에 별명 붙이기

alias 별명
aliasing 별명을 붙이는 행위

git config alias.history 'log --pretty=oneline'
/*앞으로 git histroy라고만 써도 자동으로 git log --pretty=oneline을 실행*/

필요한 커밋만 가져오기

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

파일 무시

gitignore : working directory 안에 존재하기는 하지만 Git으로 버전 관리하고 싶지 않은 것들

Head

: 보통 가장 최근에 한 커밋을 가리킴 >> 매번 더 새로운 커밋을 가리킴!

head 가 가리키는 커밋에 따라 working directory 구성

브랜치를 통해 커밋을 간접적으로 가리키는 포인터

이전 커밋으로 git reset

git reset [옵션] [이전 커밋 id]
: 과거 커밋으로 아예 돌아가고 싶을 때

reset을 해도 그 이후의 커밋들이 아예 삭제되는 건 아님
reset 최신 커밋 아이디 로 되돌리기 가능!⭐

최신 커밋 아이디를 모른다면 .. .. ..

git reflog : reference log, 헤드가 지금까지 가리켜왔던 커밋들의 기록

이전 커밋 id 대신 사용할 수 있는 것

HEAD^ 현재 HEAD 가 가리키고 있는 커밋의 바로 이전 커밋
HEAD~X 현재 HEAD가 가리키고 있는 커밋의 X번째 전 커밋

git reset [ 옵션 ]

• --soft repository 만 reset
  head 가 과거의 특정 커밋을 가리키도록 함

• --mix repository, staging area 만 reset
  staging area 를 과거의 특정 커밋의 내용과 똑같이 reset

head는 이전 디렉토리를 가리키지만 working directory는 그대로!

• --hard repository, staging area, working directory 까지 셋 다 reset
  working directory 를 과거의 특정 커밋의 내용과 똑같이 reset

리모트 래퍼지토리에 올린 것 취소

git revert [작업을 되돌리고 싶은 커밋의 아이디]

git revert [A..B] : A~B 까지의 커밋을 취소할 때 사용 (A는 포함 x)

작업내용 임시저장

git stash : 안전한 곳에 보관하다,
working directory에서 작업하던 내용을 깃이 따로 보관

최근 커밋 이후로 작업했던 내용은 모두 stack에 옮겨지고
working directory 내부는 다시 최근의 커밋 상태로 초기화

여기서 보관하는 장소를 "stack" 이라고 함!

stack : 어떤 데이터를 저장하는 구조

git stash list : stack 에 저장된 리스트 출력

git stash apply : 스택에 있는 내용을 다시 working directory로 가져와서 적용 (가장 최근의 스택 적용, 이전의 스택을 적용하려면 id작성)

git stash drop [삭제할 작업내용 아이디] : stack에서 작업내용을 삭제

git stash pop [작업 내용의 아이디] : 작업내용을 적용함과 동시에 삭제⭐

branch

: 하나의 코드 관리 흐름

커밋을 가리키는 포인터

브랜치 커맨드

git branch [브랜치 이름] : 브랜치 생성

git checkout [이동할 브랜치 이름] : 브랜치 이동 후 작업을 한 뒤의 변경사항은 이동한 브랜치에만 적용됨!⭐

git checkout -b [브랜치 이름] : 브랜치 생성 후 해당 브랜치로 이동

git branch : 프로젝트의 모든 브랜치 조회
현재 내가 위치한 브랜치 옆에 * 표시 생성됨

git branch -d [브랜치 이름] : 브랜치 삭제

merge

: 헤드가 가리키던 커밋에 다른 브랜치가 가리키던 커밋을 합쳐서
새로운 커밋 을 만드는 작업

• fast-forward 머지

• 3-way 머지

git merge [합칠 브랜치 이름] : 현재 위치에 선택한 브랜치를 합침

git merge --abort : 머지 취소

merge commit

: 머지를 통해 생겨난 커밋

conflict 발생시

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

rebase

git rebase : 커밋을 재비치하다

merge vs rebase

• rebase는 새로운 커밋을 만들지 않는다.
• rebase로 만들어진 커밋 히스토리는 merge보다 더 깔끔하다.

rebase와 merge의 결과물은 같지만,
rebase를 사용하면 커밋 히스토리를 깔끔하게 관리할 수 있다.