Back-end/ETC

Git Bracnches

Ho's log 2021. 4. 26. 15:38

 

Why git?

1. Version Control -> 최종분 수정

2. Co - Working Tool -> 협업에대한 전달

3. Powerful -Branchimg -> 관심사의 분리

 

Git Overview

Commit 

-> 완전한 상태가 아니라, 부모 커밋이 있어야 한다

 Common Parent

-> Merge 를 하려면 공통부분이 있어야 한다.

Merge

-> 2개를 수정하지 않고 합친다.

Rebase

-> 하나의 흐름으로 생성되지만, 원래 있던 커밋이 뒤에가서 붙는다.

Conflict

->  커밋의 중복되어 겹치는 수정 부분이 있어, 어떻게 할지 모른다.

    - Resovle Conflict -> 수동으로 작업한다

    - Revert -> 사라지는 커밋의 자식 커밋을 붙여주고, 삭제해서, 충돌도 없어고 버전도 관리한다. 

    - Approvr PR Commit -> PM입장에서 모든 커밋을 승인하지 않고 하나의 커밋으로만 깔끔하게 정리한다

 

Co - working with Git 

Braching Strategy 

- 작업하는데 효율이 생김, 하나의 브렌치에 뭐한지 알수있다, 버그가 생기면 범인을 찾을수 있다. 

- 협업 할때는 커밋 을 삭제하면 안된다

Project Remote Local

Orgin에 바로 커밋을 하지못하게 막고, Orgin을 패치한다음 코딩을 진행한다.

 

바로 커밋해버리면 Conflict가 생긴다 (,A, B, C가 겹쳐서 수정을 다해야한다 ) 

 

Orgin에서 가지고 와서 커밋을 수행한다. 

 

체크아웃으로 오리진에서 가지고온 것을 따로 만들어서 원본을 그대로 두고 수정할수도 있다

 

꿀팁

HEAD operator

git reset {HEAD~[숫자], HEAD^^}

 

Git commands - push 

 

 

 

Git commands - rebase

자식 커밋들만 가지고 오고 싶을때, 타켓 브렌치에, 어디서부터!, 어디까지! 

 

 

www.youtube.com/watch?v=MIGliPrUMGE&list=PLgXGHBqgT2TvpJ_p9L_yZKPifgdBOzdVH&index=84

 

'Back-end > ETC' 카테고리의 다른 글

Github 관리  (0) 2021.07.12
API vs LIbrary vs Framework  (0) 2021.05.07
빌드 용어  (0) 2021.05.04
Web Server VS WAS  (0) 2021.05.03
함수형 프로그래밍  (0) 2021.04.28