23.12.01
codeit강의보면서 공부했던 내용들입니다
[ git 개념 및 도구들 ]
- git : 버전관리 도구
- github : 버전관리되 내용들을 백업저장 = 원격저장소 → 협업을 도와줌
- git bash : Windows에서 Git을 설치할 때 함께 제공되는 터미널 환경
=> 윈도우 사용자가 Git 명령어를 실행하고 Git 저장소를 관리할 수 있는 환경
=> Bash 셸을 기반으로 하여 Windows에서도 유닉스/리눅스 커맨드를 사용할 수 있는 환경
+) Git Bash Here : 해당 위치에서 Git Bash로 작업을 시작
[ git 시작하기 ]
- repository : 프로젝트 디렉토리, .git디렉토리 - 시점별(버전별) 기록
- commit : 프로젝트 디렉토리의 모습을 하나의 버전으로 남기는 행위 & 결과물 (고정된 결과물)
1) git init : 해당디렉토리에서 git을 통한 버전관리를 시작
USER@DESKTOP-7IPND5J MINGW64 ~/MathTool
$ git init
Initialized empty Git repository in C:/Users/USER/MathTool/.git/
USER@DESKTOP-7IPND5J MINGW64 ~/MathTool (master)
$ ls -al
total 16
drwxr-xr-x 1 USER 197121 0 Nov 10 20:25 ./
drwxr-xr-x 1 USER 197121 0 Nov 10 20:25 ../
drwxr-xr-x 1 USER 197121 0 Nov 10 20:25 .git/비어있는 레파지토리(.git)를 생성하여 버전관리를 하게 된다.
2) git config : commit할 사용자의 정보지정( 이름, 이메일 )
3) git add 파일명 : 수정된 해당파일의 모습이 커밋에 포함될 것이라 지정하는 것
4) git commit : 해당순간의 repository의 모습을 하나의 버전으로 기록
* 커밋을 위해 필요한 2가지 정보
1. 사용자정보(config)
2. 커밋메시지(커밋에 대한 정보) : -m 옵션으로 지정 / 혹은 텍스트에디터로 추가가능
USER@DESKTOP-7IPND5J MINGW64 ~/MathTool (master)
$ git config user.name "rudals"
USER@DESKTOP-7IPND5J MINGW64 ~/MathTool (master)
$ git config user.email "linda284@naver.com"
USER@DESKTOP-7IPND5J MINGW64 ~/MathTool (master)
$ git add calculator.py
USER@DESKTOP-7IPND5J MINGW64 ~/MathTool (master)
$ git add license
USER@DESKTOP-7IPND5J MINGW64 ~/MathTool (master)
$ git commit -m "create calculator.py and license"
[master (root-commit) a40eec7] create calculator.py and license
2 file changed, 7 insertions(+)
create mode 100644 calculator.py* root -commit :: 커밋이 프로젝트의 첫번째 커밋이라는 뜻이다.
- git의 내부영역 3가지
working directory(working tree) : 작업중인 디렉토리
staging area(index) : git add한 파일들이 존재하는 영역 -> 커밋의 대상의 지정(세밀한 버전관리) git status로 확인
repository : working directory의 변경이력들이 저장 ( 커밋들이 저장 ) git log로 확인
- git status : 깃이 인식하고 있는 프로젝트 디렉토리의 현재상태를 보여줌
- changes to be committed (커밋에 반영될 변경사항 ) == stage area에 올라간 상태
- changes not staged for commit ( 커밋에 반영되지 않을 변경사항 ) == stage area에 올라가지 않은 상태
USER@DESKTOP-7IPND5J MINGW64 ~/MathTool (master)
$ git add calculator.py
USER@DESKTOP-7IPND5J MINGW64 ~/MathTool (master)
$ git status
On branch master
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: calculator.py
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: License
USER@DESKTOP-7IPND5J MINGW64 ~/MathTool (master)
$ git add License
USER@DESKTOP-7IPND5J MINGW64 ~/MathTool (master)
$ git status
On branch master
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: License
modified: calculator.py커밋하지 않은 파일을 확인할때 유용하게 이용된다.
- git add . : 현재 프로젝트 디렉토리 내에서 변경사항이 생긴 모든 파일들을 staging area에 추가한다. ( 특정 디렉토리 )
- git add -A : 현재 디렉토리 뿐아니라 하위 디렉토리까지 모두 검사하여 변경된 파일, 새로 생성된 파일, 삭제된 파일 등 모든 변경 사항을 스테이징 영역에 추가한다. ( 전체 디렉토리 )
* git 파일의 상태 2가지
untracked 상태 : 해당파일이 git에 의해서 변동사항이 추적되고 있지 않는 상태 ( ex. 파일생성후 git add를 한번도 수행하지 않음)
tracked 상태 : 해당파일이 git에 의해 변동사항이 추적되고 있는 상태
- staged 상태 : 파일이 수정되고 staging area에 올라와있는 상태( git add된 상태 )
- unmodified 상태(clean) : 현재 파일의 내용이 최신커밋의 모습과 비교했을때 바뀐것이 없는 상태 ( 커밋직후 working directory의 파일들 )
- modified 상태 : 최신커밋의 모습과 비교했을때 조금이라도 바뀐 내용이 있는 상태
- git reset 파일명 : staging area에서 파일제거 ( <-> git add )
옵션을 통해 변경된 내용이 staging area에서는 제거되었지만 working directory에는 내용이 잔류할 수 있다.
USER@DESKTOP-7IPND5J MINGW64 ~/MathTool (master)
$ git add calculator.py
USER@DESKTOP-7IPND5J MINGW64 ~/MathTool (master)
$ git status
On branch master
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: calculator.py
USER@DESKTOP-7IPND5J MINGW64 ~/MathTool (master)
$ git reset calculator.py
Unstaged changes after reset:
M calculator.py
USER@DESKTOP-7IPND5J MINGW64 ~/MathTool (master)
$ git status
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: calculator.py
no changes added to commit (use "git add" and/or "git commit -a")
[ github 시작하기 ]
프로젝트 디렉토리에서 작업하던 내용을 외부의 저장소에 전송한다. ( = repository를 전송하는 개념 )
- 원격 레포지토리( remote 레포지토리 ) : 깃허브의 레포지토리 , 안전성 & 협업가능
- 로컬 레포지토리 : 개별 컴퓨터의 레포지토리
*remote repository 생성방식
1) 로컬레포지토리를 만들고 커밋후 깃허브에 업로드하는 방식
2) 이미 만든 로컬레포지토리를 깃허브에 업로드하는 방식( 기본 브랜치명 main으로 생성 )
git remote add origin https://github.com/rudalsss/Math_Box.git
git push -u origin main리모트 레포지토리 https://github.com/rudalsss/Math_Box.git를 만들고 그 이름을 origin으로 지정했다.
현재 로컬레포지토리의 레포지토리 내용 --> 리모트레포지토리(origin)으로 반영 ( 리모트에 main 브랜치가 없다면 생성하고 전송 )
-u(set-upstream) 옵션 : 이후 로컬레포지토리의 브랜치가 리모트레포지토리 origin의 main브랜치를 추적( tracking )
로컬의 내용을 리모트에 반영할때 반드시 지정해야한다!!!!
* tracking connection : 로컬레포지토리의 한 브랜치가 레모트레포지토리의 한 브랜치와 지속적으로 연결
=> 이후의 push, pull 작업에서 자동적으로 연결되어 동작 ( git push origin 로컬브랜치명:리모트브랜치명 대신 git push로 간편처리 )
*github계정인증은 21년 8월 13일부터 비밀번호를 이용하지 않고 토큰을 이용한다.
1) 프로필사진 > settings > developer settings
2) personal access tokens > generate new tokens > select scopes에서 repo체크
3) generate token
github에서는 연동된 로컬레포지토리의 커밋한 날짜, 횟수를 파악가능 / 구체적인 수정작업 확인가능
README.md : 프로젝트에 대한 설명 -> markdown 언어로 작성, 디자인
- git push : 로컬레포지토리가 리모트레포지토리와 연동된 상태에서 로컬레포지토리에 새로운 커밋내용을 리모트 레포지토리에 반영하는 작업
- git pull : 리모트레포지토리에서 발생한 새로운 커밋내용을 로컬레포지토리로 가져오는 작업
*원칙적으로 자신의 리모트 레포지토리에는 자신만 git push할 수 있음
만약 다른 사용자도 git push를 할 수 있게 해주려면 그 사용자를 해당 리모트 레포지토리의 collaboarator로 지정
( settings > access > collaborators )
- git clone 프로젝트github주소 : 깃허브 프로젝트의 레포지토리를 그대로 복제해서 가져오는 작업. 깃허브의 프로젝트사이트에서 https 주소를 clone해서 가져온다.
USER@DESKTOP-7IPND5J MINGW64 ~
$ git clone https://github.com/numpy/numpy.git
Cloning into 'numpy'...
remote: Enumerating objects: 255247, done.
remote: Counting objects: 100% (2228/2228), done.
remote: Compressing objects: 100% (928/928), done.
remote: Total 255247 (delta 1418), reused 1873 (delta 1273), pack-reused 253019
Receiving objects: 100% (255247/255247), 130.09 MiB | 19.63 MiB/s, done.
Resolving deltas: 100% (200991/200991), done.
[ 커밋 다루기 ]
- git log : 커밋 히스토리( 이때까지 한 커밋들 )를 확인하는 작업( 최신순으로 나열됨 )
커밋아이디(커밋해시) : 커밋작업을 식별 + 작업자 + 날짜 및 시간 + 커밋메세지
git log --pretty=oneline
- git show + 커밋아이디(4자리) : 해당커밋작업의 상세안내
- git commit --amend : 최신커밋을 수정하여 새로운 커밋으로 만든다.( 추가커밋진행X )
자동적으로 커밋 아이디도 변경된다.
USER@DESKTOP-7IPND5J MINGW64 ~/MathTool (main)
$ git log --pretty=oneline
d4e387fb973364e8a80010dddc2207a929beac58 (HEAD -> main) add one function
04eb4ac5dc43e68f94500ae46e0d60ce969b3e09 (origin/main) Make README.md look nice
f1c88ec5fb5a371eacff5ff0c83bb2b26a6c5e5b add the info of calculator.py in README.md
ca4524f871675e83449808bb4cf0f01da986b348 create readme.md
9fdf8b633880d3d93a3fffff9e1957cfaaa9bd58 add title and comment and create meeting-log
ae8303b593d94b42aaab1bfca2854a4bafd3972a create calculator.py and license
a40eec766f70f31f7138929dc9f61eaa77c67525 create calculator.py and license
USER@DESKTOP-7IPND5J MINGW64 ~/MathTool (main)
$ git add .
USER@DESKTOP-7IPND5J MINGW64 ~/MathTool (main)
$ git commit --amend
[main 9b013ad] add multiply function
Date: Sat Nov 11 10:24:45 2023 +0900
1 file changed, 4 insertions(+), 1 deletion(-)
USER@DESKTOP-7IPND5J MINGW64 ~/MathTool (main)
$ git log --pretty=oneline
9b013ad62d06543fc7ccd55ca8dc8b4c2a6a31ac (HEAD -> main) add multiply function
04eb4ac5dc43e68f94500ae46e0d60ce969b3e09 (origin/main) Make README.md look nice
f1c88ec5fb5a371eacff5ff0c83bb2b26a6c5e5b add the info of calculator.py in README.md
ca4524f871675e83449808bb4cf0f01da986b348 create readme.md
9fdf8b633880d3d93a3fffff9e1957cfaaa9bd58 add title and comment and create meeting-log
ae8303b593d94b42aaab1bfca2854a4bafd3972a create calculator.py and license
a40eec766f70f31f7138929dc9f61eaa77c67525 create calculator.py and license
추가커밋없이 기존커밋이 수정되었다. 그리고 커밋 아이디도 변경되었다.
- 커맨드 aliasing :: git config alias.별칭 '작업옵션'
git config alias.history 'log --pretty=oneline'git log --pretty=online 작업을 git history의 한줄로 aliasing하였다.
- git diff 이전커밋아이디 이후커밋아이디 : 두 커밋사이의 변화 알아보기
- HEAD : 어떤 하나의 커밋 ( 보통 가장 최근에 한 커밋을 가르킴 ) --> 해당 커밋으로 working tree의 현모습을 유지
- HEAD^ : HEAD가 가리키고 있는 커밋의 바로 이전 커밋
- HEAD~n : HEAD가 가리키고 있는 커밋보다 x단계 이전 커밋
- +) git tag 태그이름 커밋아이디 :: 해당 커밋에 태그이름을 붙여서 이용할 수 있다.
- git reset : HEAD가 과거의 커밋을 가르키게 할 수 있다. 과거의 커밋 모습으로 돌아가게 한다.
USER@DESKTOP-7IPND5J MINGW64 ~/MathTool (main)
$ git history
9b013ad62d06543fc7ccd55ca8dc8b4c2a6a31ac (HEAD -> main, origin/main) add multiply function
04eb4ac5dc43e68f94500ae46e0d60ce969b3e09 Make README.md look nice
f1c88ec5fb5a371eacff5ff0c83bb2b26a6c5e5b add the info of calculator.py in README.md
ca4524f871675e83449808bb4cf0f01da986b348 create readme.md
9fdf8b633880d3d93a3fffff9e1957cfaaa9bd58 add title and comment and create meeting-log
ae8303b593d94b42aaab1bfca2854a4bafd3972a create calculator.py and license
a40eec766f70f31f7138929dc9f61eaa77c67525 create calculator.py and license
USER@DESKTOP-7IPND5J MINGW64 ~/MathTool (main)
$ git diff ca45 04eb
diff --git a/README.md b/README.md
index f17cd75..308347d 100644
--- a/README.md
+++ b/README.md
@@ -1 +1,3 @@
-### 수학계산을 위한 코드를 제공하는 프로젝트
\ No newline at end of file
+### 수학계산을 위한 코드를 제공하는 프로젝트
+**1. calculator.py** : 계산기에 있는 기능들을 제공하는 모듈
+- add, subtract 등..
USER@DESKTOP-7IPND5J MINGW64 ~/MathTool (main)
$ cat calculator.py
#기본 계산기
def add(a,b):
return a+b
def subtract(a,b):
return a-b
def multiply(a,b):
return a*b
USER@DESKTOP-7IPND5J MINGW64 ~/MathTool (main)
$ git reset --hard 04eb
HEAD is now at 04eb4ac Make README.md look nice
USER@DESKTOP-7IPND5J MINGW64 ~/MathTool (main)
$ git history
04eb4ac5dc43e68f94500ae46e0d60ce969b3e09 (HEAD -> main) Make README.md look nice
f1c88ec5fb5a371eacff5ff0c83bb2b26a6c5e5b add the info of calculator.py in README.md
ca4524f871675e83449808bb4cf0f01da986b348 create readme.md
9fdf8b633880d3d93a3fffff9e1957cfaaa9bd58 add title and comment and create meeting-log
ae8303b593d94b42aaab1bfca2854a4bafd3972a create calculator.py and license
a40eec766f70f31f7138929dc9f61eaa77c67525 create calculator.py and license
USER@DESKTOP-7IPND5J MINGW64 ~/MathTool (main)
$ cat calculator.py
#기본 계산기
def add(a,b):
return a+b
def subtract(a,b):
return a-b
HEAD 변경후 working tree 내부의 상태도 그에 맞게 변화한다.
옵션을 통해 3가지 작업영역 중 어디까지 reset할지 지정할 수 있다.
repository의 상태 변화 발생 but 옵션을 통해 working directory, staging area 에는 저장해놓았던 상태가 남겨져있다.
- git reset --hard 커밋아이디 : 해당 커밋으로 HEAD의 위치변동 / 커밋 이후의 작업이 모두 사라진다.
- git reset --mixed 커밋아이디 : 해당 커밋으로 HEAD의 위치변동 / working directory의 내용은 유지
- git reset --soft 커밋아이디 : 해당 커밋으로 HEAD의 위치변동 / working directory, staging area의 내용은 유지
$ git reset --mixed ca45
Unstaged changes after reset:
M README.md
M calculator.py
staging area에 있던 최신파일들이 reset 때문에 staging area에서 내려왔다 ( mixed 옵션은 repository 상태로 따라간다. )
[ 브랜치 사용하기 ]
- branch : 하나의 코드 관리 흐름
* main 브랜치 : 레포지토리를 만들고 커밋을 하면 자동으로 생기는 브랜치 ( 최소의 코드흐름, 기본 코드흐름 )
프로젝트를 개별적으로 만들지 않고 브랜치를 두어 다른 버전으로 만든다. -> 무료버전과 유료버전 / 모바일버전 PC버전 / 개발버전 배포버전
- git branch 브랜치명 : 브랜치 생성
- git branch -d 브랜치명 : 브랜치 삭제
- git checkout 브랜치명 : 해당 브랜치로 이동
- git checkout -b 브랜치명 : 해당 브랜치를 만들고 이동( 생성+이동 )
- git branch : 현재 레파지토리에 있는 모든 브랜치를 조회
USER@DESKTOP-7IPND5J MINGW64 ~/MathTool (main)
$ git status
On branch main
Your branch is up to date with 'origin/main'.
nothing to commit, working tree clean
USER@DESKTOP-7IPND5J MINGW64 ~/MathTool (main)
$ git branch premium
USER@DESKTOP-7IPND5J MINGW64 ~/MathTool (main)
$ git checkout premium
Switched to branch 'premium'
USER@DESKTOP-7IPND5J MINGW64 ~/MathTool (premium)
$ git status
On branch premium
nothing to commit, working tree clean- branch merge 브랜치명 : 해당 브랜치의 commit 작업을 현재 브랜치에도 반영
** branch conflict : branch간 merge를 수행하다 충돌이 발생 => 두 가지 버전 모두 주석으로 기록됨
- 해결방법 : conflict된 파일을 open -> merge되기 원하는 모습으로 코드를 수정하여 commit
- git merge --abort : merge를 취소, 실행하기 이전의 상태로 되돌림
새로운 브랜치를 리모트레포지토리에 올리기 : 반드시 tracking 정보를 지정해주어야함
USER@DESKTOP-7IPND5J MINGW64 ~/MathTool (main)
$ git checkout premium
Switched to branch 'premium'
USER@DESKTOP-7IPND5J MINGW64 ~/MathTool (premium)
$ git push
fatal: The current branch premium has no upstream branch.
To push the current branch and set the remote as upstream, use
git push --set-upstream origin premium
To have this happen automatically for branches without a tracking
upstream, see 'push.autoSetupRemote' in 'git help config'.
USER@DESKTOP-7IPND5J MINGW64 ~/MathTool (premium)
$ git push --set-upstream origin premium
Enumerating objects: 20, done.
Counting objects: 100% (18/18), done.
Delta compression using up to 8 threads
Compressing objects: 100% (10/10), done.
Writing objects: 100% (11/11), 1.17 KiB | 1.17 MiB/s, done.
Total 11 (delta 5), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (5/5), completed with 1 local object.
remote:
remote: Create a pull request for 'premium' on GitHub by visiting:
remote: https://github.com/rudalsss/Math_Box/pull/new/premium
remote:
To https://github.com/rudalsss/Math_Box.git
* [new branch] premium -> premium
branch 'premium' set up to track 'origin/premium'.로컬의 premium 브랜치에 대응되는 리모트의 premium 브랜치(origin premium)를 구축하고 그 내용을 push한다.
*HEAD와 branch의 관계성 ==> 둘다 pointer : 특정 커밋을 가르킨다.
branch는 매번 새로운 커밋흐름을 가르키면서 이동 , 이전커밋에 대한 정보를 보유
HEAD는 branch를 통해 간접적으로 커밋을 가르킴 , 현재 working directory의 상태를 지정
코드의 관리흐름이 바뀌는 것(checkout)도 HEAD가 가르키는 branch가 달라지는 것이다.
합병하는 것(merge)도 헤드가 가르키는 커밋에(기준) 다른 브랜치의 커밋을 합쳐서 새로운 커밋을 만드는 작업이다.
* git reset과 git checkout의 차이 : HEAD를 브랜치대상으로 이동하는가 커밋대상으로 이동하는가
detached head를 통해 새로운 branch를 생성할수도 있다.
* 두종류의 merge
1) fast-forward merge : 같은 선상에 있는 branch로 빨리감기하는 효과
2) 3-way merge : 다른 선상으로 갈라진 branch를 통합 ( 3요소 :: 공통조상 커밋, 한브랜치 커밋, 다른 브랜치 커밋 )
case1~3 : 변화가 발생한 것을 우선채택!!
case4 : 둘다 변화가 발생하여 conflict가 발생 --> 사용자의 처리 필요
[ Git협업하기 ]
- git fetch: 로컬 레포지토리에서 현재 HEAD가 가리키는 브랜치의 업스트림(upstream) 브랜치로부터 최신 커밋들을 가져옴 ( 이는 가져오기만 한다는 점에서, 가져와서 머지까지 하는 git pull과는 차이가 있음 )
git pull = git fetch + merge - git blame: 특정 파일의 내용 한줄한줄이 어떤 커밋에 의해 생긴 것인지 출력
- git revert: 특정 커밋에서 이루어진 작업을 되돌리는(취소하는) 커밋을 새로 생성
- git revert 시작커밋id..종료커밋id : 사이의 작업을 되돌린다, 여러커밋 취소하기 ( 시작커밋 제외 )
[ Git 자유자재로 활용하기 ]
- git rflog : 헤드가 이때까지 가리켜왔던 커밋정보를 보여준다. --> 최신커밋으로 돌아가기 가능
git reset을 해도 커밋들이 사라지는 것은 아니다. HEAD가 새로운 커밋을 가리키는 것 뿐이다. - git log --all --graph : 모든 브랜치의 커밋 히스토리를 커밋간 관계가 잘 드러나도록 그래프 형식으로 출력
- git rebase 대상브랜치명 : 현 브랜치의 베이스를 대상브랜치로 재지정, 재배치
git rebase --continue : conflict발생하더라도 rebase를 계속 진행해라
두 브랜치가 있을때 갈라진 지점부터 한 브랜치의 커밋들을 다른 브랜치의 최신커밋 이후에 그대로 이어붙이는 형태
**merge와 결과물은 같지만 커밋 구조자체가 바뀐다. ( merge와 달리 새로운 커밋을 생성하지 않음, 더욱 깔끔하다 )
- git stash : working directory에서 작업하던 내용을 git이 따로 보관
최근 커밋 이후의 작업들이 모두 스택에 옮겨지고 working directory 내부는 최근 커밋상태로 초기화
보관구조는 stack( 후입선출 )
-- 작업중 급하게 커밋없이 다른 브랜치로 이동하는 경우
-- 한 브랜치에서 저장된 스택이 다른 브랜치에서도 공유가능( 잘못된 브랜치에서 작업한 결과를 다른 브랜치에서 이용가능 )
- git stash list : 보관 스택의 내용 조회
- git stash apply [식별자] : 보관 스택의 최신 내용을 working directory로 가져와서 사용
- git stash drop [식별자] : 보관 스택에서 작업내용을 삭제
- git stash pop [식별자] : 보관 스택에서 작업내용을 적용하면서 동시에 제거 ( apply + drop )
- git cherry-pick 커밋아이디 : 자신이 원하는 작업의 커밋들만 가져와서 현재브랜치에 추가 -> conflict 처리필요
모든 브랜치의 커밋정보가 있는 git history --all --graph에서 이용
[ GitHub로 협업을 한다는 것 ]
- Commit : 작업내용의 스냅샷, Git에서 관리하는 가장 작은 단위의 버전
commit은 로컬 저장소에 변경내역을 저장, push는 이 변경내역을 원격 저장소에 업로드
- Branch : 독립적으로 작업을 진행하고 결과를 저장할 수 있는 개별적인 흐름
특정 commit을 가리키는 참조(reference)의 형태 = 특정한 버전을 형성
- 일반적인 Git의 작업흐름
1) git pull : 원격저장소에서 최신코드를 받아온다.
2) git checkout -b 브랜치명 : 새로운 기능을 개발하기 위한 브랜치를 생성한다.
3) git add -A : 모든 변경 사항(새로 생성된 파일, 수정된 파일, 삭제된 파일)을 staging area에 추가
4) git commit -m "커밋메시지" : staging area의 변경사항을 커밋하여 작업내용을 스냅샷 생성
5) git push : 커밋한 변경사항을 원격저장소에 푸시하여 공유
[ Pull Request ]
: 다른 GitHub 사용자들에게 자신의 작업한 내용을 검토하고 머지해 달라고 요청하는 GitHub의 기능( Git에서 불가 )
변경 점의 최소 단위인 commit 단위의 기록( feature 단위의 기록)이 PR로 남음
USER@DESKTOP-7IPND5J MINGW64 ~/my-test-repository (my-first-branch)
$ git push --set-upstream origin my-first-branch
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Writing objects: 100% (3/3), 311 bytes | 311.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
remote:
remote: Create a pull request for 'my-first-branch' on GitHub by visiting:
remote: https://github.com/rudalsss/my-test-repository/pull/new/my-first-branch
remote:
To https://github.com/rudalsss/my-test-repository.git
* [new branch] my-first-branch -> my-first-branch
branch 'my-first-branch' set up to track 'origin/my-first-branch'.
commit이후에 발생하는 메시지 링크를 통해서 해당 커밋에 대한 pull request 생성가능
*pull request의 3가지 상태
- open : 아직 검토가 완료되지 않았거나 추가적인 작업이 필요한 상태 / 커밋추가가능 ( 녹색 )
- merged : 소스코드의 기본 branch로 병합된 상태 / 커밋추가 및 변경불가 ( 보라색 )
- closed : 거부되었거나 유효하지 않은 상태( 병합후 종료 ) / open 상태로 다시 돌릴 수 있음
*merge의 3가지 방식( pull request merge에서 선택가능 ) => 코드상의 결과는 동일
(1) merge commit : 두 브랜치의 변경사항을 모두 유지하면서 병합 , 새로운 최종커밋이 추가되어 병합
=> 추적용이, 쉬운이용 but 복잡한 히스토리
(2) squash and merge : 브랜치에서 모든 변경사항을 하나의 커밋으로 압축하여 병합
=> 간단한 히스토리 but 상세하지 않은 이력
(3) rebase and merge : 현재 브랜치를 target 브랜치에 재위치시킨후 병합 / target브랜치의 커밋위에 현재 브랜치의 커밋 옮김 => 깔끔한 선형히스토리 생성가능 but 분기가 많은 경우 복잡성 증가, 충돌가능
브랜치를 사용하는 방식 - 원본 저장소에 직접 접근하여 작업하여 변경사항을 PR로 제안( 팀 프로젝트 )
Fork를 사용하는 방식 - Fork저장소에서 작업하고 원본 소유자에게 PR을 제안( 오픈소스 프로젝트 )
Settings > Branches > Add rule > Require a pull request before merging : 팀원의 Approve를 받지 않으면 머지할 수 없습니다.
GitHub Flow의 핵심은 main / master 브랜치가 항상 배포가 가능하도록 유지 => 리뷰 & 테스트
<GitHub Flow>
- main: 항상 배포 가능하도록 준비된 브랜치
- feature: 새로운 기능을 개발하기 위한 브랜치로 새로운 기능을 개발할 때 main 브랜치에서 분기해 개발을 진행하며, 개발이 완료되면 main 브랜치로 다시 머지된다.
<Git Flow>
feature 브랜치는 항상 develop 브랜치에서 시작해서 develop 브랜치로 병합됩니다.
main 브랜치는 최종적인 프로덕션(production), 즉 배포되는 브랜치를 의미
- release 브랜치
많은 수의 feature들이 동시 다발적으로 개발되게 됩니다. 때문에 다른 팀원들이 개발한 기능이나 수정 사항과의 호환성 문제가 발생
release 브랜치는 항상 develop 브랜치에서 새로운 분기를 생성
release 브랜치를 사용하게 되면, 꼭 우리가 필요로 하는 feature 브랜치들만 병합해서 release 브랜치로 만들 수 있습니다.
===> 모든 메타데이터의 수정과 버그 수정이 완료된 이후에는 main과 develop에 머지
develop-> feature에서 개발 -> develop -> release -> develop, main
- hotfix 브랜치
main 브랜치에서 바로 분기
프로덕션에서 발생한 버그들은 제품에 치명적인 문제를 야기할 수 있고(비용, 매출, 고객 불편 등), 때문에 빠르게 수정돼야 하기 때문
그외
feature 브랜치: develop 브랜치에서 분기해서 develop 브랜치로 머지
hotfix 브랜치: main에서 분기해서 main, develop으로 병합머지
release 브랜치: develop 브랜치에서 분기해서 develop 브랜치와 main 브랜치로 머지
main 브랜치: 영구적으로 존재하며, 다른 브랜치로 머지되지 않음
develop 브랜치: 최초에 main 브랜치에서 분기하며, 이 후 영구적으로 존재하며, 다른 브랜치로 머지되지 않음
'dev tech' 카테고리의 다른 글
| [C++] 디자인패턴 RAII를 이용한 자원관리 (1) | 2024.06.11 |
|---|---|
| Google Test framework의 기본개념 및 사용법 (0) | 2024.05.20 |
| Make 및 Makefile의 개념 및 사용 (0) | 2024.05.20 |
| WSL(Windows Subsystem for Linux)의 개념과 기본명령 (0) | 2024.05.20 |
