[git] 깃 협업하는 방법 (feat. rebase)

내용정리 및 사진추가 필요

김호정

Sep 01, 2024

Contents

브랜치 rebase merge 충돌 해결 (merge conflict)

💡

오늘 배울 것 1. fastforward merge, 3 way merge 2. branch 3. rebase merge

ex01 ~ 03 까지 폴더생성하고 ex01 폴더 열기

vsCode로 열었음

→ Help 옆에 Terminal 클릭하면 하단에 터미널 열림

터미널 오른쪽에 + 옆에 화살표 클릭 → Select Default Profile

상단 검색창 부분에서 “Git Bash” 선택

터미널 다시 열면 git bash 로 잡힌다

++ 그래프 보고 싶으면 VSCode git graph 적용!

Git Graph로 Git 저장소 시각화하기 - VSCode 내 설치법, 사용법

Git Graph로 Git 저장소 시각화하기 - VSCode 내 설치법, 사용법 Git은 현대적인 버전 관리 시스템으로, 프로젝트의 변경 내역을 체계적으로 관리하고 협업을 용이하게 합니다. Git 그래프는 Git 저장소의 구조와 커밋 히스토리를 시각화하는 강력한 도구로, 이를 통해 저장소를 더 효과적으로 이해하고 관리할 수 있습니다. 이번 글에서는 Visual Studio Code안에 Git 그래프 설치하는 방법과, 다양한 기능, 활용법에 대해 살펴보겠습니다. Git Graph 설치법 Git Graph - Visual Studio Marketplace Extension for Visual Studio Code - View a Git Graph of your repository, and perform Gi..

https://lemonlog.tistory.com/22

jhyeok.com

개인적으로 Git을 사용할 때 Sourcetree, GitKraken, Fork 등의 다른 GUI 도구를 사용하지 않고 IDE에 내장되어 있는 Git 기능을 사용하는 것을 선호한다. 처음으로 회사에서 Git을 배울 때 Visual Studio를 사용하여 Git을 배워서 그런 것 같다.

https://jhyeok.com/vscode-git-graph/

git init

사용자 정보 설정

ls -a 깃 폴더 조회

rm -rf .git 깃 지우기

ex01폴더 에서 git 으로 버전관리하고 있는데

gitwork (상위폴더) 에서 관리하면 충돌남. → 그렇게 하면안됨

이 상태로 보관하고 싶으면

변경된 모든 것들을 사진찍어주는 → git add . (현재상태 스냅샷찍음)

ex01 폴더가 내가 찍은 동영상

git init 는 카메라 켰을때 보이는 상태

찰칵하는게 git dd .

. 을쓰면 변경된애들을 다 추적해준다.

찍은 상태에서 또 찍으면 앞에 찍어둔게 없어진다. 사진함과 보관 필요.

사진함에 보관하려면 git commit -m “예쁜태양” (* m은메세지)

파일 생성

add 하고 commit 하고 log 확인

dvcs

vcs

보라카이 창문을 열면 (커텐을 치면) 그게 git init (→ ex01 폴더의 세상을 보는것)

창문 밖(작업환경)을 그대로 스냅샷을 찍는게 git add .

노을이 진다. 근데 그걸 git add . 하면 태양사진이 사라진다.

그래서 태양사진을 사진첩에 git commit 해야한다. “예쁜태양”이라고 저장.

이제 노을 사진을 스냅샷찍는다(git add .)

그리고 그걸 commit 하면 사진첩으로 들어간다 “예쁜노을”

git log를 하면 사진첩을 보여줌

현재 창문밖을 태양사진으로 바꿀 수있을까?

현실세계에서는 불가능하지만

깃세계에서는 사진첩에서 꺼내서 현재 바깥에 태양이 뜨도록 할 수 있따

head 는 가장 마지막 사진을 가리킴. ( → 제일 마지막 사진을 가리키는 커서같은거 )

태양사진으로 돌아간 히스토리가 남는다.

버전관리는 원본데이터가 불변해야한다.

v2 를 삭제하던가 v3를 만들어서 히스토리를 남기던가.

v2를 삭제해서 v1만 남기면 ( v2의 비밀번호를 알수없다) - reset

