Jump To VB.NET

개발자들이 GitHub를 통해 효과적으로 코드 협업을 진행하는 단계별 워크플로우를 정리했습니다. 실제 프로젝트에서 적용할 수 있도록 각 단계를 이해하기 쉽게 설명합니다.

1. 프로젝트 저장소 생성 및 준비

• 팀장 또는 대표가 GitHub에서 새로운 저장소(Repository)를 생성합니다.
• 팀원들은 협업 권한을 받거나, 저장소를 Fork하여 사용할 수 있습니다.

2. 코드 복제(클론) 및 환경 설정

• 각 팀원은 저장소를 자신의 로컬 컴퓨터로 Clone 합니다.
• git clone <저장소 주소>
• 필요에 따라 팀 브랜치 전략을 확인합니다(main, develop, feature/<기능명> 등).

3. 최신 코드 동기화

• 공동 작업을 시작하기 전, 항상 최신 코드를 받아와서 코드 충돌을 예방합니다.
• git pull origin main # 혹은 개발 브랜치일 경우 git pull origin develop

4. 브랜치 생성 및 작업 분리

• 새로운 기능 개발이나 버그 수정을 위해 작업용 브랜치를 만듭니다.
• git checkout -b feature/<기능명> develop

5. 코드 작성 및 수정

• 자신이 맡은 기능을 로컬 환경에서 개발합니다.

6. 변경 사항 커밋(Commit)

• 작업한 내용을 스테이지에 올린 뒤, 명확한 커밋 메시지와 함께 저장합니다.
• git add . git commit -m "Add: 로그인 기능 구현"

7. 원격 저장소에 Push

• 완성된 코드를 원격 저장소의 해당 브랜치에 업로드합니다.
• git push origin feature/<기능명>

8. Pull Request(PR) 생성

• GitHub에서 Pull Request(PR)를 만들어 코드 병합 요청 및 코드 리뷰를 받습니다.
• PR을 통해 작업 내용, 목적 등을 상세하게 작성합니다.

9. 코드 리뷰 및 승인

• 팀원 또는 팀장이 PR을 검사하고, 의견이나 개선 사항을 남깁니다.
• 승인되면 Merge가 가능합니다.

10. 병합(Merge) 및 브랜치 삭제

• 리뷰와 승인을 거치면 개발 브랜치(develop 등)에 병합합니다.
• 병합이 끝난 feature 브랜치는 삭제하여 관리합니다.
• git branch -d feature/<기능명> git push origin --delete feature/<기능명>

11. 최신 상태 유지 반복

• 새로운 작업이 있을 때마다 위 단계를 반복하며, 항상 최신 코드를 기반으로 개발을 진행합니다.

협업 팁

• 모든 팀원이 브랜치 전략과 협업 규칙에 대해 충분히 이해해야 합니다.
• 커밋 메시지는 명확하고 일관성 있게 작성해주세요.
• Pull Request에는 변경 목적, 주요 변경 내용, 이슈번호 등 상세 내용 기록을 권장합니다.

협업 과정을 체계적으로 관리하면 생산성과 코드 품질 모두 높일 수 있습니다.

Happy GoSu ~

WooGong ))*

Git을 사용해 팀 프로젝트를 하다 보면 커밋 메시지 앞에 'feat:', 'fix:' 같은 접두어가 붙는 것을 자주 보셨을 겁니다. 이 접두어들은 단순한 습관이 아니라, 협업과 프로젝트 관리를 획기적으로 개선하는 커밋 메시지 컨벤션 (Commit Message Convention), 그중에서도 Conventional Commits 규칙을 따르는 형식입니다.

이러한 규칙은 커밋이 어떤 종류의 변경을 포함하는지 한눈에 파악하게 해주고, 프로젝트의 이력 관리를 체계화하는 데 도움을 줍니다.

💡 왜 커밋 메시지에 접두어를 붙여야 할까?

일관된 커밋 메시지 형식을 사용하면 다음과 같은 이점을 얻을 수 있습니다.

