코드로 소통하기 (깃허브 쓰는 방법)

git !== git hub

git은 형상관리 툴이다 git remote는 원격 저장소

git 컨벤션과 코드 스타일 통일하기

 

🤔 왜 코드로 소통 해야하는가??

Git을 잘 활용한다면 코드 변경 이력이나 왜 이 코드를 작성하게 되었는지, 어떻게 개선하면 좋을지를 기록·공유하여 팀원 간의 효율적인 협업이 가능합니다.

 

🛠️ Git에서 알아야 할 핵심 명령어

git init	현재 폴더를 Git 저장소로 초기화	git init
git add	변경된 파일을 스테이징 영역에 추가	git add . (전체 파일 추가)
git commit	스테이징 영역에 있는 변경사항을 커밋(버전)으로 확정	git commit -m "feat: 로그인 로직 추가"
git push	로컬 저장소의 커밋을 원격 저장소로 업로드	git push origin feature/login
git pull	원격 저장소의 최신 커밋을 로컬 저장소에 가져오고 병합	git pull origin dev
git merge	다른 브랜치를 현재 브랜치에 병합(Merge Commit)	git merge feature/login
git checkout	특정 브랜치로 이동하거나, 특정 커밋 시점으로 이동	git checkout dev
git branch	브랜치를 생성, 조회, 삭제 등에 사용	git branch feature/login
git rebase	커밋 히스토리를 재정렬하여 깔끔하게 합치는 방법 (선택)	git rebase dev

 

♟️ 프로젝트에서 사용할 브런치 전략 (Git Flow)

• 일반적으로 브랜치는 이렇게 나눠요
  • 메인 or 마스터 브랜치(main, master) - 배포용
  • 디벨롭 브랜치(dev)
  • 기능 단위 별 브랜치(i-12)
• 병합 순서는 대체로 이렇게 진행해요.
  • 기능 단위 별 브랜치 → 병합 → 디벨롭 브랜치 —최종병합→ 마스터 브랜치 

브랜치명	설명	예시
main	배포용 브랜치	main
dev	통합(개발)용 브랜치	dev
feature/	기능 개발 브랜치	feature/login
bugfix/	버그 수정 브랜치	bugfix/nav-bar
hotfix/	긴급 패치 브랜치	hotfix/payment
chore/	문서, 설정파일 변경 브랜치	chore/update-readme
docs/	문서 작업 브랜치	docs/api-guide
refactor/	리팩토링 브랜치	refactor/homepage-ui

 

좋은 PR의 조건

1. 작은 단위로 PR작성
2. 의미있는 커밋으로 구성하기
3. PR템플릿 활용하기

 

팀끼리 규칙을 정해서 한명이 한 것 처럼 통일을 시켜야한다🔥