수업소개
- 고객별로 다른 버전 필요?
-
중복되는 부분에 비효율 발생
-
서로 같은 파일 같은부분을 수정했을경우?
⇒ Branch 필요
-
- 충돌: 같은 파일에 같은 부분을 동시에 수정했을 경우
- git이 수정을 멈추고 수동으로 하라고 요청함
브랜치 기본 사용법
- 처음 생성되는 디폴트 브랜치 :
master - 고객사마다 새로운 브랜치 만들기
왼쪽 브랜치 위치를 더블클릭하면, 해당 브랜치로 체크아웃되고
로컬 저장소의 파일이 그 버전에 맞게 변경이된다………!!!!!!!!!!!!!!!
→ 각 브랜치를 더블클릭하고 파일을 수정하여 커밋하면 각각의 버전을 만들 수 있다.
- 헤드 : 동그라미 있는 부분 (현재 위치, 현재 상태)
- 체크아웃 : 헤드를 옮기는 행위
- 브랜치 삭제하는 방법 : 헤드를 마스터로 옮긴 후, 삭제하고자하는 브랜치 우클릭
→ 삭제 → 강제 삭제 체크 후 확인
Merge
다른 브랜치에서 작업한 내용이 master브랜치에도 유용할거같으면?
base: 합칠려고 하는 브랜치들의 공통의 조상merge commit: 두개의 브랜치를 합친 커밋
서로 다른 파일 병합
누구를 누구한테 병합할것인가?!
순서가 가장 중요
-
병합할 위치의 브랜치로 체크아웃(master)
-
병합 브랜치 우클릭 → 현재 브랜치로 병합
⇒ master branch에서 tutorial의 파일까지 다 갖게 됨
- 파일명 다르면 git이 알아서 붙여줌
같은 파일, 다른 부분 병합
- 방법은 같은
- 파일 하나에 다른 부분 각각 반영되어 바뀜
같은 파일, 같은 부분 병합
- HEAD : 병합하고자 하는 위치의 branch에서 작성한 내용
- ====: 구분선
- tutorial : 다른 브랜치에서 작성한 내용
충돌의 속성(conflict) : 3 way merge
- 2 way merge : 각 행이 함수라고 가정했을 떄, A만 똑같고 나머지는 다르므로 3개는 충돌이 일어남
- 이러한 불편함을 자동화하기 위해 나타난 것 ⇒ 3 way merge
3 way merge
- base : 브랜치가 쪼개져 나갈 때 공통의 조상
- base에서 변경사항이 1가지일 경우 merge에 반영
- base에서 변경사항이 두가지일 경우 conflict
Merge tool
충돌 난 부분 일일히 수작업으로 수정해주기 힘들 때 → 도구 사용
p4merge
마치며..
git flow & git work flow
- 개발자들에게 널리 채택된 모범사례
- 쉽게 적용할 수 있도록 고안된 소프트웨어 : git flow
- 해당 사례들이 표준처럼 업무에 빠르게 집중하는데 도움을 줌
cherry-pick
- 부분적 병합 관련 기능
rebase
- merge와 목표는 같으나 더욱 깔끔하게 할 수있음
- a3을 베이스로, 병합한 것과 같은 효과이지만 깔끔하게 관리 가능
- b2 → a4, b3 → a5부록1: head branch commit & checkout
- HEAD: 기본적으로 master branch를 가리킴
- 헤드를 확인하면 어느 브랜치에 체크아웃 되어있는 지 알 수 있음
- HEAD → master → 따라가면 버전을 확인할 수 있음
- 체크아웃 : HEAD의 값을 변경
- 만약 HEAD가 브랜치가 아닌 커밋을 가리킨다면 detached상태라고 함
- Branch
- Commit
checkout: 헤드를 변경
reset : 버전을 변경 (delete의 성격을 가짐)
