협업을 위한 순서
1. branch
자신이 맡은 기능별로 브랜치를 생성한다.
main : master 브랜치. 최종 브랜치
develop : 각 feature 브랜치들을 merge 할 브랜치 = 테스트 용 main 브랜치
feature : (일반적으로) 각 기능별로 구분짓게 될 브랜치
예시)
main 브랜치
develop 브랜치
feature/board, feature/comment, feature/login ... 브랜치
1)
처음 repository 를 생성해서, main 브랜치만있는 상태
(main 브랜치에 아무 파일도 없으면, main 브랜치가 있다는 표시조차 뜨지 않는다.)
2)
main 브랜치를 볼 수 있도록 임의로 파일을 넣음.
(실제로는 README 파일을 넣으면 되겠다.)
2. issue
1)
이슈를 생성한다.
2)
3)
issue & commit
- 깃허브에 위와 같은 방법으로 이슈를 생성하고 나면, 각 이슈마다 자동적으로 번호가 붙는다.
- commit을 할 때 커밋 메시지와 함께
#4를 넣어주고, push까지 완료한다.
(issue 한 개 : 이슈번호 한칸띄고 커밋메세지 작성)
(issue 여러개 : #2 #3 #4 #5 )
- 깃허브에서
#4를 누르면 해당 이슈로 이동할 수 있도록, 이슈와 연동된다.
3. commit
커밋할 브랜치에 체크아웃을 해두고,
새로운 파일을 해당 브랜치에 커밋한다.
주의!
commit 후 push를 하지 않고(원격 레포지토리에 있는 원격 branch에 올리지 않고)
다시 commit을 할 경우즉, comiit을 2번 연속 할 경우
마지막 커밋 메시지의 내용으로 원격 레포지토리에 기록된다.
4. push
1)
2)
두 곳 모두에서 Pull Request 확인 가능 (일명 PR)
3)
4)
다른 팀원들이 나의 PR 요청 결과(코드)를 확인하고,
모두 확인이 끝났다면 'Merge pull request'로 merge 요청을 보낸다.
(merge 까지 됐다면, 해당 pr 요청은 이제 필요없으므로, 'close pull request'로 삭제해주면 된다.)
이 과정에서 'Merge pull request' 대신 conflict 가 뜰 때가 있다.
다른 팀원이 올린 파일과 충돌이 발생해서 나타난 것이므로, 충돌한 부분을 수정하면 merge 가 가능하다.
tip. 브랜치 default 변경하는 방법
1. setting 들어가기
- 변경된 것을 확인 가능
push 이후의 branch 처리는?
나의 로컬 브랜치 → 나의 원격 브랜치 로 push 를 하고,
상위의 브랜치(예시: main) 에 merge 한 이후에는
나의 로컬, 원격 브랜치를 삭제해준다.
4. pull
특정 기능을 완료할 때마다 각자의 branch 를 상위 branch 에 merge 를 해뒀다.
merge 이후의 나의 브랜치를 제거하고나서는
merge 한 상위의 브랜치에서 pull로 나의 컴퓨터의 폴더로 당겨온다.
