![[git] 깃 협업하는 방법 (feat. rebase)](https://image.inblog.dev?url=https%3A%2F%2Fsource.inblog.dev%2Ffeatured_image%2F2024-09-05T15%3A10%3A01.442Z-27882639-cadb-49dc-a464-4075673dd575&w=2048&q=75)
오늘 배울 것
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 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 이다.
둘이 형상이 달라졌다.
++
1)
abc
ab
2)
abcdef
abc
→ 1)과 2) 둘 다 형상이 같다. ( → fastforward merge 만 하면 되는 상태 )
3)
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 관련 내용](https://t1.daumcdn.net/tistory_admin/favicon/tistory_favicon_32x32.ico)
![[Github] 깃허브 PR(pull request) 연습 reviewer 관련 내용](https://img1.daumcdn.net/thumb/R800x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FdDnsnP%2FbtrYvmL3YDb%2FenBwo1yjHZ2KKXUwDjZ0A0%2Fimg.png)
![[Git] GitHub 팀원들의 Approve를 받아야 Pull Request의 Merge가 가능하도록 만드는 기능 추가하기](https://img1.daumcdn.net/thumb/R800x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FFlERJ%2FbtrqT1tCQVR%2FU9iOgeBAXdZj3xnsl2Vuhk%2Fimg.png)
++
팀장이 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 바꾸면 됨)
Share article
![[JavaScript] 자바스크립트 ( + 1급객체, CSR, 람다식 != 람다표현식 )](https://image.inblog.dev?url=https%3A%2F%2Fsource.inblog.dev%2Ffeatured_image%2F2024-09-05T15%3A12%3A31.290Z-a1c901fc-f102-49a1-8d9f-5680529f4d51&w=750&q=75)
![[HTML&CSS] 에어비앤비 메인페이지 만들기](https://image.inblog.dev?url=https%3A%2F%2Fsource.inblog.dev%2Ffeatured_image%2F2024-09-05T15%3A06%3A59.354Z-d7babc69-cc4e-466c-9cdb-a350ed3dd5c4&w=750&q=75)
![[Springboot] 16 리팩토링 마무리, 더티체킹, AOP](https://image.inblog.dev?url=https%3A%2F%2Fsource.inblog.dev%2Ffeatured_image%2F2024-08-26T08%3A11%3A21.508Z-f2566645-6aa3-4946-a2c3-dad9792772c0&w=750&q=75)
![[Springboot] 15 예외처리 및 코드 리팩토링 ~ing](https://image.inblog.dev?url=https%3A%2F%2Fsource.inblog.dev%2Ffeatured_image%2F2024-08-23T13%3A35%3A27.780Z-d1908883-e0d5-4c4d-9504-082bc847b582&w=750&q=75)