GitHub Actions — CI/CDCI (Continuous Integration): 코드 푸시할 때마다 자동으로 테스트/빌드CD (Continuous Deployment): 테스트 통과하면 자동으로 배포기본 구조.github/ workflows/ ci.ymlname: CIon: # 언제 실행할지 push: branches: [main] pull_request: branches: [main]jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - uses: actions/setup-node@v3 with: ..
GitHub
merge vs rebase vs squash같은 상황:main: A ── B \feature: C ── D ── Emergemain: A ── B ──────────── M (merge commit) \ /feature: C ── D ── E히스토리가 그대로 보존됨merge commit이 생김언제 어디서 합쳐졌는지 명확rebasemain: A ── B ── C' ── D' ── E'feature 브랜치를 main 최신 커밋 위로 재배치히스토리가 일직선으로 깔끔해짐커밋 해시가 바뀜 → 공유된 브랜치엔 사용 금지squash mergemain: A ── B ── CDE (C+D+E를 하나로 합침..
PR 작성법 & 코드 리뷰좋은 PR의 조건1. 하나의 PR = 하나의 목적 → 로그인 기능 + 결제 기능을 한 PR에 넣지 않기2. 크기가 작을수록 좋음 → 리뷰어가 500줄짜리 PR을 꼼꼼히 보기 어려움 → 200줄 이하가 이상적3. PR 설명에 포함할 것: - 무엇을 왜 만들었는지 - 테스트 방법 - 스크린샷 (UI 변경이면)PR 템플릿 예시## 변경 내용- 유저 로그인 API 구현 (POST /auth/login)- JWT 토큰 발급 및 검증 미들웨어 추가## 테스트 방법1. POST /auth/login { email, password } 요청2. 응답의 token으로 인증 필요한 API 호출## 참고- 토큰 만료시간: 24시간- refresh token은 다음 PR에서 구현..
Git Flow / GitHub Flow브랜치 전략 = 팀이 합의한 브랜치 사용 규칙. 팀으로 개발할 때 충돌과 혼란을 막기 위해 필요하다.Git Flow규모가 크고 배포 주기가 긴 프로젝트에 적합.main ─────────────────────────────── (실제 운영 서버) ↑ merge ↑ mergerelease ────────── ────────── (배포 준비, QA) ↑ mergedevelop ────────────────────────────── (개발 통합 브랜치) ↑ ↑feature/login feature/payment ..
팀프로젝트 진행 중 만난 충돌,, 팀장님이랑 해결하느라 시간 꽤 쏟았는데 깃헙 강의에서 쉬운 방식을 알려주셨다,,,! 💥 충돌(Conflict) 💥 원인? - 같은 파일의 같은 위치에 코드가 변경되었기 때문 ✨ 해결 방법 - 충돌이 생기자마자 충돌이 생긴 사람과 상의 후 코드를 고치고 push 해주면 된다. 숫자…. 삭제 원하는 코드로 수정 코드를 변경한 팀원과 상의하는 것을 추천!! git add. / git commit -m '' / git push origin 내 브랜치
1. 우리 팀의 저장소 가져오기 - 우리 팀에서 쓰기로 한 github 저장소를 clone 해온다. # 원하는 루트에서 git clone 팀 저장소 클론 주소 2. 팀 저장소 연결하기 - git 초기화 해주기 git init git remote add origin 팀 저장소 주소 또는 팀 내 master 브랜치 이름 git remote add origin main # 또는 git remote add origin https://github.com/choisooyoung-dev/git-test.git # 잘 됐는지 확인하기 git remote -v 3. 내 브랜치 생성하기 - checkout으로 브랜치를 생성하기 - 내 브랜치에서 코드를 짜고 편집해야 main 브랜치에 영향을 주지 않고, 각 팀원들과 충돌하..