히스토리를 남기고 v1를 복제해 v3를 만들면 -revert

reflog 폴더안에 모든 히스토리를 revert 처럼 저장한다.

(→ reset 해도 reflog 가면 모든 역사가 다 기록되어 있따.)

자기 해시코드를 이용해서 git reset — hard 를 사용

.git 폴더 내부에 데이터베이스가 있음

reflog 를 확인

예쁜노을로 돌아간다.

reflog를 확인하면 지금까지 한게 모두 보인다 (4개)

💡

깃은 한번이라도 커밋하면 그 커밋으로 복구할 수 있다.

커밋만 하면 어떻게 해서든 복구가 가능하다.

💡

reset 은 hard만 쓰기

브랜치

ex02 열기

git init 해주기 ( 창문 열기 )

잘못치면

ctrl c 가 명령어 → 하던걸 중지해라

로그인도 생성하고 add.하고 commit

💡

새로운 기능을 만들때마다 브랜치를 만드는게 좋다.

맘에 안들면 가지를 쳐내면 되니까.

맘에 들면 그 가지를 그대로 쓰면된다.

브랜치 생성 후 확인

Rebase 아리까리하다.

실습파일 보고 연습하기

나중에 cli 환경에서 명령어를 못쓰기 때문에 툴은 사용하지 말기

브랜치 전환은 체크아웃을 사용

생성후 커밋까지

topic의 header 는 아이디중복체크에

master의 header는 로그인에 있음

master 브랜치로 체크아웃해서 확인하면 master는 로그인까지 밖에 모른다.

맘에 안드는 브랜치를 삭제하려면

git branch -D topic 하면 토픽 브랜치가 삭제된다.

git branch 해서 확인하면 master 브랜치만 있음

가지를 날려버리면 reset이랑 상관없다.

git checkout -b topic 하면 브랜치 생성하면서 거기로 체크아웃 함

내가 마스터라는 가지로 다른 브랜치를 병합하고 싶으면

마스터의 포인터를 토픽으로 옮기면 된다.

// 가지 그림

실제로 “가지”라는건 헤더를 의미한다.

포인터가 한칸 위로 올라갔다.

브랜치 포인터만 이동한게 fastforward merge

두줄인것도 있지만 지금은 한줄

ex03 열여서 회원가입 add commit 로그인 add commit

토픽 브랜치 만들면서 체크아웃

아이디중복체크 만들고 확인.

지금 가지는 1개 !

마스터가지의 제일 끝을 가리키는게 로그인 ( ← 마스터 브랜치 포인터 가 가리키는 것)

토픽 가지의 제일 끝을 가리키는게 아이디중복체크 ( ← 토픽 브랜치 포인터 가 가리키는 것)

마스터 브랜치로 오면 로그인까지만 보인다.

이 상태에서 마스터에서 새로운 걸 만든다.

글쓰기 !

글쓰기라는 가지가 생겨남.

// 브랜치 그림 2

아이디중복체크와 다른길을 갈때 새로운 가지가 생겨남.

→ topic branch를 만든다고 가지가 생기는게 아니라 master와 topic이라는 브랜치가

다른 길을 가면 가지가 생긴다. ( ⇒ 브랜치가 분기된다 )

같은 조상을 두고 따로 양쪽으로 개발이 들어갔으 때 브랜치가 분기된다.

조상으로부터 분기된게

브랜치 포인터만이동하는게 fasterforward merge

→ topic header 를 왼쪽으로 이동하면 회원가입 로그인 글쓰기 만 남는다.

→ master header를 오른쪽으로 옮기면 회원가입 로그인 아이디중복체크만 남는다.

그래서 이럴땐 3 way merge를 해야한다. ( 공통 조상을 가지고 분기되었을때 )

master 가지로 쏙

git merge topic 하면

vr 에디터가 나온다.

shift :

wq 엔터

master에는 글쓰기, 로그인, 아이디중복체크, 글쓰기 4개가 보인다.

머지한것도 볼 수있다.

아이디중복체크(topic 에서 만든것) 이 master의 로그 중간에 들어온다.

커밋의 시간을 기준으로 merge되기때문에 좀 뒤죽박죽 된다.

→ 이러면 로그보기 힘들다.

