Git

• 개인 개발을 넘어, 공동 개발에서 효율적인 코드 형상 관리를 하기 위함.

Git 영역

(1) Working Directory (Local)

• 개인 코드 작성

(2) Staging 영역

• git add 를 통해서 수정된 코드를 올리는 영역

(3) Repository (Repo)

• git commit,git push 을 통해서 최종 수정본을 제출

Git 작업 플로우

• 먼저 터미널에 git을 설치합니다.
• Linux (Ubuntu) 기준

$ sudo apt install git-all

(1) 저장소(Repository) 생성

• 자신의 프로젝트 폴더 위치로 이동한 후 실행
• 현재 디렉토리를 기준으로 Git 저장소가 생성 (.git)

$ git init

• 또는 기존 github에 있는 저장소를 내 로컬로 복제
  - 디폴트는 마스터 브랜치를 복제

  $ git clone (git 저장소의 URL)

• 브랜치를 지정해서 복제

  $ git clone -b (브랜치 이름) (git 저장소의 url)

(2) 코드 생성 (in Working directory)

• 이 예제에서는 README.md 라는 파일에 스트링 문자를 쓰는 코드를 만들겠습니다.

$ echo "Hello, Git!" > README.md

• 확인

$ cat README.md
Hello, Git!

(3) Staging 영역에 추가

• 코드 수정이 완료되면 staging 영역에 추가합니다.
• 현재 디렉토리에 있는 업데이트 된 파일을 전부 스테이징 영역으로 추가

$ git add .

• 또는 수정된 파일 전부를 스테이징 영역에 추가합니다.

$ git add -A

• 현재 add내역을 확인

$ git status

(4) Repository에 commit

• m 은 메세지의 약자이고, 뒤에 " "안에 공유할 메시지 내용을 적어주시면 됩니다.

$ git commit -m "feat: README.md update"

(5) 원격 저장소에 push, 업데이트 된 내용은 pull, fetch

• 나의 local 디렉토리로 부터 원격저장소(Remote repository)로 보내기 위해서는push 명령어를 사용합니다.

• 그 전에 원격 저장소와 내 로컬을 연결해야 합니다.

(6) 원격 저장소 연결 (github)

• origin은 remote repository의 이름이며, 다른 이름으로 설정해도 무방합니다.

$ git remote add origin (원격 저장소 github URL)

• push: 현재 프로젝트의 커밋된(HEAD) 내용을 원격 저장소로 내보내는 명령어
• origin이라는 원격저장소의 master 브랜치에 푸쉬

$ git push origin master

• pull: 원격 저장소에서 로컬 저장소로 소스를 가져오는 명령어
• 원격 저장소의 소스를 가져오고 해당 소스가 현재 내 소스보다 더 최신 버전이라고 하면 지금의 버전을 해당 소스에 자동으로 병합(merge) 즉, 원격 저장소와 내 로컬 저장소의 상태를 동일하게 만듭니다.

$ git pull origin master

• 충돌을 줄이기 위해 자주 pull하는 게 좋음 ⭐️
• fetch: 원격 저장소에서 로컬 저장소로 소스를 가져오는 명령어
• 원격 저장소의 소스를 가져오며 pull과 달리 병합은 하지 않습니다.

$ git fetch origin

⭐️ push, pull 작업 순서

1) pull로 당겨서 무조건 동기화
2) 작업 시작
3) commit
4) pull (내 작업 시간 동안 타인이 작업한 내용을 사전 동기화 시킴)
5) push로 내 작업 내용 올리기

(7) 한 브랜치에서 다른 브랜치로 병합하는 방법: merge, rebase

📍 merge

• 현재 dev라는 브랜치에서 작업 중이며 작업이 완료되어, master브랜치와 병합할려고 합니다.
• master브랜치로 체크아웃한 뒤 dev와 merge

$ git checkout master
$ git merge dev

📍 rebase: 어떤 특정 브랜치를 base로 커밋 이력을 재정렬