1. 가독성 및 이력 추적 용이: 커밋 로그만 봐도 변경의 성격(기능 추가인지, 버그 수정인지 등)을 즉시 알 수 있습니다.
2. 자동화: Semantic Versioning (유의적 버전 관리)을 기반으로 버전을 자동으로 올리거나, 변경 사항(Changelog) 문서를 자동으로 생성할 수 있습니다.
3. 협업 효율 증대: 다른 팀원이 어떤 작업을 했는지, Pull Request (PR)의 목적이 무엇인지 빠르게 이해할 수 있습니다.

Conventional Commits: 핵심 타입 (접두어) 정리

커밋 메시지의 접두어는 변경의 종류를 나타내는 타입(Type)이며, 일반적으로 다음과 같은 형식을 따릅니다.

<타입>([스코프]): <제목>

가장 널리 사용되는 핵심 타입들을 정리했습니다.

🔍 커밋 메시지 작성 팁

좋은 커밋 메시지는 단순히 규칙을 따르는 것을 넘어, 프로젝트의 스토리를 명확하게 전달해야 합니다.

1. 제목(Subject)은 간결하게: 제목은 50자를 넘기지 않도록 간결하게 작성합니다.
2. 명령형 사용: 마치 "이렇게 변경하세요"라는 명령조로 작성하는 것이 일반적입니다. (예: Add feature 대신 add feature)
3. 본문(Body)은 선택 사항이지만 중요: 변경의 이유나 자세한 내용이 필요하다면 본문 영역에 "무엇을, 왜" 변경했는지 상세히 설명합니다.

Happy GoSu ~

WooGong ))*

//////////////////////////////////////

ESLint와 Prettier가 프로젝트에서 예전 설정을 따르면서 코드 포맷팅이나 린트가 제대로 적용되지 않는 경우가 있습니다. 이 문제는 설정 파일 충돌, 캐시 문제, 설정 위치 오류 등 다양한 원인으로 발생할 수 있습니다. 이 글에서는 그 원인과 해결 방법을 단계별로 자세히 설명합니다.

목차

• 현상과 원인 파악
• 설정 캐시 재시작
• 설정 파일 위치 및 중복 확인
• ESLint와 Prettier 최신 설정 적용법
• CI/CD 및 빌드 환경 점검
• CLI 옵션 점검

현상 및 주요 원인

• 예전 설정이 캐시에 남아 변경 사항 반영 안됨
• 여러 위치에 설정 파일 존재
• plugin:prettier/recommended가 extends 마지막에 위치하지 않음
• 빌드나 CI 환경에서 별도 캐시 사용
• 명령어 옵션에 --no-config 등 부적절한 설정 삽입

해결법

1. 캐시 초기화 및 에디터 재시작

• VSCode, 에디터, ESLint/Prettier 확장 프로그램 재시작
• 프로젝트 내 .eslintcache 등 캐시 파일 삭제
• 파일을 다시 저장해 적용되는지 확인

2. 설정 파일 정리

• .eslintrc, prettier.config.js 또는.prettierrc 등 환경설정 파일 위치 확인
• 중복되거나 오래된 설정 파일 제거
• 필요한 설정 파일만 유지하고 명확히 관리

3. VS Code 설정

• VS Code의 settings.json에서 editor.defaultFormatter가 esbenp.prettier-vscode로 설정되어 있는지 확인

4. 확장 프로그램 재설치

• Prettier, ESLint 확장을 제거 후 다시 설치

3. 최신 recommended 설정 사용 및 순서 확인

• .eslintrc에서 plugin:prettier/recommended를 extends 배열 마지막에 위치시키기

{
  "extends": [
    "some-other-config",
    "plugin:prettier/recommended"
  ]
}

• eslint-plugin-prettier, eslint-config-prettier 최신 버전 설치 확인

4. 빌드 도구 및 CI 설정 점검

• 별도로 저장된 캐시 제거 및 빌드 파이프라인 업데이트
• 빌드 전에 eslint --fix와 prettier --write 명령어 실행 확인

eslint --fix
prettier --write

5. CLI 옵션 확인

• 명령어에 --config 옵션을 사용해 특정 설정 강제 적용 여부 점검
• --no-config 옵션으로 설정 무시하는 경우 제거

요약

Happy GoSu ~

WooGong ))*

\\