2시간은 제발 이해하자

git flow 나 github flow 나 둘다 원칙은 master는 항상 실행 가능한 상태 여야 한다

 

git flow는 develop branch를 채택해서 여기서 일상 적인 작업을 한다

gut checkout -b develop

새로운 기능을 작업할 때는

git checkout -b feature/login 

feature는 기능이 아니라 그냥 접두사로 사용

 

feature branch 에서 끝나면 develop으로 보내고

어느 정도 작업이 완료되면 release branch로 보냄

git checkout -b  release/1.0

 

release branch에서는 작업을 추가하는게 아니라 release에 필요한 작업을 추가한다

근데 release에 있는건 개발에 중요하기 때문에 자주자주 develop branch로 가져와야한다

 

release 작업이 끝나면 release branch를 master branch와 병합

그리고 master 에서 tag를 만듬

 

커밋을 카르키는 레퍼런스 tag, head,branch

 

ex)

head가 가르키는 branch는 동적이다

git tag 1.0

tag는 정적이다 (절대 안 움직임) -> 그래서 기념을 하고 싶을 때 tag를 박음

 

요약 : tag = "commit에 이름을 붙이는 것"

 

그래서 언제 든지 checkout으로 버전을 바꿀 수 있다

 

hotfix는 하나만 빠르게 수정을 하기위해 만듬 (긴급수정 느낌)

끝나면 master와 develop에 병합을 해야한다

 

 

branch 삭제

git branch -d branch이름

 

fast forward 막는 법

git merge --no-ff branch명

merge commit을 강제로 만들어줌(뭐가 바뀌었는지를 보고 싶어서)

그 다음 branch를 버리면 된다 (포함이 되니깐)

 

=======================마지막 1시간===========================

complete상황 정리

다음과 같은 상황 만들기

e2로 바꾸고

 

어떤 이유에 의해 master가 E2만 병합하고 싶을때가 있음

 

초기상황

 

화살표의 변화를 동그라미에 가하고 싶다

즉,  1 e2 m3 m4 를 만들고 싶다

B 라고 적은 놈이 base 가 되면 된다

 

이걸 cherry pick이라고 한다

 

 

<실습>

자꾸 예전으로 가야하니깐 tag를 박아버리자

 

이렇게 만들면 reflog 만지작 안해도 된다

git checkout master

git cherry-pick E2의 commit id

다른 상황도 가정해보자

이렇게 체리픽한다면??

1 e2 m3 ?(e4,m4 conflict)

 

목표

부분병합을 시킴(cherry pick)

 

그럼 rebase는 무엇일까

 

실제로는 이렇게 되는 건데 이러면 너무 복잡해 지자나 ㅠㅠ

그래서 거짓말을 하는 거임

master가 이렇게 했다고 조작을 해버림

근데 마지막에 있는건 e2,e4가 없는걸.... ㅠㅠ

 

rebase를 하게되면

1. head가 e를 가르키고

2. 화살표의 변화를 e에 cherry pick 한다

3. head 이동 

다음 화살표의 변화를 head가 가르키는 거 한테 적용

conflict 해결하고 master를 옮겨준다

그 다음 head 가 master를 바라봄

다음과 같이 삭제 된 효과가 난다

밑에 같은 효과를 낸다

어렵긴함...

그러므로 merge와 rebase는 결과는 같다

merge : 진실, 엉망

rebase : 거짓, 단순

M3까지는 잘 되었는데 M4에서 충돌이 났다

git add common.txt

git rebase --continue

master가 새로운 버전을 가르킴

 

 

 

 

 

===========염성현 캠퍼님 정리==============

reset 은 내 컴퓨터에 있는 version에 한해서만!

 

.vscode와 같은 (개인) 설정 파일은 git -> info -> exclude에 넣어 사용할 수 있다.

 

config.txt.template 중요 정보가 담긴 config를 공유할 수 없으니 형식을 공유, 암묵적 약속

 

https://www.toptal.com/developers/gitignore

- 이근호 파일 자동 생성 웹페이지

 

https://www.youtube.com/watch?v=wVUnsTsRQ3g

- 생활 코딩 conflict 링크

 

원격 repository 생성 시 ignore 세팅 가능, read me 세팅 가능

 

 

git clone - 원격 저장소를 로컬에 복제

 

git clone 원격 저장소 주소 (+) . (현재 저장소, 생략 가능, 다른 저장 위치로 설정 가능)

 

git push -u origin(원격) master(로컬) 

- 원격 저장소와 페어링(원격 저장소를 tracking함) 후 push

- -u == --set-upstream

 

https://www.git-scm.com/docs/git-push

 

git pull = git fetch + git merge origin(원격)/master(로컬)

 

같은 이름의 branch로도 git은 원격 저장소의 branch와 지역 저장소의 branch를 서로 다른 branch로 취급한다.

 

git rebase - commit을 조작, 이따가~

 

삼단 콤보 - 작업할 때 git pull 하고 commit 하고 바로 push 한다.

 

 

