충돌conflict라고 알려준다.
둘 중에 어떤 내용을 반영할까?
issue누가 이 작업 할 것인지 정한다.
프로젝트에서 해결해야 하는 문제(버그 신고, 개선 제안, 할당..)
이러한 문제들을 해결하는 작업 단위- 각자 맡은 것을 작업한다. (나의 작업 공간 branch)
- 각자 작업을 프로젝트에 합칠(merge) 수 있게 공유한다.
- 작업한 내용을 리뷰(코드 리뷰)하고 최종적으로 프로젝트에 반영한다. PR 후 merge
issue 먼저 만들어서 할당
현업에서, 프로젝트 설계: 내가 할 작업, 기능 추가, 버그 리포트, 할당
- 무엇을 작업할지
- 어떻게 작업할지 논의한 뒤
- 작업
branch
main에서 갈라져 나와서 작업할 공간 나눈다.
각자 맡은 것을 작업할 때 or 기능별로 이름 만들어 주기.
브랜치 삭제는 다른 브랜치로 체크아웃한 상태에서 가능하다.
삭제할 브랜치 오른쪽 클릭 > 삭제 (강제 삭제)
체크아웃 : 작업할 브랜치로 바꾸는 것
merge 합병
브랜치 단위로 합병
main 브랜치을 정해 놓고, 다른 브랜치를 merge.
feature/jeon
feature/rice
Flow (commit하고 작업하는 방식)
브랜치 만들기
갈라져 나오고자 하는 ver.에서 오른쪽 클릭 >
다시 메인 브랜치로 체크아웃 >
feature/ 하위 폴더로 생김
3개 앞 원격r과는 다르게 로컬r에 n개의 commit이 더 생겼다. (차이)
origin/main 원격r의 상태는 여기에 있는 것. (push 전이라)
병합할 브랜치(ex main)에 체크아웃(ㅇ) 하고 병합 클릭.
jeon 먼저 병합하기
branch tracking
로컬r ---(tracking)--- 원격r
tracking의 단위가 branch다.
main 브랜치와 origin/main 브랜치가 트래킹되어 있는 것.
특정 브랜치를 push, pull하는 것.
commit history에 보이는 origin/main 이름표는 원격repo의 main 브랜치 라는 뜻입니다. 원격repo 를 연결할 때 origin이라고 적었기 때문에 앞에 origin이 붙습니다.
기타
- stackoverflow
- 기술블로그
- Git 기술공식문서 좋은 자료
충돌 해결하기 merge conflict
그러나 컴퓨터 프로그래밍을 배울 때 처음부터 잘하지는 못한다. 능숙한 프로그래머가 되려면 능숙하게 '버그'를 찾아내고 수정하는 법을 익혀야 한다. 프로그래밍을 하면서 던져야할 질문은 이것이 맞느냐 틀리느냐가 아니라 버그를 수정할 수 있느냐 없느냐다. 이런 식의 지적 결과물을 바라보는 방식이 지식과 지식 습득을 대하는 좀 더 큰 문화에까지 보편화된다면 우리 모두 '틀리는 것'을 덜 두려워하게 될 것이다.
- 마인드스톰 mindstorm (시모어 패퍼트 지음.인사이트.이현경 옮김) -
충돌 발생시에는 충돌 내용만 조정하여 commit하고
그 다음에 다른 새로운 내용을 commit하는 게 의사소통에 도움이 된다.
