본 세션은 깃과 깃허브를 처음 들어보시는 분, 써보긴 써봤지만 아무것도 모르고 사용하고 계시는 분, 이제는 나도 깃 좀 알아야겠다 하시는 분을 대상으로 구성되었습니다
Prerequisites
Introduction
기본 개념 빠르게 살펴보기
•
레포지토리(repository) : 스테이지에 대기하고 있던 파일들을 버전으로 만들어 저장하는 곳. 커밋을 모아서 저장하는 곳.
•
커밋(commit) : 프로젝트 디렉토리의 특정 모습을 하나의 버전으로 남기는 행위 & 결과물
Quick Start : git init, add, commit
혹시 본인의 잔디가 까~~맣게 변하는 것을 원치 않는 분들은 아직은 눈으로만 봐주셔도 됩니다!! (저도 그러고 싶지 않았어요…)
다만 출석 과제가 있으니 ‘git clone’ 부터는 집중해주세요!
)
다만 출석 과제가 있으니 ‘git clone’ 부터는 집중해주세요!실습 폴더 만들기 : 실습을 위해 원하는 위치에 hello-git 폴더를 하나 만들어주세요!
mkdir hello-git
cd hello-git
Bash
복사
git repository(.git) 만들기
•
git init 을 통해 .git이라는 비어있는 레포지토리를 생성.
◦
레포지토리 : 프로젝트 디렉토리의 각 버전이 담기는 저장소.
•
Git은 .git folder 내의 파일들을 이용하여 폴더의 버전 관리를 수행함.
git init # .git 폴더 생성
ls -al # hello-git 내의 파일 확인
ls -al .git # .git 폴더 내의 파일 살펴보기
Bash
복사
폴더 내 파일 추가 및 변경하기
•
FastAPI를 이용해서 임시 DB(list)에서 user의 id를 반환하는 API를 만드는 아주아주 간단한 프로젝트를 만들어보고자 합니다!
Commit 해보기
•
위의 과정을 통해 hello-git 폴더가 아래와 같이 변경되었습니다!
변경 전 폴더
변경 후 폴더
•
이제 이 변경 사항을 repository에 저장을 해주어야 하는데요. 이를 위한 작업을 commit 이라 합니다.
그 전에 과제에 이름을 적듯이 어떤 사람이 commit을 날렸는지를 알기 위해서는 깃에 사용자의 정보를 입력해주어야 합니다. 아래의 명령어를 통해 git config를 수정해봅시다!
git config --global user.name "이름" # github 사용자 이름
git config --global user.email "이메일" # github 설정 이메일
git config --global init.defaultBranch main # branch 이름 통일을 위해 설정(for 실습)
git config --list # 변경된 config 확인 가능
Shell
복사
defaultBranch를 main으로 변경하는 이유
•
Git의 이전 버전에서는 ‘master’를 기본 브랜치의 이름으로 사용하였지만, 버전이 업그레이드 되면서 ‘main’을 기본 브랜치의 이름으로 사용하고 있습니다. 따라서, 이전에 깃이 미리 설치되셨던 분(이전 버전의 깃을 사용하고 계신 분)들을 위해 브랜치명을 통일시키는 명령어를 실행시켰습니다!
•
설정을 완료했다면 commit을 위해 아래의 명령어를 한 번 일단 실행해봅시다
git commit
Bash
복사
•
짜잔~ 오류가 났습니다! 오류 메세지를 살펴보면 nothing added to commit but untracked files present (use "git add" to track) 이라고 하네요.
•
아직 add 가 뭔지는 모르겠지만, 아래의 코드를 이용하여 수정한 파일(router.py, schema.py, server.py)을 add를 시켜줍니다.
git add router.py
git add schema.py
git add server.py
Bash
복사
•
그리고 아래의 코드를 실행시켜주면 저희의 첫 번째 commit이 완료됩니다!
git commit -m "Initial hello-git project"
Bash
복사
◦
-m 옵션을 이용하여 커밋 메시지를 입력할 수 있다.
◦
-m 옵션을 주지 않으면 vi 편집창을 통해 커밋메시지를 남기게 된다.
•
git commit history를 살펴보기 위해서는 git log 명령어를 이용할 수 있습니다.
◦
log는 위에서부터 최신순으로 보여지며, Author, 커밋 아이디(커밋 해시) , 커밋 메세지, 커밋 시간 등을 볼 수 있습니다.
◦
--pretty=oneline 옵션을 주면 각 커밋을 한 줄로 보이게 해주어서 편하게 볼 수 있다.
git log
git log --pretty=oneline
Bash
복사
•
특정 커밋을 좀 더 자세히 살펴보고 싶다면, git show 명령어를 이용할 수 있다.
git show <커밋 아이디> # 커밋 아이디는 앞에 몇 개만 입력해주어도 된다.
Bash
복사
Git 기초
Git의 3가지 작업 영역
: Git은 내부적으로 크게 3가지 종류의 작업 영역을 두고 동작합니다. (일단 지금은 Remote Repository는 무시해봅시다)
•
Working Directory
◦
실제 작업이 수행되는 공간.
◦
위의 예시에서는 hello-git 폴더가 working directory가 됩니다.
•
Staging Area
◦
git add를 한 파일들이 존재하는 영역.
◦
commit을 하기 위해 버전을 만들고 있는 공간이라고 생각하면 편하다.
•
Repository
◦
working directory의 변경 이력들이 저장된 영역. 즉, commit들이 저장되는 영역.
◦
git commit 명령어를 수행하면, staging area의 이미지가 repository에 하나의 버전으로 저장되게 된다.
◦
위에서 살펴본 .git 디렉토리가 repository가 됩니다.
→ 정리해보자면 1) working directory에서 어떤 작업을 수행하고, 2) 작업한 파일을 git add 를 통해 Staging Area에 올려주고, 3) git commit 을 통해 Staging Area에 있던 파일들을 스냅샷(snapshot)처럼 repository에 저장하게 됩니다.
•
한 번 해볼까요?
# terminal
vi README.md
Bash
복사
•
◦
다른 걸 적고 싶은 분들은 다른 내용 적으셔도 됩니다!
## 엔지니어링 공동세션 'Git똥차게 Git 정복하기' 자료입니다.
### 🖥️ Opening a server
```
uvicorn server:app --reload
```
Bash
복사
•
git add 및 commit 하기
git add README.md
git commit -m "Add README.md"
Bash
복사
Git이 보는 파일의 4가지 상태
Git으로 관리되는 파일은 상태(status)를 가집니다.
•
일단 크게 Untracked 상태와 Tracked 상태로 구분할 수 있고, Tracked 상태는 다시 Staged, Unmodified, Modified 상태로 나누어집니다.
그리고 각 상태들의 의미는 다음과 같습니다.
•
Untracked 상태 : 파일이 Git에 의해 변동사항이 추적되고 있지 않은 상태. 파일을 생성하고 그 파일은 한 번도 git add 해주지 않았다면 Untracked 상태에 머무릅니다.
•
Tracked 상태 : Git에 의해 변동사항이 추적되고 있는 상태.
◦
Staged 상태 : 파일의 내용이 수정되고 나서, staging area에 올라와있는 상태.
▪
새로 생성한 파일에 내용을 쓰고 git add를 해주거나
▪
한 번이라도 커밋에 포함됐었던 파일이라도 내용을 수정하고 git add를 해준 상태.
◦
Unmodified 상태 : 현재 파일의 내용이 최신 커밋의 모습과 비교했을 때 전혀 바뀐게 없는 상태.
◦
Modified 상태 : 최신 커밋의 모습과 비교했을 때 조금이라도 바뀐 내용이 있는 상태.
그리고 이 상태(status)들은 git status 명령어를 통해 확인이 가능합니다.
•
git status : 깃이 인식하고 있는 프로젝트 디렉토리의 현재 상태를 보여줌.
git status
Bash
복사
•
만약 출력으로 nothing to commit, working tree clean 이라는 안내문구가 뜬다면, 현재의 working directory가 바로 직전의 commit과 차이가 없다는 것을 의미합니다.
git add & commit
git add
•
stage : git add를 통해 파일을 staging area에 추가하는 것.
파일 1개 add하기
•
add 명령어 뒤에 파일 이름을 입력하면 해당 파일을 staging area에 추가한다.
git add <filename>
Bash
복사
폴더 전체 add하기
•
add 명령어 뒤에 폴더 이름을 입력하면 해당 폴더 내의 모든 파일을 staging area에 추가한다.
git add <foldername>
Bash
복사
변경된 모든 파일 add하기
•
add 명령어 뒤에 . 을 입력하면 현재 프로젝트 디렉토리 내에서 변경사항이 생긴 모든 파일들을 staging area에 추가한다.
git add .
Bash
복사
git add 취소하기
•
git reset 명령어 뒤에 파일 이름을 입력하면 해당 파일을 staging area에서 제거한다.
◦
git reset 명령어를 사용하더라도 working directory의 모습은 변하지 않는다.
git reset <filename>
Bash
복사
git commit
git commit 하기
•
git commit : staging area에 있는 것들을 repository에 올려주는 명령어
•
-m 옵션을 이용하여 커밋 메세지를 작성할 수 있다.
•
-m 옵션을 주지 않으면 vi 편집창을 통해 커밋메시지를 남기게 된다.
git commit -m "커밋메세지"
Bash
복사
최근 git commit 수정하기
•
--amend 옵션 : 최신 커밋을 새로운 커밋으로 수정 가능
git commit --amend
Bash
복사
git diff : 두 commit 간의 차이 확인하기
git diff <더 이전의 commit id> <더 이후의 commit id>
Bash
복사
git reset: commit 되돌리기
•
HEAD : 어떤 한 커밋을 가리키는 변수. 보통 가장 최근에 한 커밋을 가리킴.
•
Working directory의 내부는 HEAD가 가리키는 커밋에 따라 구성된다. 즉, HEAD가 과거 시점의 commit을 가리키고 있다면 HEAD가 가리키는 commit의 상태대로 working directory가 변경된다.
•
git reset : 과거 커밋으로 돌아가고 싶을 때 사용. HEAD가 과거의 commit을 가리키도록 한다.
•
여기서 commit id 를 명시하지 않고, HEAD^ (바로 직전의 커밋) 또는 HEAD~x (x 시점 전의 커밋) 표현을 사용하여도 된다.
git reset <reset 옵션> <reset할 시점의 commit id>
Bash
복사
git reset의 3가지 옵션
•
git reset에는 --hard, --mixed, --soft 3가지 옵션이 있으며, 각각의 옵션은 다음과 같습니다.
◦
--hard : working directory, staging area, repository를 모두 변경 - 복구 불가능
◦
--mixed : staging area, repository를 변경
◦
--soft : repository만 변경
Command 정리
여기까지 깃의 아주아주 기초적인 부분을 다뤄보았습니다. 한 번 지금까지 살펴본 주요 command line을 빠르게 복습해봅시다!
•
git init : 현재 디렉토리를 Gi이 관리하는 프로젝트 디렉토리(Working directory)로 설정하고 그 안에 레포지토리(.git 디렉토리) 생성
•
git config user.name [username] : 현재 사용자의 아이디를 [username]으로 설정
•
git config user.email [useremail] : 현재 사용자의 이메일 주소를 [useremail]로 설정
•
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 커맨드의 공식 매뉴얼 내용 출력
•
git log : 커밋 히스토리 출렷
•
git show [커밋 아이디] : 특정 커밋에서 어떤 변경사항이 있었는지 확인
•
git reset [옵션] [커밋 아이디] : 옵션에 따라 하는 작업이 달라짐 (default : --mixed)
GitHub Repository 사용하기
•
GitHub은 로컬 저장소에 저장된 내용을 원격 저장소에 저장하여 ‘어디서든’ 접근할 수 있는 서비스입니다.
Github 회원가입 - 다들 하셨죠?
Github Remote Repository 만들기
1.
https://github.com/ 에 접속하여 로그인을 합니다.
2.
오른쪽 상단 프로필 사진 클릭 > Your profile > Repositories > New 클릭
3.
Repository 정보 입력
Repository name(필수) 입력 : boaz-engi-git(자유롭게 변경)
Description(선택) : 기호에 맞게 작성하세요
공개 범위 설정: Public vs Private
Initialization 옵션 선택 - 아무것도 변경하지 않음.
•
◦
Repository의 초입에서 본 레포지토리 정보를 정리해놓을 수 있는 파일
◦
본 실습에서는 생성하지 않음! 직접 로컬에서 작성할 예정.
•
Add .gitignore
◦
.gitignore : staging 하지 않을 파일의 위치를 작성하는 파일
◦
일반적으로 시스템 설정 파일들이 github에 올라가는 것을 막기 위해 사용
•
Choose a license
◦
코드의 저작권 라이선스를 선택하는 항목. 상업용인지 등등 설정 가능.
4.
Create repository 클릭
•
짜잔~ 여러분의 (아마도) 첫 번째 레포지토리가 생성되었습니다!
•
이렇게 깃헙에 생성된 레포지토리를 원격 레포지토리 또는 Remote Repository라 합니다.
•
반대로 저희가 기존에 작업하던 내 컴퓨터 상의 레포지토리는 Local Repository라 합니다.
Remote Repository와 Local Repository 연결하기
•
GitHub에 원격 레포지토리를 생성하면 아래와 같이 로컬 레포지토리와 연결하는 두 가지 방법이 작성되어있습니다.
◦
첫 번째의 경우 로컬 레포지토리를 ‘새롭게’ 만들고 커밋 후 깃헙에 업로드를 하는 방식이고,
◦
두 번째의 경우 ‘이미 만들어져있는’ 로컬 레포지토리를 깃헙에 업로드를 하는 방식입니다.
•
저희의 경우 두 번째 경우이기 때문에 두 번째 Quick setup 방식을 따라가보겠습니다.
◦
remote : 원격 저장소에 관한 작업을 할 때 사용하는 커맨드라인
◦
add : 새로운 원격 저장소를 등록하겠다는 의미.
◦
git push 와 -u(--set--upstream) 옵션은 아래에서 차근차근 다뤄봅시다!
# 로컬 레포지토리에서 실행
git remote add origin https://github.com/YunSeo00/boaz-engi-git.git # boaz-engi-git repo를 origin이라는 원격 저장소로 등록
git push -u origin main
Bash
복사
왜 origin을 쓰나요?
•
origin이 아닌 다른 단어를 사용하여도 괜찮습니다!
•
다만, Git에서 원격 저장소를 최초로 추가할 때 origin이라는 이름으로 가리키는 것이 관례화되어 있어 특별한 이유가 없다면 그대로 사용하는 것이 좋아보입니다
•
다음과 같이 원격 저장소에 로컬 저장소의 내용이 모두 올라갔다면 성공한 것입니다!
갑자기 레포지토리가 꾸며졌(?)어요!!
•
•
따라서, 프로젝트가 끝나고 좀 더 한 눈에 나의 프로젝트를 보여주기 위해, 나의 코드를 설명하기 위해 .md 파일을 효과적으로 사용해보세요
•
markdown 문법은 Notion과 비슷하지만 약간 다른 점들도 있으니 구글을 통해 하고 싶은 작업을 해보아요~~
Remote Repository의 쓰임새
1.
안정성 : 로컬에 있는 파일이 날라가도 언제든 불러올 수 있음!
2.
협업 가능 : 원격 저장소와 git push , git pull command를 이용하여 협업 가능!
Local Repository의 변경사항 Remote Repository에 보내기 및 받기
로컬 저장소 → 원격 저장소
•
git push : 로컬 저장소의 내용을 원격 저장소로 보내는 명령어
◦
방금 push를 통해 원격 저장소에 자료를 올려보았습니다!
◦
위에서는 -u 옵션에 무언가를 지정하여 push를 했지만, 이제는 아래처럼 git push 만을 입력해도 자료를 업로드 할 수 있습니다! (이유는 branch 파트에서 알아보아요 )
)git push
Bash
복사
원격 저장소 → 로컬 저장소
•
git pull : 원격 저장소의 내용을 로컬 저장소로 불러오는 명령어
아까 위에서 ‘Remote Repository’를 이용하여 협업이 가능하다고 했는데요. 바로 원격 레포지토리에 여러명의 사용자가 접근하여 작업을 하고 push를 하며 작업물을 변경해갈 수 있는 것입니다!
•
그럼, 원격 저장소에 있는 작업물을 내 working directory로 불러올 수도 있어야겠죠?
•
README.md 파일 변경
저는 한 번 날짜를 넣어보았습니다~ 자유롭게 변경해주세요!
•
git pull 실행 및 변경된 파일 확인
cat README.md # 변경 전
git pull
cat README.md # 변경 후
Bash
복사
•
git fetch : 원격 저장소의 변경사항을 새로운 브랜치로 병합하는 명령어. pull을 받아오기 전에 정말 믿을만한 변경 사항인지 확인하기 위해 사용할 수 있음.
◦
갈 길이 멀기 때문에 실습과 예시는 블로그를 첨부합니다 ㅎㅎ
여기부터는 출석 과제가 있습니다! 실습을 진행해주세요!!
다른 사람의 Repository Clone 해보기
•
git clone 명령어를 이용하여 다른 사람의 원격 레포지토리를 불러올 수도 있습니다.
•
맘에 드는 레포지토리에서 Code > HTTPs에 뜨는 주소를 복사하여 git clone 다음에 입력하면 해당 레포지토리를 명령어를 실행한 위치로 가져올 수 있습니다.
•
git clone : 깃허브 프로젝트의 레포지토리를 그대로 복제
cd .. # hello-git 폴더에서 나오기 (아마,,, 상위 디렉토리에서 작업해도 괜찮겠죠?)
git clone <https 주소>
Bash
복사
클론 명령어를 사용하려고 했는데 Username과 Password를 입력하라고 합니다!
•
위에서 발급받은 GitHub 토큰을 기억나시죠?
◦
Username에는 깃허브 유저 네임을, Password에는 계정 비밀번호가 아닌 위에서 복사한 키를 입력해주시면 됩니다.
여기까지 되었으면, 이제 branch로 넘어가봅시다!
Command 정리
여기까지 원격 저장소에 대한 내용을 배워보았습니다! 관련 command를 복습해봅시다
•
git push -u origin master : 로컬 저장소의 내용을 처음으로 원격 저장소에 올릴 때 사용
•
git push : 로컬 저장소의 내용을 원격 저장소에 보내기
•
git pull : 원격 저장소의 내용을 로컬 저장소로 가져오기
•
git clone [프로젝트의 GitHub 상 주소] : GitHub에 있는 프로젝트를 내 컴퓨터로 가져오기
branch 사용하기
•
Git에서 하나의 프로젝트는 여러 버전(종류)으로 관리할 수 있으며, 이를 돕는 기능이 branch 입니다.
•
또한, 여러 사용자가 하나의 줄기(branch)에서 작업을 하면 상상만으로도 난장판이 될 것이 확실합니다.
현재 나의 branch 확인하기
•
git status 명령어를 입력했을 때, On branch main 이라는 안내문구를 통해 내가 main branch에 있음을 알 수 있다.
git status
Bash
복사
새로운 branch 만들기
•
git branch [새롭게 만들 branch 이름]을 이용하여 새로운 branch를 만들 수 있다.
•
그렇게 되면, 지금까지 main branch에서 하던 작업이 모두 새로운 branch에도 적용되게 된다.
git branch test-branch
Bash
복사
특정 branch로 이동하기
•
git switch [이동할 branch 이름] 명령어로 원하는 브랜치로 이동할 수 있다.
•
-c 옵션을 주면 새로운 브랜치를 만들면서 이동한다,
git switch test-branch # test-branch로 이동
git switch -c [여러분의 이름(영어로)] # [여러분의 이름(영어로)] 생성 및 이동
Bash
복사
branch 목록 확인하기
git branch
Bash
복사
branch 삭제하기
•
-d 옵션을 이용하여 branch를 삭제할 수 있다.
git branch -d test-branch # test-branch 삭제
Bash
복사
branch 수정
•
[여러분의 이름(영어로)] branch에 변경사항 추가
◦
현재 작성되어 있는 router.py, schema.py, server.py 는 ‘./data’폴더에 존재하는 모든 csv 파일에서 ‘username’, ‘group’ 변수의 값을 받아 정보를 화면 띄워주는 fastapi 코드입니다.
router.py 코드 (궁금하실…까봐..)
◦
따라서, ‘./data’ 폴더에 본인의 정보를 .csv 파일로 저장한 뒤, main branch에 merge 시켜보도록 하겠습니다.
# terminal - branch : 본인의 이름 branch
mkdir data # data 폴더 생성
cd data
vi [본인이름].csv
Bash
복사
username,group
["최윤서"],["engi-20"]
Bash
복사
csv에 [내용]만을 변경해서 작성해주세요! (작성 완료 후 esc → :wq 누르고 빠져나오기)
remote repository 의 branch와 local branch연결하기 및 pull request 해보기
•
tracking connection : 로컬 레포지토리와 리모트 레포지토리의 브랜치를 연결 지어준 상태.
•
--set--upstream 또는 -u 를 옵션을 이용하여 현재 위치의 브랜치를 원격 저장소의 브랜치로 연결 가능.
# 자료를 commit하고
git add data
git commit -m "자유롭게~"
# push
git push -u origin yschoi
Bash
복사
•
github repository 확인 (새로운 브랜치가 생성되었습니다!)
•
pull request 해보기~
◦
원격 저장소에서 새로운 브랜치를 합치기 위해서는 pull request 와 merge 라는 기능을 사용합니다.새로운 브랜치에서 push를 하면 보통 자동으로 pull request를 만들라는 메세지가 뜹니다. (만약 없다면 pull request 로 들어가서 생성을 하면 됩니다!)
◦
Compare & pull request 클릭 → 자유롭게 내용 작성 후 Create pull request
▪
생성시 PR 제목과 코멘트를 작성합니다. 보통 본인이 한 작업에 대한 설명이 포함되면 좋습니다.
▪
상단에 Able to merge라는 문구가 뜨는데, 이 상태는 merge가 가능하다는 뜻입니다. (즉, conflict가 발생하지 않음.) 다만, 불가능한 상황이라면 직접 conflict를 해결해주고 다시 commit을 해주어야 합니다.
◦
그러면 PR이 open되고, Merge pull request 를 통해 merge를 시켜줄 수 있습니다. (캡쳐를 깜박했군요….)
◦
그렇다고 아무나 merge를 시킬 수 있는 것은 아닙니다! GitHub에서 제공하는 branch protection Rule을 이용하여 규칙을 생성할 수 있습니다.
local에서 branch merge 하기
•
한 번 main 브랜치로 이동해봅니다!
◦
pull을 받기 전에는 main branch에는 data 폴더가 없습니다.
◦
그리고 pull을 받으면 데이터가 존재하는 것을 볼 수 있습니다.
git switch main
ls # 데이터 없음.
git pull
ls # data 있음.
Bash
복사
•
main 브랜치의 데이터를 수정해보겠습니다.
vi data/[본인 파일 이름].csv
# 데이터 수정 많이
git add data/
git commit -m "Modify .csv"
Bash
복사
•
git merge [merge 시킬 branch 이름] 명령어를 이용하여 branch merge 시키기
◦
commit 과 동일하게 -m 옵션을 이용하여 merge message를 남길 수 있다.
◦
아래의 예시에서는 newbranch의 HEAD를 main branch의 HEAD로 옮긴다고 이해해도 좋다.
git switch [본인 이름 branch]
cat data/[본인 파일 이름].csv
# 데이터 수정 많이
git merge main # main branch를 newbranch(현위치)에 merge
Bash
복사
main branch의 파일
yschoi branch의 파일
merge conflict 해결하기
•
위의 과정을 따르면 다음과 같이 충돌(conflict)이 일어났습니다!
◦
conflict : merge를 하다가 충돌이 발생함.
•
두 branch의 변경 사항이 충돌이 일어난 채로 merge를 하게되면, <<<<<<, ======, >>>>>>> 기호로 구분되어 충돌 정보가 파일에 표시됩니다.
◦
====== 기호를 기준으로 main branch의 변경사항이 위쪽에, newbranch 의 변경사항이 아래쪽에 보이게 됩니다.
◦
따라서, 사용자는 1) 위의 내용을 채택하거나, 2) 아래의 내용을 채택하거나, 아님 3) 새로운 내용을 작성하는 방식으로 conflict를 해결할 수 있습니다.
◦
수정 후에는 git status 명령어로 현재 conflict가 해결이 되었는지 살펴볼 수 있습니다.
▪
Unmerge paths : conflict가 발생한 파일
▪
Changes to be committed : conflict 해결 후 staging area에 올라간 작업물. 즉, conflict가 해결됨. commit을 통해 merge를 완료할 수 있는 상태.
◦
conflict 해결 후에는 git add 와 git commit을 이용하여 merge 작업을 완료해주면 됩니다.
충돌 후
수정 후
•
만약 merge의 conflict를 해결하지 않고, 취소하고 싶다면 --abort 옵션을 사용하시면, merge를 취소할 수 있습니다.
git merge --abort
Bash
복사
모두의 경험에서 우러나온 주의할 점 및 팁들
저도 많은 협업 경험이 없어서 ‘18기 엔지 대표님’의 ‘Git 센 Github에게 얻어맞지 않는 방법’ 발제와 ‘19기 엔지 대표님’의 ‘실전은 Gitㅔ야, Gitㅔ: Git과 GitHub 찍먹해보기’를 발췌해왔습니다!
제 디렉토리에 있는 변경사항이 사라졌어요..ㅠㅜ•
커밋을 안 하고 풀 했나요?!?커밋을 안 하고 풀 했나요?!?커밋을 안 하고 풀 했나요?!?커밋을 안 하고 풀 했나요?!?커밋을 안 하고 풀 했나요?!?커밋을 안 하고 풀 했나요?!?커밋을 안 하고 풀 했나요?!?커밋을 안 하고 풀 했나요?!?
•
당신을 깃바보로 임명합니다(는 제 경험담 22).. 절대로 결단코 본인이 변경한 부분이 있다면 반드시 커밋을 해주어야합니다.
◦
특히 pull 했을 때, 양쪽 버전이 다 살아있으면 좋지만.. 잘못된 명령어를 사용할 경우 완전히 덮어씌워지는 경우가 있습니다(그러면 야근 확정).
일부러 그러고 싶으시다면 다음 명령어를 통해 아예 내 로컬의 변경사항을 리모트의 것으로 덮어쓰는 설정을 해줍니다.(위험하니 접어씀)
◦
다음 명령어는 커밋을 굳이 하지 않아도 내 로컬과 리모트의 변경사항이 다른 것을 모두 보여주는 설정입니다. 그렇지만 수동으로 사후처리(모든 변경사항에 대해 로컬, 리모트 버전 중 하나 선택)를 해주어야하므로 무척이나 번거롭습니다.
git config pull.rebase
Bash
복사
◦
마치 ctrl + s 를 안 하고 컴퓨터가 강제 종료된.. 그런 상황
복구할 수 있나요?▪
한 번 머지된 커밋은 복구되기 어렵습니다.. 특히 그 이후에 시간이 더 많이 지났다면..?(추가적인 변경사항들이 있다면)
▪
마지막으로 커밋했던 이전 버전으로 되돌릴 수는 있습니다
•
하지만 커밋을 하지 않았다면…? (콩쥐야…X때써…)
아직 커밋을 할 수는 없는데 풀은 받고 싶어요!•
그럴 땐 git stash를 이용합니다.
•
git stash는 현재 변경사항을 임시로 저장해줍니다.
•
git stash 이후 pull을 하여 변경 사항을 반영해주고, 다시 git stash apply를 하면 작업하고 있던 내용들을 보존할 수 있습니다.
•
간단한 사용 워크플로우
1.
remote와 다른 변경사항이 있는 로컬 디렉토리에서 git stash → 로컬에 있는 최종 커밋 상태로 돌아감
2.
git fetch → 현재 브랜치의 remote를 가져옴
3.
git pull origin {branch - 대부분 main} → remote의 변경사항을 내 로컬에 풀(머지)
4.
git stash apply → 1에서 잠시 stash에 저장해놓은 변경사항들을 현재에 반영
•
push를 reject 당했어요ㅠㅜ•
원인
◦
(진짜 깃린이라면) 아예 origin이 다른 브랜치는 아닌지 확인해줍니다.
◦
첫 번째로는 둘의 commit 위치가 달라 그럴 가능성이 있습니다. 때문에 pull을 이용하여 둘의 커밋 위치를 맞춰줘야합니다.
◦
두 번째로는 현 레포지토리와 remote에 있는 레포지토리 사이에 conflict가 있어서 생기는 에러일 가능성이 높습니다.
•
위에서 다룬 conflict 해결 방법과 명석한 두뇌를 이용하여 잘 해결해봅시다!!
커밋을 잘못했어요! 되돌릴 방법은 없나요?•
git reset의 사용법을 정독하고, 본인의 상황에 맞는 방법으로 해결해봅시다!
그 외의 토픽들
커밋 메시지 작성 가이드라인 - git convention
GitHub 이슈 생성 및 이슈 번호와 함께 Commit message 남기기
VSCode에서 git 사용하기
위에서는 CLI를 이용하여 우당탕탕해보았지만, 사실 Git을 GUI로 이용할 수 있는 도구들이 많답니다! 오늘은 시간이 부족하여 다루진 못했지만, 여러 블로그들을 참고하여 더 편하게 Git을 이용해보아요
Gitmoji 사용하기
GitHub 프로필 꾸미기 (자매품 : README.md 파일 꾸미기)
•
누구나 좋아하는 변성윤님 블로그
•
특히 이 블로그가 맛집인 듯 합니다 (21기 분석 이상암님 블로그로 추정)
(21기 분석 이상암님 블로그로 추정)
