[temp] 03. Git / GitHub
GIT
VCS (Version Control System)
- 빠른 속도, 단순한 구조
- 분산형 저장소 지원
- 비선형적 개발 가능 (수천개의 브랜치)
git objects
- Blob : 파일 하나의 내용에 대한 정보
- Tree : 해당 Blob의 기록들 (메타데이터)
- Commit : 모음, 의미 있는 변동사항들의 덩어리
git file status
깃으로 추적하는 4가지 파일의 상태
추적안됨
,수정함
,수정없음
,스테이지됨
-
$git add
는수정함
과추적안됨
파일을 스테이지로 업로드 할 수 있는데add
하면스테이지됨
파일상태가 된다. -
$git commit
을 하면수정없음
상태로 돌아가 다시 파일을 수정할 수 있음.
깃은 변경사항의 모음이 아닌 모든 전체의 모음이다.
그럼에도 용량이 무겁지 않은 이유는 변경되지 않은 파일은 변경되지 않음만을 표시해 저장하기에 같은 파일이 두 번이상 저장되지 않기 때문이다.
한번 스테이지에 올라간 파일들은 수정되지 않아 add
를 하지 않아도 계속 스테이지에 존재 하기 때문에 커밋을 전체의 묶음으로 볼 수 있다.
기록해야 하는 변경사항 두개가 있을 때 add
를 사용해서 특별한 것만 stage에 올리고 commit
을 찍어 두번으로 나눠줄 수 있다.
빈 디렉토리
원래 git은 빈 디렉토리를 Tracking 하지 않는다.
그렇기에 폴더안에 어떠한 파일이라도 존재하고 그 파일이
커밋이 되어야 remote repo에 올릴 수 있다.
git process
작업해서 메모한 뒤 넘긴다.
오프라인 (local)
-
working directory : 코딩 및 작업 단계
-
staging area : git에 올라갈 파일들을 설정
-
local repo : commit으로 기록을 남김
→ 인터넷에 연결되어 있지 않아도 개발자가 언제 무엇을 했는지 기록을 저장해 둔다.
온라인 (remote)
- remote repo : github에 업로드 한다.
github
git ≠ github
git을 이용한 클라우드 서비스
라이센스
-
MIT : 자유로운 수정 재배포 가능
-
Apache : 수정배포 가능하나 원작자 표기
-
GNU GPL 라이센스가 전염
→ 이 라이센스가 들어간 코드를 사용하면 무조건 GPL 라이센스를 사용해야 함
커밋 컨벤션
commit write in english....
-
제목은 50자 이내로
모든 내용을 한 눈에 파악할 수 있게 핵심적인 구나 절의 형태로
-
제목과 내용 사이는 한칸 줄바꿈 공간을 두기.
-
prefix를 사용하여 커밋의 용도를 작성해 둔다.
-
PREFIX
feat (features) - 기능이 추가 되었을 때
docs (documentations) - README.md 같은 텍스트 작업
conf (configurations)
test (test) - 테스트를 돌린 결과물
fix (bug-fix) - 디버그를 하거나 이슈가 해결되었을 때
refactor (refactoring) - 문법적인 개선점을 주었을 때 (5줄의 실행을 1줄로 줄이거나)ci (Continuous Integration)
build (Build) - 배포 전 마무리 단계
perf (Performance) - 성능개선
asset (asset) - 파일 업로드
style (style) - 코드 포맷팅, 세미콜론 누락, 코드 변경 없음
-
git commit
기본 설정
$git config — list 목록들을 확인할 수 있음
$git config —global user.email {[email protected]} "{이메일}"
$git config —global user.name {name} "{이름}"
$git config —global core.editor "vim"
$git config —global core.pager "cat"
local과 remote의 repo 이름은 통일 시킨다.
create repo
-
git init
$git init
→$ git remote add origin {url}
▶
$git init
명령어로 현재 폴더에 local repo를 생성한다.
한 폴더에 하나의 local repo만 유지해야 한다.
상위 폴더 안에 들어 있는 하위 폴더에 repo를 생성하면 상위 폴더 repo에 종속된다.
-
repo가 생성되었는지 확인하는 방법
-
$git status
수정된 파일이 있는 지 확인하는 명령어$git status -uall
수정된 파일이 어떤 파일인지 풀어서 설명 -
ls -a
.git 파일이 존재하면 repo가 생성된 것이다.
-
▶
$git remote add origin {url}
명령어로 remote repo와 연결해 준다.
origin이라는 이름의 링크를 연결해 준다라는 뜻이다.
origin은
clone
사용 시 자동으로 생성되는 이름이다. -
-
git clone
$git clone {remote repo's url}
git clone
으로 remote repo를 복사한다면 repo의 이름으로 폴더가 생성된다.현재 폴대에 풀기 위해서는
$git clone {remote repo url} .
(현재 폴더가 빈폴더일 때만 가능합니다.)
자동으로 origin이라는 이름의 원격저장소가 등록되게 됩니다.
branch name
github의 branch default 설정은
main
이다.
local repo와 remote repo의 branch 이름을 통일 시켜야 한다.
$git branch
현재 브랜치의 이름을 확인하는 명령어
$git branch -M name
현재 브랜치의 이름을 바꾸는 명령어
commit
[offline]
-
stage
에 수정 된 파일 올리기$git add file-name
$git add .
전체파일 선택커밋 분기점을 자르기 어려워질 수 있으니 조심히 사용할 것
-
stage
의 파일의 커밋 메세지 작성하기$git commit
→ vim이 뜬다. -
commit
확인하기$git log
커밋된 목록과 내용을 확인 할 수 있는 명령어
커밋은 의미있는 수정을 분기로 작성하는 것이 좋다.
[online]
-
$ git push -u origin {branch-name}
-u
는 local과 remote의 repo를 연동시키는 명령어로해당 브랜치로
push
하는 처음 한번만 하면 된다.$git push origin main
push
는 최소 기능 단위로 올리는 것이 좋다.
code review
branch
메인 브렌치에서 만들어진 분기점 🌌평행 우주같은 느낌
- 여러 사람이 개발하기에 좋다.
merge
새로운 코드가 작석된 compare(최신 브랜치)를 base(기존 브랜치)와 합친다.
$git merge (compare)
합집합
review → pull request
-
브랜치 생성
$git branch
현재 브랜치 위치 확인$git branch {create branch}
새로운 브랜치 생성$git switch {branch}
브랜치 이동
→ 새로운 브랜치에서 커밋을 작성 후 push
-
pull request
-
리뷰어 설정하기
repo의 setting → manage access → 리뷰어 추가
-
pull reguest 제출
-
review 해결 후 승인 요청
-
스스로 혹은 리뷰어의 merge
merge가 된 remote repo의 업데이트 상태를 local repo에 적용하기
-
$git fetch origin main
remote repo에 있는 내용을 임시 branch인
FETCH_HEAD
에 담는 명령어→
switch FETCH_HEAD
로 이동해서 최신 내용을 확인할 수 있다. -
$git merge FETCH_HEAD
FETCH_HEAD
에 있는 내용을 현재 local repo에 merge 해서 업데이트가 된다.---
==
$git pull
pull은 위의 두 명령어를 합친 것과 같은 기능을 한다.
Branch
-
-
새로운 기능을 개발하거나 할 때 main brach 혹은 develop branch가 아닌 feature branch를 생성 후 작업을 해야 한다.
-
create branch
git branch {생성할 브랜치 이름}
-
move branch
git switch {이동할 브랜치 이름}
-
merge branch
main branch로 이동 후 →
git merge {작업이 끝 난 feature branch}
-
delete branch
git branch -d {삭제할 브랜치 이름}
-
브랜치에서 코드 리뷰가 필요하지 않는 이상 cli에서 merge 한 뒤 push는 main에서 진행한다.
합치기 전 정상 작동이 된다는 것이 확인된 상태이기 때문에 굳이 깃헙에 새로운 브랜치를 추가하지 않기 위해서?
-
파일 수정 후
add
나commit
없이 브랜치를 옮기게 된다면 수정 사항이 따라와서 브랜치를 더럽히게 된다.→ 그럴 경우 다시 파일 수정이 일어난 브랜치로 이동 후
add
나commit
을 진행해준다.
Branch Collision
-
같은 파일이 동시에 수정이 된 경우 발생하게 된다.
자동으로 합쳐지지 않았기 때문에 직접 코드를 보고 합쳐서 사용할지, 이전 것을 사용할지, 새로운 것을 사용할 지 선택해야한다.
가운데 선을 중심으로 위쪽은 이전 코드 아래쪽은 새로운 코드이다.
수정이 완료된 후에는 꼭 커밋을 찍어줘야 한다
Before Push 변경 및 수정
파일이동 혹은 이름을 바꿔야 한다면 git 명령어를 사용해서 이름을 바꿔야 한다.
-
git mv 바뀌기 전 이름 바뀔 이름
해당 명령어를 사용하면 renamed라는 스테이지 상태를 확인할 수 있다.
-
git rm
은 스테이지에 있는 파일을 삭제할 때 사용
-
스테이지에 있는 파일을 내릴 때
git restore --staged 돌리고 싶은 파일 이름
-
이전 커밋으로 돌아가기
git checkout .
-
갓 작성한 커밋 수정
git commit --amend
푸쉬하기 전에만
이전 커밋으로 돌아가기 REVERT
그 전 시점으로 돌렸다고 기록을 남긴다.
git revert --no-commit HEAD~3
최신커밋으로부터 몇개를 돌릴 건지 하나전이면 HEAD~1
--no
는 커밋 한개로 여러개 돌릴 때 사용 (원래는 한 커밋당 하나 작성해야하기에)
-
파일을 삭제해야 한다면 다른 팀원들에게도 알리기 위해서 기록을 남기는 것이다.
reset은 지웠다는 기록도 삭제하게 된다.
커밋도 파일도 삭제되지만 기록을 남길 수 있다면 revert
.gitignore
gitignore.io 에서 만들어진 코드들을 .gitignore파일에 붙여 넣어준다.
gitignore 파일에서 설정된 파일들은 깃 스테이트가 안되기 때문에 깃헙의 파일 용량을 줄일 수 있다.
braching models
우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그
git flow
- master(main) : 제품으로 출시될 수 있는 브랜치
- develop : 다음 출시 버전을 개발하는 브랜치
- feature : 기능을 개발하는 브랜치
- release : 이번 출시 버전을 준비하는 브랜치
- hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치
-
git flow init
→ main과 develop branch 생성 → develop으로 이동 -
git flow feature start helloworld
개발용 feature 브랜치 생성 → feature이동 -
git flow feature finish helloworld
닫고 develop에 머지 → 브랜치 지우기 -
git flow release start {v0.1}
develop에서 release branch 생성 -
git flow release finish v0.1
main과 develop으로 합쳐짐-
v1.0
소수점 뒷자리 : 마이너한 업데이트 (버그 수정)
앞자리: 큰 기능 업데이트 (게임 같은 경우 시즌이 달라진다.)
→ 1번째 머지 커밋 저장하고 나감 (main)
→ 태그를 적으라는 2번째 창이 뜸
태깅을 위한 커밋창
- === 패치 노트
→3번째 디벨롭으로 머지 커밋창
→각 브랜치 위에서 푸쉬로 remote
-
-
git push --tags
tag도 푸쉬
Summary of actions:
- Release branch 'release/v0.1' has been merged into 'main'
- The release was tagged 'v0.1'
- Release tag 'v0.1' has been back-merged into 'develop'
- Release branch 'release/v0.1' has been locally deleted
- You are now on branch 'develop'
위 창이 뜨면 성공적으로 합쳐졌다는 것이다!
→ develop은 자신의 remote develop에 push
→ main은 자신의 remote main 에 push
Squash Merge
메인 브렌치의 관점에서
메인 브렌치의 커밋을 통해 머지된 커밋들이 어떤 형상을 가진지 비교해보면 아래와 같습니다.
-
Merge
-
Merge : 커밋 m에서부터 뒤로 되돌아가면서 부모를 모두 찾아 브렌치를 구성. 커밋 m은 부모로 c, Init을 가지고 있으며, c는 b, b는 a, a는 Init을 다시 부모로 가짐. 이 형상을 모두 backtrace 하여, Init -> a -> b -> c -> m이라는 구조를 만들고 이 구조가 모두 히스토리에 남음.
-
-
Squash and Merge
-
Squash and Merge : 커밋 'a,b,c' 는 Init만을 부모로 가진 단일 커밋. 작업했던 브렌치의 a, b, c 커밋들은 머지 후의 메인 브렌치 커밋 Init, 'a,b,c' 와 아무런 연관을 가지지 않음.
-
-
Rebase and Merge
-
Rebase and Merge : 커밋 a, b, c 의 관계를 그대로 유지한 채, 메인 브렌치에 그대로 추가. 커밋 a는 부모로 커밋 e를 가짐. Rebase and Merge 작업 후에는, 작업했던 브렌치의 a, b, c 커밋들은 머지 후의 메인 브렌치의 Init, d, e, a, b, c 커밋들과 연관 관계를 가지지 않음.
-
Git Flow
- Git Flow 를 따른다고 했을 때, 아래와 같이 정리할 수 있습니다.
- develop - feature 브렌치간 머지 : Squash and Merge가 유용합니다. feature의 복잡하고 지저분한 커밋 히스토리를 모두 묶어 완전 새로운 커밋으로 develop 브렌치에 추가하여, develop 브렌치에서 독자적으로 관리할 수 있기 때문입니다. 일반적으로 머지 후에 feature 브렌치를 삭제해버리는 점을 떠올려 보면, feature 브렌치의 커밋 히스토리를 모두 develop 브렌치에 직접 연관 지어 남길 필요가 없습니다.
- main - develop 브렌치간 머지 : Rebase and Merge가 유용합니다. develop의 내용을 master에 추가할 때에는 별도의 새로운 커밋을 생성할 이유가 없기 때문입니다.
- hotfix - develop, hotfix - master 브렌치간 머지 : Merge 또는 Squash and Merge 모두 유용합니다. 때에 따라 골라 사용하면 좋을 것 같습니다. hotfix 브렌치 작업의 각 커밋 히스토리가 모두 남아야 하는 경우 Merge, 필요 없는 경우 Squash and Merge를 사용하면 됩니다.
협업
Collaboration보다는 주로 Fork를 사용하는 작업이 많다.
- fork: 사본을 만들고 진행 (포크로 작업할 때도 원본의 양식을 지키는 것이 좋다.)
Author And Source
이 문제에 관하여([temp] 03. Git / GitHub), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://velog.io/@wuixwui/temp-03.-Git-GitHub저자 귀속: 원작자 정보가 원작자 URL에 포함되어 있으며 저작권은 원작자 소유입니다.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)