카테고리 없음

Git / GitHub 사용법

생선묵김치찌개 2022. 10. 26. 02:28

용어정리

  • 커밋 : 지금 코드의 상황을 저장하는것 = 버전을 만듬
  • 브랜치(나뭇가지) : 깃에서 관리 하에 놓인 코드를 다른 차원으로 복제하는 과정 -> 병렬로 작업 수행가능
  • 머지(merge = 병합) : 두개의 브랜치를 하나로 만듬 
  • 레포지토리 : 깃허브에서 하나의 프로젝트를 위한 저장소
  • 푸시 : 내가 만든 깃 내역을 깃허브에 올리는것
  • 로컬 : 내 컴퓨터

브랜치를 설명하는 그림

 

CLI 사용 vs GUI 사용

CLI(commend-line interface) 는 명령어를 터미널에서 사용함 -> 보통 깃에게 명령을 할때 사용

터미널의 default를 git-bash로 해놓은 상태

 

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 파일로 배제할 파일 설정 가능

 

.gitignore에 추가하는 파일 형식

[git에 파일 추가]

git add 경로/파일명.java : 파일 하나를 git이 관리하도록 함 (일반적이진 않음)

 

git add . : 파일 전체를 한꺼번에 선택해서 git이 관리하도록 함

 


■ Commit

 

[git에 커밋]

git commit : vim 모드에서 커밋 진행 (별로 안씀)

vim 모드에서 사용하는 명령어 (git log 볼때 사용)

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 log에서 해쉬코드를 드래그 해놓음

git reset --hard : 가장 최근에 커밋한 내용으로 돌아감 = 롤백임

 

git revert 해쉬코드 : 해쉬코드에 해당하는 커밋에서 바뀐 내용을 다시 이전으로 돌리고 이를 적용한 새로운 커밋을 만듬

 

 

※ revert 는 충돌 가능 -> ex) revert로 넘긴 커밋에서 leopard라는 클래스가 생긴거라 leopard를 삭제 해야하는데 지금 커밋에서 leopard라는 클래스를 고친 흔적이 있을때 (상식적으로 삭제할것을 고치진 않으니까 컴퓨터가 판단을 미루는것임 main|reverting으로 나옴) => 판단후 git continue-- 해줌

leopard를 삭제하기로 결정한 화면

revert 한후 vim 모드로 나오는데 :wq 로 저장해주면 됨

vim 모드에서 저장하는 모습

 

 

git revert --no--commit 해쉬코드 : 커밋은 생성하지 않고 그냥 변경만 해줌

-> 이 상태 후에 커밋하면 "git revert 해쉬코드"랑 똑같은 상황인거임

 

※ 보통 git revert 한후에 마음에 안들면 git reset --hard하여 이전에 쓰던 코드로 돌아옴

 

 


■ Branch

 

[브랜치 생성하기]

git branch branch-man : branch-man이란 브랜치명의 브랜치 생성

 

git branch : 브랜치 목록 확인

현재 브랜치가 new-team을 가르키고 있다는 뜻임

 

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 방식 / 보라색은 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 함

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 해주는거 잊지 말자

모두 다 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은 사실 변경사항만 저장하는것이 아니라 모든파일을 저장한다