~ 오늘은 3일차 ~
- 목차
1. Branch
2. Merge & Merge Conflict
3. Pull Request
4. Github 자체 기능 활용 (issue, milestone 등)
+ 복기일기
1. Branch
(1) 생성 : git branch (branch명)
(2) 생성 후 바로 전환 : git switch -c (branch명)
(3) 전환 : git switch (branch명)
(4) branch 목록 확인 : git branch --list
(5) 브랜치 삭제 : git branch -D (branch 1) (branch 2)
기타
- master일 경우 main으로 변환 : git config --global init.defaultBranch main
- 현재 git 기록 삭제 : rm -rf .git
- 커밋 로그 : git log --graph --decorate --oneline
ㄴ merge한 과정을 볼 수 있다.
2. Merge & Merge Conflict
(1) Merge
① main에 branch 병합 (main으로 switch한 다음 실행) : git merge (branch명)
② merge 후 add → commit
(2) Merge Conflict
- 같은 파일의 같은 부분을 수정했을 때 발생
- VS코드는 선택하거나 둘 다 선택 가능
! 해결 후에는 add-commit !
- 다만, 보통 Merge 는
Pull Request를 통해서 진행하기에 선택 할 일이 많이 없다.- 애초에 작업을 분담할 때 서로 다른 파일을 담당하도록, 혹은 같은 파일을 작성하더라도 다른 부분을 작성하도록 분담하는 것이 conflict를 방지 하는 것.
(3) fast-forward 와 rebase
- fast-forward 관계 :
main에서 추가 branch 생성 후에 수정 기록이 없을 때, main에 develop의 commit 기록이 바로 병합 - rebase :
커밋 히스토리를 정렬하기 위한 명령어,
main에 수정기록이 있어도 branch가 만들어진 시점으로 main 커밋 히스토리 중간에 병합
- 보통은 non fast-forward 형태로 병합을 진행
- ff일 때 줄기가 나눠진 형태로 merge하고 싶을 경우 : git merge develop --no-ff
3. Pull Request
- 보편적인 branch의 구성
main: 사용자가 이용할 서비스의 코드가 담기는 브랜치, 해당 브랜치에 있는 코드가 사용자에게 배포
develop: 배포 전 모든 기능 통합
feature: 기능을 분할해서 각각의 기능 구현
- github repo에서 진행
상단에 떠있거나,pull request로 가서 새로 생성할 수 있다.
(1) Pull Request 작성
작성 시 들어갈 내용
- 현재 PR 요약/개요
- 코드 변경 이유 (작성 이유)
- 관련 스크린샷
- 테스트 내용
- 리뷰 관련 요청사항
(2) files changed에서 코드리뷰 및 approve
①
start a review-> 코드의 여러 부분에 대해서 코멘트를 작성
② 우측 상단의finish your review
③approve체크 후submit review
-> 본인의 것은 approve 안됨
④merge pull request-confirm merge-delete branch
-> 보통 주니어 개발자가 누를 일은 없음
(3) local 반영 (git fetch —prune)
- pull request 가 merge 된 이후 & git pull 전
① 우리 컴퓨터가 github 상에서 해당 브랜치들 삭제한 것 인식 하도록 가지치기 : git fetch --prune
② 로컬 브랜치 삭제 : git branch -D (branch 1) (branch 2)
③ git pull origin main 진행
4. Github 자체 기능 활용 (issue, milestone 등)
issue,milestone등은 이름과 형식을 통일해 주는 것이 좋다.
(ex: Feat: Add feature/name)- 보통
issue명을 branch명으로 통일한다.
(1) issue 작성
- 내부 내용은 개요, 세부사항을 넣어준다.
- 세부사항에는 - [ ] 로 체크리스트를 만든다.
①
Assignees-> 해당 작업을 담당할 사람
②label-> 해당하는 카테고리
③milestone-> milestone 지정
(2) pull request에서 issue 활용
- 개요와 이슈번호를 넣어준다.
- Close를 넣어주면 merge 후 자동으로
issue가 완료된다.##개요
##이슈번호
Close (이슈번호 ex: #4 )
(3) wiki의 활용 가능 범위
- 업데이트 사항
- 서비스 소개 (readme.md 에 다 적지 못한 부분 등)
- 서비스 기능
- 매뉴얼 (개발자 혹은 사용자를 위한)
- 해당 프로젝트에 기여하는 방법 (how to contribute)
(4) Github Pages
- new repo 작성 시 레포네임에 (유저명).github.io을 작성해서 정적 배포가 가능
ex) https://sky-pey.github.io/
(5) github actions
-
repo 에서 특정한 이벤트가 발생했을 때 자동으로 특정한 작업이 실행되도록 하는 기능
-
배포, CI/CD (자동 빌드 및 자동 배포), 테스트 등이 가능
+ 복기일기
문제점 복기를 시작해보자.
오늘은 그래도 온라인 강의와 강의 자료 예습으로 어느정도 숙지하고 시작해서 어제보단 허둥거리는 게 덜해졌다.
터미널도 PowerShell에서 Git Bash로 바꾸고 나니, 윈도우에서 먹히지 않는 명령어 rm -rf .git 등이 실행되면서 진도를 따라가기가 쉬워졌다.
에러가 난 부분은 팀과의 협업 실습에서 발생했다.
에러는 타 팀원에 의해 발생했고 마무리 작업을 내가 진행해야 하면서 직접 처리해볼 기회가 생겼었다.
결론부터 말하자면 수습을 실패해서 강사님이 직접 해주시고 갔다.
오류 내용과 해결 과정은 다음과 같다.
- 에러 1
branch를 만들고 난 다음 pull request를 진행해야 했는데 push로 main에 바로 들어감.
-
에러 2
내가 가지고 있는 main에서 reset을 진행했는데 어떤 문제로 제대로 해결 되지 않음.
-> 제대로 된 루트를 실행하지 않은 것으로 보인다. -
해결 과정
강사님이 revert를 해보라고 했지만 이미 reset한 상태라 돌아갈 commit이 없는 상태가 되었고,
git push -f origin main으로 해결이 되었다.
git push -f 는 강의 내용에 없었는데 아무래도 강제로 하는 push이고 잘 사용하지 않다보니 내용에 포함되지 않은 것으로 보인다.
해당 에러가 났을 때,
어떤 걸 해야할 지 아직 판단이 되지 못해서 강사님이 reset과 revert를 코칭해주셨다.
분명 어제 배운 내용임에도 막상 문제가 났을 때 떠올리지 못한 게 아쉽지만 그래도 이번 일을 통해 다음에 이런 문제가 난다면 떠올릴 수 있을 거라 확신이 든다.
실습 내용을 들었을 때는 너무 간단한 내용이 아닌가 싶었지만 확실히 협업을 할 때는 어떤 에러가 날지 모른다는 걸 몸소 깨달아 재밌었다.
비록 아직까지 velog를 복습 목적으로 강의 내용을 요약하고 약간의 복기 일기로 쓰고 있지만,
나중에는 요약보다는 기술 복기가 주로 되었으면 하는 필자의 소소한 바람이 있다.