topic의 로그를 다 뜯어서 master 글쓰기 뒤로 붙여서 로그를 깔끔하게 정렬?할 수 있는게 바로

rebase merge ⇒ “git rebase”

회사문화마다 다르다.

팀원을 신뢰하면 rebase merge를 한다.

rebase merge

위에서 글쓰기를 reset하면 아이디 중복체크가 남아있을 것 같은 찝찝함이 있음

근데 실제 git reset —hard 728cc 하면

아이디중복체크가 깔끔하게 안보이게 된다.

( → 병합이 안 된 상태에서 master 브랜치에 head 가 있으니까)

충돌 해결 (merge conflict)

topic 브랜치로 체크아웃하고 아이디중복체크에 “윗부분” 이라고 내용 적어주고

master로 체크아웃하고 아이디중복체크.txt 생성 ( → 토픽의 그 아이디중복체크랑 파일명 동일하게 )

안에 “중간부분”이라고 써줌

그리고 add . commit 해주고 로그 확인하면

master 브랜치에서는 위의 4 개 로그가 보인다.

topic으로 체크아웃해서 로그 확인하면 위의 4개가 보인다.

💡

같은 파일을 건드려서 충돌나면 깃이 알려준다. 그럼 수정 + 병합 내가 해야함

master 브랜치로 이동해서 git merge topic 해줌 ( → 병합 실행 ! )

병합충돌이 발생한다. ( → merge conflict in 아이디중복체크.txt )

해결 : 위에가서 === 을 찾는다. === 기준으로 아래 위 head 와 topic 을 삭제하고 코드 정렬/수정.

터미널에 보면 master | merging → 아직 머지 안 끝났다.

충돌 난 부분 수정해주고 터미널와서 add . commit 해주면 끝 !

💡

프로젝트가 하다가 충돌나면 깃허브로 가기전에 로컬에서 해결하고 올려야한다!

++ 추가

topic 브랜치로 가보면 아이디중복체크에 “윗부분”은 남아있다.

→ 왜냐하면 윗부분/ 중간부분 이라고 merge 한건 master 브랜치의 파일이기 때문

깃 그래프로 확인하면 위와같다.

rebase 로 다시 들어가면

rebase 도 뭐가 많은데 1개만 먼저 배우자!

토픽을 만들었다고 가지가 2개가 아니라고!!

// 토끼 그림

토픽쪽으로 rebase하면, master줄기는 그대로 남아있는상태에서 토픽 줄기가 뒤로 들어간다.

abcd 순서가 됨

fastforward merge할때는 충돌안난다 (→ 가지가 1개니까)

rebase가 된 상태에서 master쪽으로 merge하면 절대 충돌안남.

기능을 만들때마다 topic을 만듦 ( → t1, t2 … )

rebase 연습

master 브랜치에서

a 만들고 add commit

b 만들고 add commit

로그 확인

topic 브랜치를 만들고 d 만들고 add commit

현재 깃의 줄기는 1개로 a - b (m) - d (t) 이렇게 형성되어있음

master 브랜치로 체크아웃해서 c 파일 만들고 add commit

현재

topic 브랜치는 형상이 a - b - d 이렇게 된다.

master 브랜치는 형상이 a - b - c 이다.

둘이 형상이 달라졌다.

abc

abcdef

abc

→ 1)과 2) 둘 다 형상이 같다. ( → fastforward merge 만 하면 되는 상태 )

abckf

abcd

→ 이건 형상이 다르다 ( → 3 way merge 하기. 근데 그렇게 하기 싫으면 rebase merge 하기 )

만약 abcd 쪽으로 rebase 하면 (abcd 에 checkout) ⇒ abckfd가 됨

💡

뒤에 놔두고 싶은 쪽으로 이동(checkout) 해서 머지하기

💡

rebase 할때는 뒤에 놔두고 싶은 쪽으로 이동해서 하면된다. (checkout) 만약 abckf 와 abcd 가 있는데 둘을 merge 할 때, d가 뒤에 있기를 바라면 abcd 에서 “ git merge abckf “ 하면 된다.

토픽에서 “ git rebase master “

그럼 rebase merge 되어서 토픽은 a- b- c- d 가 된다.

