Workflow

• work space : 내 컴퓨터의 작업 공간
• staging area : 작업에 들어간 파일들을 git의 관리 하에 있는 상태로 올려주는 영역으로 staging area에 들어온 파일들은 commit이 가능
  - staging area에 있는 파일 : staged 된 파일
  - staging area에 들어오지 않은 파일 : unstaged or untracked file
  

1. 혼자 작업할 때의 workflow

• Remote에 있는 다른 Repository에서 Fork를 해서 Remote에 있는 내 Repository에 가져옴
• 코드를 수정하기 위해서는 clone하여 내 컴퓨터로 가져옴
• work space에서 작업한 파일들을 staging area에 올려줌
• staging area에 들어온 파일들을 commit
• commit 후 내 remote repository에 push해서 commit기록을 remote에도 남겨줌
• push 완료 후 remote의 원래 레파지토리에 pull request를 보내 Remote Repository로 내가 수정한 코드를 업로드

1) git clone

git clone URL

• url : 다른 사람의 Remote Repository에서 Fork한 나의 Remote Repository 주소

2) git status

git status

• staging area와 untracked files 목록에 어떤 것들이 있는지 확인하여 현재 Local Repository에서의 변경 파일 확인
• 변경된 상태 : modified
• Changes to be committed : staged 파일
• Changeds not staged for commit : modified된 unstaged 파일

3) git restore

git restore 파일명

• commit되지 않은 Local Repository의 변경사항을 폐기(discard changes)하는 명령어로 처음 Clone을 받았던 상태로 되돌려줌

4) git add

git add 파일명

• 내 local의 untracked files을 git의 관리 하에 있는 staging area로 추가하여 commit 할 수 있는 상태로 만들어 줌
• staging area에 unstaged 상태인 모든 파일을 한번에 추가하게 되므로 주의
• add 명령어를 통해 tracked area에 들어간 파일을 수정하게 되면 다시 modified 상태가 되기 때문에 다시 add를 통한 staged 작업이 필요

5) git commit

git commit -m '변경사항에대한 코멘트'

• work space에서 발생한 변경사항을 Local Repository에 commit
• -m : commit 메시지를 작성할 때 사용하는 옵션
• Commit 기록 : 날짜, commit한 사람, commit 메시지
• 수정한 파일을 commit하기 위해서는 staged area에 add하는 작업이 필요
• commit 메시지 작성 요령

6) git reset

git reset HEAD^
*가장 최신의 commit을 취소

• Remote Repository에 업로드 되지 않고 Local Repository에만 commit 해 놓은 기록은 reset 명령어를 통해서 commit을 취소할 수 있음
• HEAD : 연속된 ^의 shortcut으로 HEAD3은 HEAD^^^
  *^ : 커밋 개수
• git reset --mixed(default): commit된 파일들을 add 하기 전 상태(work space)로 돌려놓음
• git reset --hard : commit된 파일들 중 tracked 파일들을 work space에서 삭제
• git reset --soft : commit된 파일들을 staging area로 돌려놓음

7) git push

git push 저장소명 브랜치명
git push origin master
git push origin main

• Pull Request를 하기 위해 Local Repository에 저장되어 있는 commit 기록들을 내 Remote Repository에 업로드 해줌
  *commit 기록을 남긴 후 이 파일들을 contribute하기 위해 Pull Request 필요
• 저장소명 : git clone을 했다면 일반적으로 origin
  *git remote 명령어를 통해서 정확한 저장소명을 알아낼 수 있음
• 브랜치명 : master는 최초 생성하는 기본 브랜치로 사용하는 이름으로 master에서 main으로 변경 가능

master에서 main으로 변경하기

1. git branch -m master main
   *원격 저장소의 브랜치 이름 변경(git status로 확인 가능)
2. git push -u origin main
   *현재 로컬 HEAD 분기가 여전히 기본인지 확인
3. git push origin --delete master
   *이전 "마스터"분기를 제거
4. 에러 발생시 github에서 defalt branch 변경 필요 문서 참고

8) git log

git log

• 남긴 commit들이 잘 기록되었는지 확인할 수 있는 명령어
• 현재까지 commit된 로그들을 터미널 창에서 확인후 q를 입력해 창을 종료

9) Pull Request

• Remote Repository에 Push한 변경 사항에 대해서 함께 작업하는 다른 사람들에게 알리는 것으로 PR이라고도 함
• Remote Repository에 Push -> GitHub 웹사이트 상의 해당 Remote Repository에 Compare & pull request 버튼 클릭 -> Push해 놓은 내용을 간단하게 요약 후 Pull Request
• 여러 동료들의 리뷰도 받을 수 있고 내가 올린 작업을 기존 코드에 병합할 수 있음

2. 함께 작업할 때의 workflow

• 내 컴퓨터에서 생성한 디렉토리를 init 명령어를 통해 Git의 관리 하에 들어가게 함
• 내 컴퓨터의 Git 디렉토리를 Remote Repository와 연결
• pair의 변경 사항과 나의 변경 사항을 Remote Repository를 통해서 공유

1) git init

git init

• 내가 직접 만든 디렉토리를 Git의 관리 하에 들어가게 만들어 주는 명령어
• 기존 프로젝트를 Git Repository로 변환하거나 새로운 Repository를 초기화하는 데에 사용
• 이는 Local Repository가 생성되는 것을 의미

2) git remote add (1)

