Git 정리2 : Github

Kimhojin_Zeno·2023년 6월 5일
0

Git 정리

목록 보기
2/2

Git 정리2 : Github

출처 - 코딩애플 git 강의
https://codingapple.com/course/git-and-github/

git과 github는 다르다

git → 버전관리 프로그램

git이 파일 기록해두는 장소 → repository 레포지토리

레포지토리는 작업폴더에 숨김파일 해제해보면.git 폴더에 들어있음

컴터 고장나면? → 망한다

그래서 온라인에서 repository를 만들고, 로컬에서 작업한 후 온라인에다 백업하면 안심!

또 온라인 repository를 만들면 다른 사람과 협업이 가능하다.

온라인 repository = 원격 저장소

대표적인 원격 저장소 서비스 github

github.com

github 시작해보기

github에서 new repository를 만들고 난 후,

로컬에서 작업 폴더를 만들고

git init

입력하면

repository를 생성하는 명령어다. 아직 온라인에 백업은 안되었음.

github는 기본 브랜치 이름을 master가 아닌 main으로 사용하라고한다.

만약 기본 브랜치명이 main이 아니라면

git branch -M main

이렇게 바꿀 수 있다

github사이트에서 내가 만든 repository의 주소를 복사한다. https로 시작해서 .git으로 끝난다.

로컬 → 원격저장소로 보내기

git push -u 원격저장소주소 main

main브랜치를 원격저장소주소에 올린다는 뜻.

만약 vscode에서 github 로그인하라고 창이 뜨면 로그인하면 됨.

-u는 뒤의 주소를 기억해두라는 뜻이다. 한번 이렇게 하면 그 다음부터는

git push

이것만 해도 됨.

원격저장소주소를 입력하는게 귀찮으면 변수에 저장가능

git remote add origin https://githun~~.git

이렇게 하면 origin 이라는 변수명에 주소가 저장된다.

.gitignore

원격저장소에 올리고싶지 않은 파일은 coommit해서 올리지 않는게 좋다.

.gitignore 파일을 하나 만들어 놓으면 저장소에 올리지 않을 파일들을 리스팅해 놓을 수 있다

.gitignore에 파일이름을 넣으면 git add . 해도 스테이징되지 않음.

웹개발에서 node_modules, .env (개인정보있음) 등은 올리지 않는다.

협업해보기

원격저장소에 있던 거 내려받기

git clone 저장소주소

다른 팀원도 github 아이디를 레포지토리에 Collaborators 메뉴에 등록해놔야 협업가능하다

이제 다른 팀원이 git clone으로 내려받고 작업해서 push하려는데

clone 받은 상태에서 내가 변경을 만들고, 팀원이 그 상태에서 push하려면 오류가 난다.

→ 원격 vs 로컬 내용이 다르다면 로컬 저장소에서 git push가 안된다.

git pull

git push하기 전에 git pull부터 하자!

원격저장소 → 로컬저장소

git pull 원격저장소주소

모든 브랜치 내용이 원격저장소에서 가져와 로컬저장소에 합쳐진다

이러면 최신이므로 git push가능

결론 → 변동사항 생겼으면 git pull하고 git push

git pull 원격저장소주소 브랜치명

특정 브랜치를 가지고 옴

이전에 -u로 주소를 등록해놨으면 git pull만 해도 된다

git pull은 git fetch와 git merge를 동시에 하는 명령어다

git fetch : 원격저장소 신규 commit 가져오세요

git merge : 내 브랜치에 merge

git pull하면 conflict가 날수도 있다.

pull request

github사이트나 로컬 repository에서 새로운 브랜치를 생성하고

작업후 add, commit까지 했다.

그 다음 로컬 브랜치를 원격저장소에 올리고 싶다면

git push 원격저장소주소 로컬브랜치명

해주면 된다

git push 원격저장소주소

만 하면 모든 브랜치가 올라가고, 로컬브랜치명을 특정해주면 그것만 간다.

! 보통 특정 브랜치만 올리는 일이 많다.

브랜치를 올리고 나면 새로 올린 브랜치를 main 브랜치와 합쳐야한다.

팀으로 협업을 하면 merge하기 전에 토론하거나 검토하거나 한다.

그게 바로 pull request 기능.

Pull request를 생성하면,

관리자가 그걸 보고 merge 여부를 결정한다.

merge할때는 3way, squash, rebase 등 방식을 고를 수 있다

git stash

임시보관함이다.

커밋 후 코드를 새로 입력했는데 이 코드들을 잠깐 치워두고 싶다.

임시보관함으로 보내고 싶다. 하면 git stash를 사용하면 된다.

git stash

최근 commit 상태로 되돌아간다

그 후 작성된 코드들은 임시보관함에 들어간다.

git stash save 'b코드 망함'

이렇게 메시지도 같이 남길수 있음

git stash list

여러번 할 수 있다. 임시보관함에 있는 것들을 나열해줌

git stash pop

보관했던 코드 중 가장 최근에 보관한 코드부터 불러온다(스택)

git stash drop 삭제할id
git stash clear

특정 stash삭제

모든 stash삭제

주석처리하는 것과 비교해서 주석은 commit에도 다 남기 때문에 더 깔끔하게 가능하다.

또는 새로운 브랜치를 하나 만드는 것으로도 stash안쓰고 가능.

GitFlow 전략

프로젝트가 커져도 깔끔하게 하기 위한 전략이 여러개 있다

‘방법론’

여러가지 중

GitFlow전략

  1. main
  2. develop
  3. feature
  4. release
  5. hotfix

개발중인 코드는 develop 브랜치에서 진행된다.

그 develop브랜치에서 다시 기능별로 나눠서 브랜치를 만든다.

예를들어

feature/친구기능

feature/길드기능

기능이 만들어지면 develop 브랜치에다가 merge한다.

그 다음 develop을 main에다가 merge하기 전에

release 브랜치를 만들어서

버그 수정을 위해서 테스트, QA같은거 하면서

release 브랜치를 드디어 main 에다가 merge했는데

심각한 버그가 발견된다.

그럼 이제 바로 그것만 패치하는 hotfix 브랜치를 만들어 수정하고 합친다

hotfix 브랜치는 main 브랜치에다가 직접 merge해줌.

main 브랜치에다 merge한 후 develop에다가도 merge해준다.

장점: 안정적으로 버전별 배포가능

단점: CI/CD를 하는 곳에서는 싫어한다.

Trunk-based 전략

브랜치 하나만 잘 관리하자.

main브랜치 하나만 운영하고 기능별로 브랜치 만들었다 머지하고 하는 방식

장점: 소스코드 한 곳에만 있다

단점: 테스트 많이, 자주 해야함

테스트 자동화, 배포 자동화한 경우에 알맞음.

안정화된 프로젝트에 쓴다.

profile
Developer

0개의 댓글