• 가장 자주 사용되는 경우는 커밋 이력을 깔끔하게 관리하는 경우에 사용할 수 있습니다.
• master 브랜치에서 다른 브랜치를 rebase하는 경우는 피하기
• 재정렬되는 commit 이력이기 때문에, 재정렬되는 commit 이력에는 이전과는 다른 새로운 해쉬 ID가 부여됩니다.
  (만약 master 브랜치에서 다른 브랜치를 기준으로 rebase을 실행하면, master의 커밋이력이 변함)
• Merge는 Merge commit 기록이 추가로 남게 되지만 Rebase의 경우에는 branch 병합 시 Merge commit 기록이 남지않아, 마치 하나의 브랜치에서 작업한 것처럼 보여집니다.

$ git checkout master
$ git rebase dev

그 외 알아두면 좋은 git 명령어

(1) 커밋 이력 확인

$ git log

• 커밋 이력 한 줄로 요약해서 보고싶은 경우

$ git log --oneline

(2) 파일변경시 (Working drectory → Staging) 내역 확인 및 취소

• 현재 디렉토리에 README.md 가 있다는 가정하에,이 파일에 다른 내용을 적어 업데이트하고, 무엇이 바뀌었는지 확인해봅니다.
• 파일 내용 변경

$ echo "update test" >> README.md

• 내용 변경 확인

$ cat README.md
 
Hello, Git! 
update test

• 변경 내용 확인

$ git diff

• staging 취소 (unstage)

$ git reset

• 또는 working directory 까지도 변경전 상태로 되돌림 즉, 변경한 내용이 소멸되므로 주의

$ git reset --hard

(3) commit 정리

• 여러개의 commit을 하나의 commit으로 정리

$ git rebase -i

• 직전과 금번 커밋을 하나로 정리

git commit --amend

Git Branch

• 프로젝트 진행 시, 중간에 에러가 발생한다면 이를 고쳐야합니다. 하지만 그와 동시에 지금 진행하고 있는 프로젝트에서 새로운 모듈을 개발해야 할 경우 위 두 코드는 독립적으로 수행되어야 합니다.

• 따라서 master (기본 브랜치) 외에 다른 브랜치가 하나더 필요합니다.

(1) branch 확인

• 현재 설정된 브랜치 앞에 * 가 붙습니다.

$ git branch

(2) branch 생성 및 변경

• 새로운 브랜치 mybranch를 생성

$ git branch mybranch

• 기존 브랜치(master)에서 새로운 브랜치(mybranch)로 전환합니다.

$ git checkout mybranch

• 따라서 바뀐 브랜치에서 commit을 하면, 원래 브랜치에는 업데이트가 안되고, 새로운 브랜치에서만 업데이트가 됩니다.
• push는 다음과 같이 진행하면 됩니다.
• origin이라는 원격저장소의 mybranch로 push합니다.

$ git push origin mybranch

Pull Request와 Merge

• commit을 한다고 최종 코드가 수정되는 것은 아닙니다.
• 개인이 commit을 했으면, 관리자가 이 코드를 리뷰하고 바꿀것이 있으면 수정해달라고 다시 요청해야하기 때문입니다. 그 과정을 알아봅니다.

1) Pull Request 발행 (Review 의뢰자)

• github에 접속 후, 원격저장소에 들어가서 해당 commit의 pull request 버튼을 누르면 Reviewer에게 풀리퀘스트 메시지 전송

2) Review & Comment (Review 수행자)

• 리뷰 후 comment 할 것이 있으면 comment 버튼 클릭

3) Comment 대응 (Review 수행자)

• local에서 코드 수정 후 원래와 같은 방식으로 commit 수행

$ git add .
 
$ git commit -m "커밋 메시지"

$ git push

4) Review 및 병합 (Review 수행자)

리뷰 후 최종 결과 만족 시 병합(merge) → github에서 pull request merge 버튼 클릭