Git & GitHub

git

git은 local에서 관리되는 버전 관리 시스템이며 소스코드 수정에 따른 버전 또한 관리를 해준다.

git은 형상 파일의 변화를 무엇이, 어디서, 누가, 몇번, 몇시에 변경 되는지 기록한다.

같은 파일에 대한 각기 다른 버전을 보관하며 같은 파일을 가지고 여러명이서 작업 가능한 장점이 있다.

git의 영역

git은 위 사진처럼 Work space, Staging area, Repository의 3가지 영역으로 파일들을 관리한다.

Work space : git이 추적 중인 파일들이 위치하는 영역
Staging area : commit할 준비가 된 파일들이 위치하는 영역
Repository : commit된 버전을 관리하는 파일들이 위치하는 영역

git의 상태

git은 위 사진처럼 Untracked, Unmodified, Modified, Staged의 4가지 상태로 분류된다.

Untracked : Work space에 존재는 하지만 git이 관리를 하지 않는 파일들의 상태
Unmodified : 기존에 commit 했던 파일을 수정하지 않은 상태
Modified : 기존에 commit 했던 파일을 수정한 상태
Staged : commit이 가능한 상태

git 명령어

init

init 명령어는 현재 디렉토리를 기준으로 git 저장소가 생성된다

git init

clone

clone 명령어는 특정 저장소를 내 로컬 디렉토리에 그대로 복사하는 것이다.

git clone Repository주소

status

status 명령어는 내 로컬의 staging area, untracked files 목록을 확인할 수 있다.

git status

add

add 명령어는 파일을 commit 할수 있는 상태로 만들어 준다.

git add 파일명
git add .

git add . 명령어는 staging area에 unstaged 상태인 모든 파일을 한번에 추가할 수 있는 명령어이다.

restore

restore 명령어는 commit 또는 staged 되지 않은 변경 사항을 폐기하는 명령어이다.

git restore --staged 파일명

commit

commit 명령어는 수정 작업이 끝났을 때 변경 사항을 저장하는 명령어이다.
또한 어떤 사항이 변경 됐는지 메세지를 통해서 버전의 변경 기록들을 관리 할 수 있다.

git commit -m "변경사항에대한메시지"

협업시 협업자들이 변경 사항에 대한 내용을 알아야 하므로 commit 메세지도 중요하다.
아래에서는 commit 메세지를 잘 작성하기 위한 7가지 스킬을 설명하겠다.

1. 공백 라인으로 본문과 주제를 구분
2. 제목줄은 50자 내외
3. 제목의 시작은 대문자로
4. 제목줄을 마침표로 끝내지 않기
5. 제목에 명령형 분위기 사용
6. 본문은 70자 내외로 줄바꿈 해주기
7. why와 how를 이용하여 본문에 설명하기

reset

reset 명령어는 local에서 commit한 내용을 취소할 때 사용한다.

git reset 옵션 돌아가고싶은커밋

옵션에는 hard, soft, mixed가 존재한다.

hard : 돌아가려는 이력 이후의 모든 내용을 지워 버린다.
soft : 돌아가려 했던 이력으로 되돌아 갔지만 이후의 변경된 내용이 지워지지 않고 해당 내용의 인덱스도 그대로 있다.
mixed : default 값으로 돌아가려 했던 이력으로 되돌아가고 이후의 변경된 내용이 지워지지 않고 해당 내용의 인덱스는 초기화 된다.

돌아가고 싶은 커밋을 직접 적어도 되지만 HEAD를 이용할 수도 있다.

HEAD는 현재 브랜치를 가리키는 포인터이며 브랜치는 브랜치에 담긴 커밋 중 가장 마지막 커밋을 가리킨다.
지금의 HEAD가 가라키는 커밋은 바로 다음 커밋의 부모가 된다.
단순하게 생각하면 HEAD는 현재 브랜치 마지막 커밋의 스냅샷이다.

HEAD^ : 가장 최근의 커밋이 취소된다.
HEAD~ : 가장 최근의 커밋 부터 ~뒤에 오는 숫자 만큼의 커밋이 취소된다.

log

log 명령어는 현재까지 commit된 로그들을 터미널 창에서 확인할 수 있는 명령어이다.

git log

pull

pull 명령어는 Remote Repository의 작업 내용을 그대로 가져오는 명령어이다.
가져오는 내용은 자동으로 merge(병합) 된다.

git pull remote branch
// remote와 branch에 대해서는 따로 설명하지 않는다

push

push 명령어는 로컬에서 변경, commit된 사항을 Remote Repository에 업로드 하는 명령어이다.

git push remote branch
// remote와 branch에 대해서는 따로 설명하지 않는다

remote add

remote add 명령어는 나의 Local Repository를 Remote Repository에 연결하거나 다른 사람의 Repository와 연결 할 수 있다.

// remote가 origin이라고 가정

git remote add origin Repository주소
// 나의 Local Repository를 Remote Repository에 연결 

git remote add origin Repository주소
// 다른 사람의 Repository와 연결 

remote -v

remote -v 명령어는 현재의 Local Repository와 연결된 모든 Remote Repository 목록을 확인 할 수 있다.

git remote -v

GitHub

GitHub는 버전 관리와 협업을 위한 코드 호스팅 플랫폼의 종류이며 현재 가장 많이 사용하는 플랫폼이며 클라우드 방식으로 관리되는 버전 시스템이다.

Fork

Fork는 다른 사람의 GitHub 저장소에 있는 히스토리를 그대로 나의 GitHub 원격 저장소에 복사하는 것이다.

Fork의 위치는 GitHub의 프로젝트 저장소에 오른쪽 상단 Fork탭이 존재한다.

Pull Request(PR)

Pull Request는 Remote Repository(원격 저장소)에 push해 놓은 변경사항에 대해서 함께 작업하는 다른 사람들에게 알리는 것을 말한다. 줄여서 PR이라고 많이 부른다.

PR의 위치는 GitHub의 프로젝트 저장소에 code탭 옆에 Pull requests라는 탭이 존재한다.

Merge conflict

pull 과정 중 merge 과정에서 충돌이 일어날 때가 있다.
충돌한 파일을 해결하기 위해 status명렁어로 충돌 파일을 체크하고 해당 파일을 터미널이나 vscdoe 같은 소스코드 편집기툴에서 열어보면 Accept Current Change, Accept Incoming Change, Accept Both Changes, Compare Changes 4개의 선택지가 상단에 나타난다.

Accept Current Change : 내가 수정한 내용으로 파일에 반영
Accept Incoming Change : Remote Repository의 내용으로 파일에 반영
Accept Both Changes : 변경 사항 모두를 파일에 반영
Compare Changes : 충돌한 파일을 각각 열어서 비교

수정을 마치면 반드시 add와 commit을 해주어 git으로 관리해주어야 한다.

upstream과 downstream

upstream과 downstream은 두개의 Repository간의 관계에 따라 정의되는 상대적인 개념이다.

예를들면 A, B Repository가 존재하고 A Repository로부터 B Repository로 pull을 해오고
B Repository에서 A Repository로 push를 한다고 하면 A Repository는 upstream이며 B Repository는 downstream이 된다.

upstream과 origin

가장 근본이 되는 Repository를 upstream이라고 부르고 내가 Fork해서 가져 온 Repository를 origin이라고 부른다.