Git / GitHub 사용법
용어정리
- 커밋 : 지금 코드의 상황을 저장하는것 = 버전을 만듬
- 브랜치(나뭇가지) : 깃에서 관리 하에 놓인 코드를 다른 차원으로 복제하는 과정 -> 병렬로 작업 수행가능
- 머지(merge = 병합) : 두개의 브랜치를 하나로 만듬
- 레포지토리 : 깃허브에서 하나의 프로젝트를 위한 저장소
- 푸시 : 내가 만든 깃 내역을 깃허브에 올리는것
- 로컬 : 내 컴퓨터
CLI 사용 vs GUI 사용
CLI(commend-line interface) 는 명령어를 터미널에서 사용함 -> 보통 깃에게 명령을 할때 사용
GUI(graphical user interface)는 소스트리를 이용함 => 커밋이나 브랜치의 전체적인 구조를 볼때 사용
Git의 CLI (터미널에 입력)
[시작]
git init : 지금 내가 작성중인 프로젝트를 git이 관리하도록 함(프로젝트내에 .git라는 폴더가 생김)
git status : 현재 프로젝트를 git이 관리하고 있는 상황을 알려줌(ex. 어떤 파일은 커밋이 안됐다...)
- Untracted files: Git 관리에 들어간적 없는 파일
- Changes to be commit : Git 관리에 들어가서 커밋할수 있는 파일
git에 포함하지 않는것들 : 빌드결과물, 라이브러리, 보안상 민감한 정보를 담은 파일(절대x) => .gitgnore 파일로 배제할 파일 설정 가능
[git에 파일 추가]
git add 경로/파일명.java : 파일 하나를 git이 관리하도록 함 (일반적이진 않음)
git add . : 파일 전체를 한꺼번에 선택해서 git이 관리하도록 함
■ Commit
[git에 커밋]
git commit : vim 모드에서 커밋 진행 (별로 안씀)
git commit -m "커밋 메시지" : 커밋 메시지와 함께 커밋
git commit -am "커밋 메세지" : 새로 추가된 파일이 없는 경우 커밋 메세지와 함께 커밋(이걸 써야 할듯)
깃에 새로 생긴 파일 : 초록색 / .gitignore 된 파일 : 녹색 / 커밋후 변경된 파일 : 파란색 / 아얘 git에 안올라간 파일 : 빨간색
[이전 커밋으로 돌아가기]
reset vs revert
reset : 원하는 시점으로 돌아간 후 그 시점 이후 커밋들을 모두 삭제
revert : 커밋을 선택하면 그 커밋에서 변경되었던 내용이 사라지고 이를 적용한 새로운 커밋으로 만듬 (이걸 보통 사용)
ex) a라는 커밋에서 lion의 매니저명을 바꿨는데 (매니저명 : Marry->Drogbar)
a를 revert 하면 바뀐 내용이 다시 돌아옴 (Drogbar->Marry)
git reset --hard 해쉬코드 : 해쉬코드가 가르키는 커밋으로 돌아가고 그 시점 이후 커밋들 모두 삭제
git reset --hard : 가장 최근에 커밋한 내용으로 돌아감 = 롤백임
git revert 해쉬코드 : 해쉬코드에 해당하는 커밋에서 바뀐 내용을 다시 이전으로 돌리고 이를 적용한 새로운 커밋을 만듬
※ revert 는 충돌 가능 -> ex) revert로 넘긴 커밋에서 leopard라는 클래스가 생긴거라 leopard를 삭제 해야하는데 지금 커밋에서 leopard라는 클래스를 고친 흔적이 있을때 (상식적으로 삭제할것을 고치진 않으니까 컴퓨터가 판단을 미루는것임 main|reverting으로 나옴) => 판단후 git continue-- 해줌
revert 한후 vim 모드로 나오는데 :wq 로 저장해주면 됨
git revert --no--commit 해쉬코드 : 커밋은 생성하지 않고 그냥 변경만 해줌
-> 이 상태 후에 커밋하면 "git revert 해쉬코드"랑 똑같은 상황인거임
※ 보통 git revert 한후에 마음에 안들면 git reset --hard하여 이전에 쓰던 코드로 돌아옴
■ Branch
[브랜치 생성하기]
git branch branch-man : branch-man이란 브랜치명의 브랜치 생성
git branch : 브랜치 목록 확인
git switch branch-man : IDE에서 현재 브랜치에서 branch-man에 해당하는 브랜치로 이동함
git switch -c branch-man : branch-man이란 브랜치를 생성과 동시에 이동
git branch -d branch-man : branch-man이란 브랜치를 삭제
git branch -D branch-man : branch-man이란 브랜치를 강제 삭제(branch-man에만 있는 커밋 내용이 있는 경우)
git branch -m branch-man hydro-man : branch-man이란 브랜치를 hydro-man로 이름 변경
[브랜치 합치기]
merge vs rebase
merge : 두 브랜치를 한 커밋에 이어 붙임, 각각의 마지막 커밋이 합혀짐 => (브랜치 사용내역에 대해 남길 필요가 있을때, 협업하는 경우 주로 사용)
rebase : 브랜치를 그대로 잘라서 다른 브랜치에 이어 붙임 => (한줄로 깔끔하게 정리된 내역 유지하기 원할때 사용)
[merge로 합치기]
git merge add-coach(현재 가르키는 브랜치가 main인 상태) : add-coach 브랜치를 main 브랜치로 merge
※ merge는 하나의 커밋이기 때문에 reset으로 되돌리기 가능
+ 병합된 브랜치는 git branch -d add-coach로 삭제
[rebase로 합치기]
상황 : new-teams 브랜치를 main 브랜치로 rebase 할거임
1. git switch new-teams 하여 new-teams로 이동
2. git rebase main 함
3. git switch main 하여 main으로 이동
4. main에서 git merge new-teams 하여 main과 new-teams가 같은곳을 가리키게 함
5. new-teams 브랜치 삭제
[merge, rebase에서 발생하는 충돌 해결]
merge
main과 다른 브랜치를 merge할때 같은 위치에 있는 코드의 내용이 다르면 충돌이 발생함 (둘중 하나를 선택해 줘야함)
=> 충돌이 너무 많아서 merge 전으로 되돌리고 싶은 경우 git merge --abort를 사용
rebase (협업에서 사용 X)
main과 다른 브랜치를 rebase 할때 같은 위치에 있는 코드의 내용이 다르면 충돌 발생함(둘중 하나 선택해 줘야함)
merge랑 다른점 : merge는 한번에 병합이 된다면 rebase는 커밋마다 코드 내용이 다른것에 충돌이 발생하기 때문에 rebase 된 커밋에서 ①커밋 하나 단위로 코드를 둘중하나 선택해주고, ②이를 커밋하고(Vim창 뜨게 git commit만 쳐줌), ③git rebase --continue 해줘야함
터미널 오른쪽에 REBASE 1/2 식으로 rebase 된 커밋 수가 나옴
마지막에 main을 rebase 한 브랜치에 merge 해주는거 잊지 말자
※ Tip. 충돌이 일어난 지점은 <<<<<<<< / ======== / >>>>>>> 로 이루어져 있으므로 이것들만 찾으면 됨
※ 다 사용한 브랜치는 그때 그때 지워주자
※ 소스트리에서 merge는 병합 rebase는 재배치이다
■ GitHub 사용법
(초기 설정)
git remote add origin 원격주소 : 로컬의 git 저장소에서 원격저장소로 연결 추가
git push -u origin main : 푸시 될 디폴트 값 지정 (origin 이란 원격에 main 브랜치로 푸시한다는 뜻)
git remote : 원격 목록 보기
(진행중)
git clone 원격주소 : 동료의 깃 작성 내역을 내 컴퓨터로 가져올때 사용
git push : 설정된 레포지토리에 푸시
git pull : 설정된 레포지토리에 변경사항이 있는 경우 로컬로 커밋을 가져옴
git pull origin master --allow-unrelated-histories
동료가 깃허브에 push해서 바뀐 사항이 내가 push할 사항과 겹친다면? = pull한 다음에 push 해야함
1. git pull --no-rebase : 원격과 로컬의 코드를 merge 해줌 -> 푸쉬하면 내가 수정한 부분이 올라감
2. git pull --rebase : 원격과 로컬의 코드를 rebase 해주는데 원격이 이전 커밋으로 로컬이 가장 최신 커밋으로 배치됨
(pull 할때 rebase는 협업에서 사용 OK)
git push --force : 강제로 로컬의 내용을 원격으로 푸시 (협업할때 합의하고 사용해야함)
+a 깃허브에서 커밋 보는 방법
+a 협업할 팀원 추가하는법
+a 깃허브에서 파일로 가는거랑 커밋 내역으로 가는거랑 헷갈림
[원격에서 Branch 사용법] = 그냥 소스트리랑 깃허브에서 만지는게 나을듯?
git branch --all : 로컬 + 원격의 branch들을 모두 볼수 있음
git push -u origin from-local : 원격의 origin의 from-local 이란 브랜치를 만들고 이에 코드를 저장 (-u = upstream)
(상하관계를 확립해주는 코드)
git switch -t origin/깃허브의 브랜치명 : 앞으로 커밋하는 내용을 "깃허브의 브랜치명"으로 올리는것을 디폴트로 하고 로컬에 깃허브의 브랜치명으로 브랜치를 하나 생성
git push 원격이름 -d 원격의 브랜치명 : 원격의 브랜치를 삭제 할때 사용
git fetch : 깃허브의 최신 정보를 가져옴
[참고할 것]
upstream과 origin
(upstream : 상류) 우아한테크코스의 저장소 - 내가 우테코에서 포크한 저장소 - 로컬 (downstream : 하류)
로컬에서 origin은 내가 우테코에서 포크한 저장소
내가 우테코에서 포크한 저장소에서 origin은 우아한테크코스의 저장소
☆ 특징 : upstream 장소는 하나인데 하류로 갈수록 물줄기가 많아질수 있음
git의 객체
blob : 파일
commit : 저장단위, tree+blob+메타정보
tree : blob들을 묶어서 관리 (디렉토리 구조와 유사)
tag : 커밋에 대한 참조지만 설명이 추가되는 객체
파일내용 수정하고 커밋하면 Git은 사실 변경사항만 저장하는것이 아니라 모든파일을 저장한다