branch 전략

- branch를 적극적으로 사용해서 project를 체계적으로 관리

- git flow / github flow 등

 

- git hub flow 전략(아래)

  - master는 언제나 실행 가능하고 테스트 가능해야 한다.

  - 새로운 기능을 추가할 때는 branch를 만들어 pull-request로 merge

 

- git flow 전략(아래)

  - https://techblog.woowahan.com/2553/

  - develop 브랜치로 일상 작업 / feature 브랜치로 기능 추가 

  / release 브랜치로 출시 준비 (출시에 필요한 작업만 수행) develop으로 자주 합쳐라!

  / release 브랜치 작업 내용을 master 브랜치로 병합 - Tag를 만듦, Tag로 checkpoint(* 비유임)!!

  / release 작업 내용은 중요한 작업 내용이기 때문에 develop으로도 명시적 병합을 해야함

  / hotfix 긴급 수정 사항, master에서 만들어 작업 후, develop과 master로 병합

  - 참고 사이트 : https://danielkummer.github.io/git-flow-cheatsheet/index.ko_KR.html

 

(* git tag 태그이름 - 태그를 단다)

head, branch - 움직이는 reference

tag - 움직이지 않는 reference

commit 에 이름을 붙인 것 : tag

 

로컬 branch를 만든 후 push --set-upstream 브랜치명

-> 원격 branch 생성 및 연결

-> master로 checkout

-> master에서 로컬 branch merge? -> merge commit 생성되지 않음 (master가 별도로 작업한 게 없기 때문)

-> fastforward (따로 merge commit 필요 없이 master가 로컬 branch와 동일 version으로 이동, 변경 사항 반영)

 

* git merge --no-ff 브랜치명 - fastforward 못하게 하는 명령, merge로! (병합을 명시하기 위해, flow 확인 수월)

* git branch -d 브랜치명 - 브랜치 삭제

* 명령어 ; 명령어 로 명령어 한번에 입력 가능

 

 

pull-request

- merge-request가 이해 더 잘 될 듯

- 여러분의 branch를 master로 합쳐달라는 요청

-> branch를 만든 후 원격 저장소에 push

-> 원격 저장소에 pull request 등장 == 내가 만든 브랜치를 마스터에 병합하도록 승인 요청

-> 코드 비교, 기능 설명 

    assignees - 담당자

    reviewers - 코드 리뷰를 맡김

-> Create pull request (pull request 신청)

    conversation : 종합적인 timeline

    (* merge 되기 전의 push 변동 사항은 자동으로 업데이트된다.)

    file changed : 해당 branch에서 변경된 내용들을 보여줌

    - + 버튼을 통해 line 별로 comment를 달 수 있다(add single comment).

       start a review는 여러 파일에 걸쳐서 리뷰를 달 수 있다.

       -> finish your review로 작성 완료

* .을 누르면 웹 버젼 VS code를 열어준다.

-> 병합의 두 가지 방법

    - 책임 있는 사람이 Merge pull request를 누르는 방법 -> confirm merge

    - local 에서 git checkout master로 가서 merge(fast-forward) 후 push

-> 1번 방법(원격 저장소 제어) 후 로컬에서 git pull -> fast-forward!!

 

서로 다른 branch에서 같은 파일을 작업, pull request

-> git 원격 저장소에서 conflict를 감지하고 그것을 알려줌

-> local에서 conflict 해결 후 push / remote에서 resolve

-> merge pull request

 

git push - 로컬의 변화를 반영해줘~

git pull - 원격의 변화를 가져와줘~

 

 

git config --global core.editor "code --wait"

- vs code를 터미널에서 키는 명령어

 

 

cherry pick - 하나의 version 만 가져오는 것, 부분 병합

git cherry-pick (원하는 version의 commit id) -> 부분 병합

 

rebase

- git rebase 로컬 branch명

- 타임라인의 복잡성을 해결

ex)  head가 exp(로컬 브랜치)를 가리키는 상황에서

      m3(master 브랜치의 중간 version) 변화를 cherry pick해서 exp에 반영

      -> 새로운 (가짜) version이 만들어짐 / 최종 version 까지 이를 반복, conflict 발생 가능

      -> (가짜) version에 m4(master 최종 version) 변화를 줌, conflict 발생 가능

      (-> conflict 발생 시, 해결 후 git rebase --continue 커맨드로 지속)

      -> 그 후, master를 (가짜) version의  최종 상태로 이동

      -> head가 master를 가리킴, 중간 version이 삭제된 효과, log 간략화

      -> 끝 

- 익숙해지면 쓰세요

- merge : 진실, 엉망 / rebase : 거짓, 단순

- merge 대신 rebase를 써서 log 단순화

 

revert

- git revert commit id

- 특정 commit을(변화를) 지움, 특정 commit의 version을 base로 3자 대면 (이전 commit의 version과 현재 version)

- 삭제하고 이력을 남김

- push해서 원격 저장소에 반영 가능

- conflict 발생 가능