마스터는 a b c

이상태에서 마스터로 ffm을 하면 로그를 깔끔하게 관리할 수 있다.

토픽 가지에서 rebase 로 로그를 정렬/ 정리 한 뒤에 master 에 merge하면

마스터 브랜치 로그를 깔끔하게 관리할 수 있다.

git merge topic 하면 ffm 된다.

// 하트 그림

팀원들은 dev만 신경쓰면 된다. ( ⇒ 계속 개발이 되고 있는곳 )

release 브랜치 → 완료된 v1을 테스트하는 브랜치 → 출시하기 직전에 잠시 사용

다 테스트하고 출시전에 release를 master로 집어넣음.

연결 실패 시

git remote rm origin

git remote add origin 주소

연결 확인

git remote -v

dev로 체크아웃

dev pull 하기

c-topic 브랜치 만들기

파일 작업해주고

일단 커밋까지

A는 git checkout dev ( → dev로 체크아웃 )

git pull origin dev ( → dev에 혹시나 누가 push 했을까봐 pull 받아서 확인)

git rebase dev ( → dev에 누가 push했을 수 있으니 rebase . 만약 충돌나면 local에서 해결. )

git push origin a-topic

그리고 pr 요청해야함.

a-topic 을 dev에 merge 해도 되니 ? 물어보는것

base는 merge 할 브랜치

compare은 내가 만든 브랜치

제목과 내용쓰고

reviewer에 팀장아이디 선택해서 요청

→ 팀장은 pull request 가서 commits 탭 이랑 file changes 확인 후

request changes (다시해), comment (메시지남기기), approve(승인)

merge pull request 는 팀원이나 팀장이나 정해서 하면됨

++ 검색

require approvals 깃허브

( → 팀원들의 approve 를 받아야 pull request 가능하도록 하던가

암튼 pull request 승인 절차를 추가할 수 있음 )

[Github] 깃허브 PR(pull request) 연습 reviewer 관련 내용

상황 설명 개인적으로 issue를 달고 feature/기능명 이름의 branch를 만들어 PR을 날리는 연습을 하고 있습니다. collaborator은 없고 개인 repo이며 public으로 되어있습니다. 원하는 기능 PR의 reviewer를 owner인 나로 설정하여 merge confirm을 하는 것 부연설명 main 브랜치에 protection rule을 적용시킬 수 있어 merge 이전에 reviwer의 수를 지정할 수 있는 옵션이 있길래 1명으로 적용하였습니다. Require approvals(protection ruels -> edit 버튼 -> protection rule의 옵션 중 하나)가 바로 그 옵션입니다. 해당 repo의 contributor이자 owner는 저밖에 없으므로 reviw..

https://blueprint-12.tistory.com/319

[Git] GitHub 팀원들의 Approve를 받아야 Pull Request의 Merge가 가능하도록 만드는 기능 추가하기

개요 현업에서 굉장히 좋았다고 느꼈던 기능이 있어 이번 팀 프로젝트를 진행하며 적용시켜보고 싶었어요. 그래서 그 내용을 공유하려고 해요 :) 규모가 큰 프로젝트일수록 브랜치 전략이 필요하고, 브랜치가 세분화됨에 따라 Pull / Request의 중요성은 더 커져요. 특히 혼자만의 판단으로 Merge할 경우 나중에 큰 문제가 생길 수 있어요. 객관적인 판단을 위해 팀원들의 리뷰와 승인이 있을 때에만 Merge를 진행할 수 있는 제약 조건이 있다면 조금 더 신뢰성 있게 프로젝트가 관리될 수 있을 거예요. 그래서 이 글에서는 GitHub에서 팀원들의 승인이 N개 이상일 때에만 Merge 가능하게 제약을 거는 방법에 대해 이야기 해볼게요. 제약 설정하기 방법은 매우 간단해요. 우선 제약을 생성하기 원하는 Git..

https://jayb-log.tistory.com/314

팀장이 protection rule 설정하는거

GitHub에 올라간 Branch에 Protection Rule 적용하기

Prologue Branch protection rule Branch name pattern Protect matching branches Require a pull request before merging Require ap...

https://devfancy.github.io/Technology-GitHub-Branch-Protection-Rule/

