1. 세팅 후 github에 push
2. 다른 브랜치(a-topic)를 만들어서 작업 후 해당 브랜치에 push하기
git checkout -b [브랜치명] : 해당명의 브랜치를 만들면서 체크아웃한다.
새로 만든 브랜치에 push하기 : git push origin a-topic
3. compre & pull request 요청
이 경우 맨 위에 [ compare & pull request ] 버튼이 생긴다. 이 버튼은 master에게 merge를 요청하는 승인요청 같은 것이다.
버튼 클릭 후 request를 보내면 master merge권한을 가진 사람에게 메일이 보내진다. (request 메일을 받으려면 settings-email notifications을 설정 후 setup을 해야 받을 수 있다.)
pull request : 진짜 merge 요청
draft pull request : merge가 되지 않는 요청. 중간코드를 확인해 달라는 용도로 자주 쓰인다.
request를 보내면 pull request 알림이 뜬다.
4. merge하기
권한을 가진 사람은 Commit에서 코드를 보고 확인이 끝난 뒤 merge를 할 수 있다.
Create a merge commit : 해당 브랜치의 로그가 그대로 merge 됨
Squash and merge : 모든 로그를 압축해서 하나의 로그로 만들어 merge 함
squash and merge를 선택한 뒤 log제목을 붙여주었다. (merge가 되었다는 것을 알 수 있도록 앞머리를 구분되게 붙여주자.)
마스터에 merge된 것을 확인할 수 있다.
5. merge가 안 된 master 브랜치에서 b-topic 생성하여 작업하기
🔔 b-topic을 다른 장소에서 이어 작업할 경우
: 해당 브랜치 만들어서 pull하고 시작하기
- 반드시 해당 브랜치를 만들어 pull해와야 한다. 그렇지 않을 경우 master나 다른 브랜치에 b-topic의 로그가 저장될 수 있다.
- git log를 확인해보면 b-topic 브랜치만 있는 점을 확인할 수 있다.
6. b-topic을 작업완료 후 request 요청하기
🤔 이 경우 master와 b-topic의 형상이 다른데 어떻게 merge가 되는 것일까?
💻 자동으로 compare(비교)하여 (master 브랜치를) pull 한 뒤 request(push요청)을 해주기 때문에 가능하다. (이를 PR요청 이라 부른다.)
따라서 conflict가 날 경우에만 conflict를 해결해주면 된다.
❗️ request 요청을 할 때에 base 브랜치를 merge할 브랜치로 설정해줘야 한다. 다른 브랜치로 설정하는 실수를 하지 말자!!
7. 승인거절의 경우 comment 남기기 or merge하기
github issue 관리
이슈가 생기면
- 이슈에 이슈 등록하고
이슈 책임자는
- Master를 내려받고
- a-hotfix 브랜치 만들어서 수정후 푸시
- PR 요청하기
승인 후 merge되면 merge 한 사람은
- Close Comment 하기
이슈에 대한 comment를 달고 싶으면
- close comment가 아닌
- 초록색 comment를 누르면 된다.
