😀 Github로 협업을 한다는 것
❤️ GitHub 훑어보기
: 깃허브는 단순히 원격 저장소의 역할을 넘어 개발자들이 소통하고 협업하는 중추적인 플랫폼이다.
-
Organization
: 팀을 만들기 위한 기능
-> 프론트엔드와 백엔드와 같이 다양한 영역으로 나눠진 저장소를 한데 모아, 프로젝트 관리를 간소화 -
Teams 기능
: 목적에 따라 그룹화 -
Issues
: 버그 리포트, 기능 요청등을 다른 사용자들과 공유하고 토론 -
Pull Request
: 다른 사용자들에게 자신이 작업한 코드 변경 사항 검토하고 병합해달라고 요청하는 기능
-> 의견을 주고받으며 다른 사람들과의 협업 및 코드 리뷰를 통해 프로젝트의 품질 향상을 이끌어낼 수 있음 -
Code Reviews
: PR을 통해 다른 사람들이 작업한 코드를 검토하고 피드백을 주고받음
-> 품질 향상시키고, 버그 예방
-> 서로의 코드 검증하고 개선하여 더 견고하고 효율적인 코드 개발 가능
😀 Pull Request
❤️ Pull Request 란? (PR)
: 다른 팀원들에게 자신이 작업한 내용을 검토하고 머지해달라고 요청하는 기능
-> 더 효율적이고 품질 높은 코드 작성 가능
개인 프로젝트
: PR사용하지 않고 머지하면 복구 어려운 반면, 사용하면 기록이 remote에 남게 되어 실수한 경우 쉽게 되돌릴 수 있음
팀 프로젝트
: pr의 장점은 팀 프로젝트에서 더욱 두드러진다. 프로젝트의 투명성을 높어주고, 작성자의 의도를 쉽게 파악할 수 있게 해줌. PR 통해 코드의 작성 배경, 목적, 주요 내용을 문서화
PR의 3가지 상태
-
Open : 아직 검토 완료되지 않았거나 추가적인 작업이 필요한 상태
-> 더 많은 커밋 추가하거나 토론 진행하며 수정 요청 가능
-> 녹색 아이콘
-
Merged: 기본 브랜치로 병합된 상태. PR의 변경 사항이 승인되었고, 코드에 통합되었음을 의미. 이후 추가적인 변경이나 커밋을 추가할 수 없음. PR이 병합된 후에는 Closed 상태로 표시
-
Closed: PR이 거부되었거나, 더 이상 유효하지 않은 PR을 의미. 병합되지 않았지만, 더 이상 필요하지 않거나 다른 이유로 종료된 상태. 브랜치가 존재한다면 다시 Open 상태로 되돌릴 수 있음
-> 빨간색 아이콘
--> Closed와 Merged 모두 Closed 상태이기 때문에, Cosed에서 모두 확인 가능
❤️ PR Merge
1. merge commit을 만들며 합치기
: 두 브랜치의 변경 사항을 모두 유지하면서 병합
-> 각 브랜치의 변경 사항이 과거의 커밋으로 보존/ 새로운 커밋 추가
<장점>
: 브랜치의 히스토리를 모두 유지하므로, 진행 상황을 명확하게 이해하고 추적 가능
<단점>
: 히스토리가 복잡해질 수 있음
2. Squash and merge 하기
: 모든 변경 사항을 하나의 커밋으로 압축하여 병합하는 방식
-> 3rd-4th-5th 커밋이 하나의 커밋 feature/f1으로 합쳐짐
<장점>
: 히스토리를 간단하게 유지할 수 있음
-> 커밋 하나가 완성된 기능을 의미
<단점>
: 작업의 상세한 이력을 잃게 됨
-> 각 커밋에 대한 개별적인 맥락, 작업자 정보 등이 포함되지 않으므로 문제 해결의 어려움
-> 깃허브에는 해당 커밋 기록들이 모두 남아있음
3. Rebase and merge 하기
: 현재 브랜치를 target 브랜치에 재위치(rebase)시킨 후 병합하는 방법
-> target 브랜치의 커밋 위로 현재 브랜치의 모든 커밋을 옮겨놓는 것과 같음
-> 커밋 히스토리는 선형적으로 유지
<장점>
: 깨끗하고 선형적인 커밋 히스토리를 만들어줌.
-> 히스토리 파악 및 코드의 변화 이해가 더욱 쉬워질 수 있음
<단점>
: 관련 커밋의 id들이 모두 바뀌게 되어 혼란을 초래할 수 있음
-> 여러 개발자가 동시에 작업을 수행한 경우, 브랜치가 크게 분기된 경우에는 복잡하고 어려울 수 있음
--> 어떤 방법으로 머지해도, 코드에는 변화가 없다. 각 방법의 장단점을 잘 알아두고, 머지 방법을 통일하는 것이 협업할 때 혼란을 줄일 수 있다.
-> 프로젝트 규모가 커져, 머지 커밋만으로 관리가 어려우면 squash나 rebase 방식등을 활용하자
❤️ Fork해서 PR 만들기
: 이 방식의 협업이 일반 적임
(fork해와서, 각자 레포에서 작업 이후, 원본 레포로 PR보내기)
- fork
: 이미 존재하는 원격 git repository를 사용자의 계정으로 복사하는 기능
-> Github나 Gitlab같은 서비스에서 제공하는 GIT을 호스팅 하는 서비스
-> 기존 repository와 완전히 독립적인 새로운 repository이므로 자유롭게 변경 사항을 반영할 수 있음
-> 작업이 끝난 후에는 PR로 원본 repository에 기여도 할 수 있음
<장점>
: 작업 효율성이 좋고, 원본 저장소에서 직접 협업할 수 있음
❤️ fork로 협업하는 방법
- github에서 원하는 프로젝트 페이지로 이동
- 우측 상단에 있는 fork를 클릭하여, 해당 프로젝트를 자신의 계정으로 fork해와서 새로운 repository생성
- fork된 레포에서 변경사항을 반영할 새로운 브랜치 생성
- git add / git commit/ git push를 이용하여 변경사항 반영
- fork된 나의 레포로 이동하여 New pull request 버튼 클릭
❤️ 오픈 소스에 기여해 보기
: fork를 사용해 PR을 생성하는 대표적인 프로젝트
-> 버그 보고, 문서 개선, 테스트 작성
❤️ PR 충돌 해결 방법
충돌이란?
: 머지하는 과정에서 발생하는 현상
-> 동일한 파일, 동일하 부분에서 서로 다른 변경 사항이 생길 때 발생
충돌 해결 방법
-> 깃허브 ui, 로컬 2가지 방법이 있지만, 로컬에서 해결하는 방식이 코드의 흐름을 파악하기도 쉽고, 실수할 가능성을 줄여줌
1. 파일을 켜서 충돌 난 부분 코드 직접 수정
2. 수정된 파일 저장 후 git add/ git commit를 통해 해당 파일의 병합이 완료되었음 알림
3. git push를 통해 충돌 해결
❤️ PR 충돌을 최소화하는 방법
1. 최신 코드 유지
: 프로젝트 진행 시, 보통 하나의 메인 브랜치를 기반으로 새로운 기능을 개발하기 위한 브랜치를 생성한다.
-> 메인 브랜치와 개발 중인 브랜치 간의 차이를 줄이기 위해 주기적으로 최신 변경 이력을 가져와서 머지해서 최신 버전으로 동기화 시켜주자
2. 작은 Pull Request 만들기
: PR이 작아지면 변화하는 코드의 양도 적어질 뿐 아니라, 그 코드를 작성하는 시간도 줄어듦
-> 원본 브랜치와의 차이가 적음
-> PR을 작게 생성하기 위해 소프트웨어의 구조가 잘 구성되어 있어야 함
3. 파일을 작게 만들기
: 코드의 충돌은 보통 파일 단위로 일어나므로, 파일을 작게 만들어 충돌의 가능성을 줄인다.
-> 파일을 작은 의미 단위로 나누어 구성
-> 코드의 가독성 향상
-> 소프트웨어의 아키텍처가 잘 구성되어 있지 않은 경우에는 적용하기 어렵
4. 동료들과 많은 커뮤니케이션 수행하기
: 커뮤니케이션 능력은 협업과 프로젝트의 성공을 위해 프로그래머에게 꼭 필요한 덕목
-> 프로젝트 하면서 느낀 커뮤니케이션 부분 회고록에 모두 정리해놓기
❤️ 좋은 Pull Request란?
: 이해하기 쉽고 명확한 PR
-> 목적, 변경 사항, 프로젝트에 어떻게 영향을 미치는지 잘 이해할 수 있어야 함
-> 리뷰어가 편하게 PR을 보며 리뷰할 수 있어야 함.
pull request 작게 만들기
- 하나의 PR은 하나의 문제를 해결해야 함
: 코드의 목적을 명확히, 리뷰어에게 어떤 변경 사항에 주의를 기울여야 하는지 가이드 제공, PR의 범위를 제한하면서 코드 관리의 효율성을 높임 - PR은 하루 안에 끝낼 수 있는 크기로
: 대략 8시간 이내에 완료할 수 있는 작업을 pr로 구성하는 것이 이상적
-> 복잡성을 줄이며, 리뷰 과정을 간결하게 함
-> 효과적인 피드백 이끌어내는 데 유리 - 커밋을 활용해 논리적 그룹
: 작은 pr로 각 기능들을 이해하기 쉽고, 커밋으로 이루어진 논리적 그룹을 통해 전체 코드에서 어떤 역할 하는 지 파악하기 쉬움
--> 대규모의 PR이 종종 주의 깊게 리뷰되지 않는다
코드 스타일 깔끔하게 유지하기
: 이해력과 가독성에 직접적인 영향을 미치고, 효율적인 코드 리뷰와 팀의 생산성에 결정적
-> 코드의 일관성 증가시키고, 새로운 개발자가 프로젝트에 빠르게 적응하도록 도움
작성한 코드 테스트하기
: PR 보내기 전, 반드시 코드가 제대로 작동하는 지 테스트해야 함
-> 테스트 성공 결과를 pr에 명시하여 리뷰어에게 신뢰감을 제공하고 과정을 간소화할 수 있다.
-> 테스트 실패에 대한 부분도 PR에 담아 동료들의 의견을 묻는 것도 좋은 방법
😀 코드 리뷰
❤️ Github에서 코드 리뷰하기
pull request 페이지 들어가서 file changed 클릭
: 왼쪽 2번 부분이 변경 사항들을 보여주는 곳
: 가운데 내용들은 파일의 변경된 코드들을 보여주는 곳
라인 별로 코드 리뷰하기
: 라인 수 옆에 파란색 +버튼을 눌러, 라인 별로 리뷰를 진행한다.
-> 위의 빨간 박스를 클릭하면 제안할 수 있도록 하는 깃허브 편의 기능
<리뷰 제출하는 2가지 방법>
1. Add single comment
: 즉시 다른 개발자들이 볼 수 있도록 코멘트 형태가 리뷰로 남음
2. start a review
: 작성한 코멘트가 pending되고, 모든 리뷰가 모두 완료되었을 때 한꺼번에 제출 가능
-> 리뷰를 철회하거나, 추가할 것이 있으면 다른 개발자들에게 보내기 전에 수정 가능
멀티라인 코드 리뷰하기
: 라인 번호의 좌측을 클릭하게 되면 노란색으로 해당 라인 표시
-> shift+다른 라인 번호의 좌측을 눌러 범위 선택 가능
-> 이후 우측에 커서 올리면 파란색 플러스 버튼을 통해 코멘트
- #: 다른 pr를 검색하고 언급 가능 (다른 pr과 연관이 있다면 좋은 기능)
- viewed 버튼: 이미 본 파일 체크해줌
커밋 별로 리뷰하기
리뷰 제출하기
1. comment: 개선점, 의문점, 제안 남기기
2. approve: 코드가 문제 없다 (머지 가능)
3. request changes: 개선이 필요하거나 수정이 요구되는 사항이 있을 때
-> 이러한 사항을 반영해서 새로운 커밋
--> approve 된다면 머지 가능
❤️ 좋은 commit 만들기
1. 의미 있는 단위의 작업해야 할 것
: 하나의 기능이나 작업을 완성
-> 작업의 단위는 작게 유지하는 것이 좋지만, 너무 작은 단위로 커밋하는 것은 다량의 커밋만 생성할 뿐
2. 생성된 커밋은 동작이 가능한 형태여야 할 것
: 개별 커밋의 동작/ 전체 프로젝트의 동작
3. 커밋 메시지는 명확하고 간결하게 작성
: 커밋의 의미를 명확하게 전달
- conventional Commit
-> 꼭 이것을 따를 필요는 없고, 팀에 따라 결정하면 된다.
❤️ 자동으로 코드 Style 맞추기 (Linting)
: 소스 코드에서 스타일, 문법, 오류 등이 특정 규칙에 어긋난 것이 없는 지 자동으로 체크해주는 툴
-> 팀 전체 동일한 코딩 스타일 유지
-> 코드 가독성 높이고, 다른 개발자들이 코드 이해하기 쉽게
-> 코드 리뷰 시간을 단축
-> 스타일 가이드 준수 여부 상관없이 핵심 로직에만 집중 가능
ESLint
: ESLint는 가장 많이 사용되는 JAVASCRIPT의 Linting 도구
-> 플러그인을 사용해 프레임워크/라이브러리에 맞는 특화된 규칙 추가 가능
-> 프로젝트 루트에 ' .eslintrc ' 파일 생성하고, ESLint 옵션 추가
\{
"root": true,
"extends": ["eslint:recommended", "plugin:@typescript-eslint/recommended"],
"ignorePatterns": ["src/**/*.test.ts", "src/frontend/generated/*"]
}
Prettier
: 포매팅에 초점을 맞춘 도구로서, JS 뿐 아니라 다양한 언어를 지원
-> 프로젝트 루트 하위에 '.prettierrc' 파일에 Prettier 옵션을 추가