나는 c기능.txt까지 하고 지금

이 상태이다.

c 기능생성 후

c-topic 으로 checkout 후 ,

dev로 rebase 하고

push ( → git push origin c-topic )

그리고 깃허브 가서 pr 요청 to 팀장님

굳!

팀장님이 merge 함!

다시 정리하면

개발할때 무조건 dev 에서 동기화하고 토픽 따야한다.

→ 동기화 안하면 환경변수 세팅한 dev가 온다. 큰 충돌

push 할때 자기 토픽을 push

내가 한번 올리고 나서 자기 토픽에 다시 push 할때 강제 푸쉬 가능

git push -f origin khj

reset 도 자기 브랜치에서만 가능할 수 있다.

강제 push는 dev에 하면 안된다.

💡

프로젝트 시작할 때 , “깃flow”를 메뉴얼로 만들고 프로젝트를 시작해야함

컨벤션을 만들고 나면 지키자.

[FEAT] - 새로운 개발 ( 등록 )

[FIX] - 수정

[REMOVE] - 삭제

[REFACTOR] - 코드 리팩토링

깃허브 서브에서는 토픽 브랜치 지워도 되지만 로컬에서는 지우지말기

깃 컨벤션 참고 (FROM 선생님)

** 검색

브랜치 이름 정하는 법

커밋 로그 컨벤션 만드는 법

깃허브에서 conflict 발견하면

github.dev 로 가서 수정하면된다.

(com → dev 바꾸면 됨)

Contents

브랜치 rebase merge 충돌 해결 (merge conflict)

Collaboration

[git] 깃 협업하는 방법 (feat. rebase)

내용정리 및 사진추가 필요

김호정

Sep 01, 2024

Contents

브랜치 rebase merge 충돌 해결 (merge conflict)

💡

오늘 배울 것 1. fastforward merge, 3 way merge 2. branch 3. rebase merge

ex01 ~ 03 까지 폴더생성하고 ex01 폴더 열기

vsCode로 열었음

→ Help 옆에 Terminal 클릭하면 하단에 터미널 열림

터미널 오른쪽에 + 옆에 화살표 클릭 → Select Default Profile

상단 검색창 부분에서 “Git Bash” 선택

터미널 다시 열면 git bash 로 잡힌다

++ 그래프 보고 싶으면 VSCode git graph 적용!

Git Graph로 Git 저장소 시각화하기 - VSCode 내 설치법, 사용법

https://lemonlog.tistory.com/22

jhyeok.com

https://jhyeok.com/vscode-git-graph/

git init

사용자 정보 설정

ls -a 깃 폴더 조회

rm -rf .git 깃 지우기

ex01폴더 에서 git 으로 버전관리하고 있는데

gitwork (상위폴더) 에서 관리하면 충돌남. → 그렇게 하면안됨

이 상태로 보관하고 싶으면

변경된 모든 것들을 사진찍어주는 → git add . (현재상태 스냅샷찍음)

ex01 폴더가 내가 찍은 동영상

git init 는 카메라 켰을때 보이는 상태

찰칵하는게 git dd .

. 을쓰면 변경된애들을 다 추적해준다.

찍은 상태에서 또 찍으면 앞에 찍어둔게 없어진다. 사진함과 보관 필요.

사진함에 보관하려면 git commit -m “예쁜태양” (* m은메세지)

파일 생성

add 하고 commit 하고 log 확인

dvcs

vcs

보라카이 창문을 열면 (커텐을 치면) 그게 git init (→ ex01 폴더의 세상을 보는것)

창문 밖(작업환경)을 그대로 스냅샷을 찍는게 git add .

노을이 진다. 근데 그걸 git add . 하면 태양사진이 사라진다.

그래서 태양사진을 사진첩에 git commit 해야한다. “예쁜태양”이라고 저장.

이제 노을 사진을 스냅샷찍는다(git add .)

그리고 그걸 commit 하면 사진첩으로 들어간다 “예쁜노을”

git log를 하면 사진첩을 보여줌

현재 창문밖을 태양사진으로 바꿀 수있을까?

현실세계에서는 불가능하지만

깃세계에서는 사진첩에서 꺼내서 현재 바깥에 태양이 뜨도록 할 수 있따