git remote add origin 내-Repository-주소

• Local Repository를 Remote Repository와 연결
• 변환한 Local Repository를 Github에서 원격으로도 관리할 수 있게 해줌
• 내 Github에 Repository를 하나 만들고 그 Repository 주소를 git remote add origin 명령어 뒤에 입력

3) git remote add (2)

git remote add pair 상대방-Repository-주소

• 다른 사람의 Repository와 연결하여 Github Repository를 함께 공유
• 상대방의 Repository의 이름이 pair일 때 git remote add pair 뒤에 상대방의 Repository 주소를 입력

4) git remote -v

git remote -v

• 현재의 Local Repository와 연결된 모든 Remote Repository 목록을 확인

5) git pull

git pull pair master

• git push 저장소명 브랜치명

• 저장소명 : 상대방의 Repository의 이름

• 페어가 작업을 완료한 후 Repository의 master 브랜치에 작업한 코드를 올려 놓으면 git pull pair master 명령어를 통해 페어의 Remote Repository에 있는 작업 내용을 받아옴

• 받아오는 내용은 자동으로 병합(merge)

6) git status

git status

• 페어의 작업 내용을 받아오는 도중 내게 동일한 라인을 수정한 파일이 있을 경우 자동 병합에 실패하게 되고 충돌이 발생시 git status를 통해 어떤 파일이 충돌하고 있는지 확인
• 충돌이 일어난 부분은 하나 하나 직접 확인 후 수정이 필요
• Accept Current Change 클릭 : 내가 수정한 내용으로 파일에 반영
• Accept Incoming Change 클릭 : Remote Repository의 내용으로 파일에 반영
• Accept Both Changes : 변경 사항 모두를 반영

7) git add

git add 파일명

• 수정을 마치면 병합 커밋(merge commit)을 생성해 주기 위해서 파일을 staging area로 추가

8) git commit

git commit

• Merge commit은 자동으로 Commit 메시지가 생성
• 메시지를 입력 및 수정할 수도 있음

9) git push

git push origin master

• Merge branch ‘master’ of 라는 commit 메시지가 기록되며 push 완료

3. 브랜치를 이용한 workflow

1) git clone

git clone URL

• 각자의 Remote Repository로 Fork한 후 Local에서 작업하기 위해서 git clone 명령어로 Repository를 Local에 가지고 옴

2) git switch -c dev

git switch -c 새로운-브랜치-이름
git checkout -b 새로운-브랜치-이름

• 기본적으로 개발을 진행하는 과정에서는 main 브랜치가 아닌 dev 브랜치를 하나 만들어서 작업을 하는 경우가 많음
• dev 브랜치를 만들어서 해당 브랜치로 이동

3) git push

git push origin dev

• Remote Repository에도 생성한 브랜치를 반영하기 위해서는 git push origin dev 명령어를 입력해 주어야 함

4) git branch

git branch

• 생성한 브랜치의 목록과 내가 현재 dev 브랜치에 있는 것이 맞는지 확인 가능
• q를 눌러서 종료

5) git switch -c feature

git switch -c 피쳐/기능
git switch -c feature/login

6) git merge

git switch 피쳐/기능
git merge 피쳐/기능
*merge하기 위해서는 먼저 병합이 될 브랜치로 이동을 해야 함

• 소셜 로그인(oauth) 기능을 추가를 위해 만든 feature/login-oauth 브랜치를 feature/login 브랜치에 병합
• feature/login-oauth 코드를 feature/login에 병합하려면 git switch feature/login 명령어를 통해 feature/login 브랜치로 이동
• git merge feature/login-oauth 명령어를 통해 feature/login 브랜치로 병합
• 브랜치가 머지되기 전 feature/login 브랜치에 추가적인 커밋이 없으면 브랜치가 분기될 필요가 없으므로 자동적으로 fast-forward 방식으로 병합이 이루이점
  *별도의 커밋을 생성하지 않고 feature/login 브랜치가 가리키는 커밋을 feature/login-oauth가 생성한 커밋으로 바꾸는 작업
• feature/login 브랜치에 별도의 커밋이 있었다면 merge-commit 방식으로 병합

fast-forward 방식

merge-commit 방식

7) git rebase

git rebase 브랜치-이름 피쳐-브랜치-이름

• feature/login 브랜치에서 git rebase main feature/login 명령어를 입력하면 main의 가장 최신 커밋으로 브랜치가 가리키는 곳이 변경
  *main의 다른 커밋에서 충돌이 없을 경우에 해당

merge VS rebase

1. merge : 변경 내용의 이력이 모두 그대로 남아 있기 때문에 이력이 복잡해 집니다.
2. rebase : 말 그대로 branch base를 이동시킨다는 뜻으로, merge처럼 브랜치 통합을 목적으로 하지만 특정 시점으로 브랜치가 가리키는 곳을 변경하는 기능을 수행
   

8) git push

git push origin feature/login

• 로컬의 작업한 내용을 Remote Repository에 업로드하기 위해 push
• feature/login 브랜치의 변경 사항을 다른 팀원들과 함께 코드 리뷰를 하고 dev 브랜치에 적용
• Github의 Pull Request 기능을 활용해 dev 브랜치로의 반영을 요청
• 리뷰가 끝난 코드는 브라우저에서도 dev 브랜치로 merge
• PR 내용을 입력한 후 Create pull request 버튼을 클릭