head 는 가장 마지막 사진을 가리킴. ( → 제일 마지막 사진을 가리키는 커서같은거 )

태양사진으로 돌아간 히스토리가 남는다.

버전관리는 원본데이터가 불변해야한다.

v2 를 삭제하던가 v3를 만들어서 히스토리를 남기던가.

v2를 삭제해서 v1만 남기면 ( v2의 비밀번호를 알수없다) - reset

히스토리를 남기고 v1를 복제해 v3를 만들면 -revert

reflog 폴더안에 모든 히스토리를 revert 처럼 저장한다.

(→ reset 해도 reflog 가면 모든 역사가 다 기록되어 있따.)

자기 해시코드를 이용해서 git reset — hard 를 사용

.git 폴더 내부에 데이터베이스가 있음

reflog 를 확인

예쁜노을로 돌아간다.

reflog를 확인하면 지금까지 한게 모두 보인다 (4개)

💡

깃은 한번이라도 커밋하면 그 커밋으로 복구할 수 있다.

커밋만 하면 어떻게 해서든 복구가 가능하다.

💡

reset 은 hard만 쓰기

브랜치

ex02 열기

git init 해주기 ( 창문 열기 )

잘못치면

ctrl c 가 명령어 → 하던걸 중지해라

로그인도 생성하고 add.하고 commit

💡

새로운 기능을 만들때마다 브랜치를 만드는게 좋다.

맘에 안들면 가지를 쳐내면 되니까.

맘에 들면 그 가지를 그대로 쓰면된다.

브랜치 생성 후 확인

Rebase 아리까리하다.

실습파일 보고 연습하기

나중에 cli 환경에서 명령어를 못쓰기 때문에 툴은 사용하지 말기

브랜치 전환은 체크아웃을 사용

생성후 커밋까지

topic의 header 는 아이디중복체크에

master의 header는 로그인에 있음

master 브랜치로 체크아웃해서 확인하면 master는 로그인까지 밖에 모른다.

맘에 안드는 브랜치를 삭제하려면

git branch -D topic 하면 토픽 브랜치가 삭제된다.

git branch 해서 확인하면 master 브랜치만 있음

가지를 날려버리면 reset이랑 상관없다.

git checkout -b topic 하면 브랜치 생성하면서 거기로 체크아웃 함

내가 마스터라는 가지로 다른 브랜치를 병합하고 싶으면

마스터의 포인터를 토픽으로 옮기면 된다.

// 가지 그림

실제로 “가지”라는건 헤더를 의미한다.

포인터가 한칸 위로 올라갔다.

브랜치 포인터만 이동한게 fastforward merge

두줄인것도 있지만 지금은 한줄

ex03 열여서 회원가입 add commit 로그인 add commit

토픽 브랜치 만들면서 체크아웃

아이디중복체크 만들고 확인.

지금 가지는 1개 !

마스터가지의 제일 끝을 가리키는게 로그인 ( ← 마스터 브랜치 포인터 가 가리키는 것)

토픽 가지의 제일 끝을 가리키는게 아이디중복체크 ( ← 토픽 브랜치 포인터 가 가리키는 것)

마스터 브랜치로 오면 로그인까지만 보인다.

이 상태에서 마스터에서 새로운 걸 만든다.

글쓰기 !

글쓰기라는 가지가 생겨남.

// 브랜치 그림 2

아이디중복체크와 다른길을 갈때 새로운 가지가 생겨남.

→ topic branch를 만든다고 가지가 생기는게 아니라 master와 topic이라는 브랜치가

다른 길을 가면 가지가 생긴다. ( ⇒ 브랜치가 분기된다 )

같은 조상을 두고 따로 양쪽으로 개발이 들어갔으 때 브랜치가 분기된다.

조상으로부터 분기된게

브랜치 포인터만이동하는게 fasterforward merge

→ topic header 를 왼쪽으로 이동하면 회원가입 로그인 글쓰기 만 남는다.

→ master header를 오른쪽으로 옮기면 회원가입 로그인 아이디중복체크만 남는다.

그래서 이럴땐 3 way merge를 해야한다. ( 공통 조상을 가지고 분기되었을때 )

master 가지로 쏙

git merge topic 하면

vr 에디터가 나온다.

shift :

wq 엔터

master에는 글쓰기, 로그인, 아이디중복체크, 글쓰기 4개가 보인다.

머지한것도 볼 수있다.

아이디중복체크(topic 에서 만든것) 이 master의 로그 중간에 들어온다.

커밋의 시간을 기준으로 merge되기때문에 좀 뒤죽박죽 된다.

→ 이러면 로그보기 힘들다.

topic의 로그를 다 뜯어서 master 글쓰기 뒤로 붙여서 로그를 깔끔하게 정렬?할 수 있는게 바로

rebase merge ⇒ “git rebase”

회사문화마다 다르다.

팀원을 신뢰하면 rebase merge를 한다.

rebase merge

위에서 글쓰기를 reset하면 아이디 중복체크가 남아있을 것 같은 찝찝함이 있음

근데 실제 git reset —hard 728cc 하면

아이디중복체크가 깔끔하게 안보이게 된다.

( → 병합이 안 된 상태에서 master 브랜치에 head 가 있으니까)

충돌 해결 (merge conflict)

topic 브랜치로 체크아웃하고 아이디중복체크에 “윗부분” 이라고 내용 적어주고

master로 체크아웃하고 아이디중복체크.txt 생성 ( → 토픽의 그 아이디중복체크랑 파일명 동일하게 )

안에 “중간부분”이라고 써줌

그리고 add . commit 해주고 로그 확인하면

master 브랜치에서는 위의 4 개 로그가 보인다.

topic으로 체크아웃해서 로그 확인하면 위의 4개가 보인다.

💡

같은 파일을 건드려서 충돌나면 깃이 알려준다. 그럼 수정 + 병합 내가 해야함

master 브랜치로 이동해서 git merge topic 해줌 ( → 병합 실행 ! )

병합충돌이 발생한다. ( → merge conflict in 아이디중복체크.txt )

해결 : 위에가서 === 을 찾는다. === 기준으로 아래 위 head 와 topic 을 삭제하고 코드 정렬/수정.

터미널에 보면 master | merging → 아직 머지 안 끝났다.

충돌 난 부분 수정해주고 터미널와서 add . commit 해주면 끝 !

💡

프로젝트가 하다가 충돌나면 깃허브로 가기전에 로컬에서 해결하고 올려야한다!

++ 추가

topic 브랜치로 가보면 아이디중복체크에 “윗부분”은 남아있다.

→ 왜냐하면 윗부분/ 중간부분 이라고 merge 한건 master 브랜치의 파일이기 때문

깃 그래프로 확인하면 위와같다.

rebase 로 다시 들어가면

rebase 도 뭐가 많은데 1개만 먼저 배우자!

토픽을 만들었다고 가지가 2개가 아니라고!!

// 토끼 그림

토픽쪽으로 rebase하면, master줄기는 그대로 남아있는상태에서 토픽 줄기가 뒤로 들어간다.

abcd 순서가 됨

fastforward merge할때는 충돌안난다 (→ 가지가 1개니까)

rebase가 된 상태에서 master쪽으로 merge하면 절대 충돌안남.

기능을 만들때마다 topic을 만듦 ( → t1, t2 … )

rebase 연습

master 브랜치에서

a 만들고 add commit

b 만들고 add commit

로그 확인

topic 브랜치를 만들고 d 만들고 add commit

현재 깃의 줄기는 1개로 a - b (m) - d (t) 이렇게 형성되어있음

master 브랜치로 체크아웃해서 c 파일 만들고 add commit

현재

topic 브랜치는 형상이 a - b - d 이렇게 된다.

master 브랜치는 형상이 a - b - c 이다.

둘이 형상이 달라졌다.

abc

abcdef

abc

→ 1)과 2) 둘 다 형상이 같다. ( → fastforward merge 만 하면 되는 상태 )

abckf

abcd

→ 이건 형상이 다르다 ( → 3 way merge 하기. 근데 그렇게 하기 싫으면 rebase merge 하기 )

만약 abcd 쪽으로 rebase 하면 (abcd 에 checkout) ⇒ abckfd가 됨

💡

뒤에 놔두고 싶은 쪽으로 이동(checkout) 해서 머지하기

💡

토픽에서 “ git rebase master “

그럼 rebase merge 되어서 토픽은 a- b- c- d 가 된다.

마스터는 a b c

이상태에서 마스터로 ffm을 하면 로그를 깔끔하게 관리할 수 있다.

토픽 가지에서 rebase 로 로그를 정렬/ 정리 한 뒤에 master 에 merge하면

마스터 브랜치 로그를 깔끔하게 관리할 수 있다.

git merge topic 하면 ffm 된다.

// 하트 그림

팀원들은 dev만 신경쓰면 된다. ( ⇒ 계속 개발이 되고 있는곳 )

release 브랜치 → 완료된 v1을 테스트하는 브랜치 → 출시하기 직전에 잠시 사용

다 테스트하고 출시전에 release를 master로 집어넣음.

연결 실패 시

git remote rm origin

git remote add origin 주소

연결 확인

git remote -v

dev로 체크아웃

dev pull 하기

c-topic 브랜치 만들기

파일 작업해주고

일단 커밋까지

A는 git checkout dev ( → dev로 체크아웃 )

git pull origin dev ( → dev에 혹시나 누가 push 했을까봐 pull 받아서 확인)

git rebase dev ( → dev에 누가 push했을 수 있으니 rebase . 만약 충돌나면 local에서 해결. )

git push origin a-topic

그리고 pr 요청해야함.

a-topic 을 dev에 merge 해도 되니 ? 물어보는것

base는 merge 할 브랜치

compare은 내가 만든 브랜치

제목과 내용쓰고

reviewer에 팀장아이디 선택해서 요청

→ 팀장은 pull request 가서 commits 탭 이랑 file changes 확인 후

request changes (다시해), comment (메시지남기기), approve(승인)

merge pull request 는 팀원이나 팀장이나 정해서 하면됨

++ 검색

require approvals 깃허브

( → 팀원들의 approve 를 받아야 pull request 가능하도록 하던가

암튼 pull request 승인 절차를 추가할 수 있음 )

[Github] 깃허브 PR(pull request) 연습 reviewer 관련 내용

https://blueprint-12.tistory.com/319

[Git] GitHub 팀원들의 Approve를 받아야 Pull Request의 Merge가 가능하도록 만드는 기능 추가하기

https://jayb-log.tistory.com/314

팀장이 protection rule 설정하는거

GitHub에 올라간 Branch에 Protection Rule 적용하기

Prologue Branch protection rule Branch name pattern Protect matching branches Require a pull request before merging Require ap...

https://devfancy.github.io/Technology-GitHub-Branch-Protection-Rule/

나는 c기능.txt까지 하고 지금

이 상태이다.

c 기능생성 후

c-topic 으로 checkout 후 ,

dev로 rebase 하고

push ( → git push origin c-topic )

그리고 깃허브 가서 pr 요청 to 팀장님

굳!

팀장님이 merge 함!

다시 정리하면

개발할때 무조건 dev 에서 동기화하고 토픽 따야한다.

→ 동기화 안하면 환경변수 세팅한 dev가 온다. 큰 충돌

push 할때 자기 토픽을 push

내가 한번 올리고 나서 자기 토픽에 다시 push 할때 강제 푸쉬 가능

git push -f origin khj

reset 도 자기 브랜치에서만 가능할 수 있다.

강제 push는 dev에 하면 안된다.

💡

프로젝트 시작할 때 , “깃flow”를 메뉴얼로 만들고 프로젝트를 시작해야함

컨벤션을 만들고 나면 지키자.

[FEAT] - 새로운 개발 ( 등록 )

[FIX] - 수정

[REMOVE] - 삭제

[REFACTOR] - 코드 리팩토링

깃허브 서브에서는 토픽 브랜치 지워도 되지만 로컬에서는 지우지말기

깃 컨벤션 참고 (FROM 선생님)

** 검색

브랜치 이름 정하는 법

커밋 로그 컨벤션 만드는 법

깃허브에서 conflict 발견하면

github.dev 로 가서 수정하면된다.

(com → dev 바꾸면 됨)

Contents

브랜치 rebase merge 충돌 해결 (merge conflict)