SEB_Pre-Project - Git 학습

📔 Github 리포지토리

📙 꼭 필요한 파일

• README.md
  • 간단한 마크다운 사용법을 숙지하면 소개 페이지로 제작 가능
  • 프로젝트 이름, 프로젝트 핵심 기능 소개, 팀원 소개
• .gitignore
  • git으로 관리하지 않는 파일 모음. 개인이 따로 관리해야 하는 중요한 secret token이나, 다른 동료와 공유할 필요가 없는 설정 파일, 그 외 공유할 필요 없는 파일. push할 때 리포지토리에 push되지 않는다.
• LICENSE
  • 해당 코드의 라이센스 표기
  • 퍼블릭으로 공개된 리포지토리도 라이센스에 따라 사용할 수 있고, 하지 못 할 수있다.

📖 프로젝트 관리에 활용할 수 있는 Github기능

• Issue
  • 프로젝트에 새로운 기능을 제안, 버그 제보 등
  • Pre-Project에서는 Issue를 하나의 칸반 티켓처럼 사용
• Milestone
  • 이정표 역할, 태스크 카드(Issue)를 그룹화 하는데 사용
  • 마일스톤에 연결된 태스크 카드가 종료되면 마일스톤마다 진행상황이 업데이트
  • 연관된 이슈의 추적과 진행상황 한눈에 파악 가능
  • Pre-Project에서는 Bare Minimum, Advanced Challenge, Nightmare를 표시하기 위해 사용
• Pull Request
  • 내가 작업한 내용을 중요 git branch에 합칠 수 있는지 확인하는 요청
  • 깃헙에서는 Pull Request에서 커밋한 코드를 따로 선택하여 해당 부분에 코멘트 가능
• Project
  • 깃헙 내에서 업무 관리해주는 기능
  • 칸반 보드 생성. 업부 흐름 관리

📔 Github Project 칸반

• 팀과 조직이 작업을 시각화하고 업무의 병목 현상과 리소스 낭비를 해결하는 업무 관리 방법
  
• Work In Progress(WIP) 로 진행중인 업무 제한 및 흐름 관리 (업무 과도 막기 위함)

📔 Github 이슈

• 하나의 작업(task)로 관리
• 예시
  

Github 이슈 템플릿 카드

• 이슈 반복 생성 가능

1. Setting
2. Issue의 Setup templates 생성
   

📔 Github 마일스톤

• 여러 개의 이슈들을 각각의 마일스톤으로 그룹화 작업 가능

1. Issue 탭에서 Milestones 생성
   

📔 Github Project(칸반)

1. 프로젝트 탭에서 생성
2. 설정에서 이름 설정 후
3. 권한 설정 / 팀원 초대
4. Issue 연결 (#으로 레포지토리 찾기)
   
5. 이슈들 상태 설정과, 새로운 칼럼 추가 가능, 그룹으로 보기 가능
   
6. 이슈 생성 시 Project를 생성한 프로젝트로 설정하면 자동으로 트래킹 가능

---

📔 Git branch

• 기존 개발중인 메인 개발 코드를 그대로 복사하여 새로운 기능 개발을 메인 개발 코드를 건드리지 않고 할 수 있는 버전 관리 기법

📖 브랜치 생성 / 변경하기 (git switch)

• 새로운 브랜치로 Git이 바라보는 곳, HEAD를 변경하는 작업을 switch라고 한다.

# feature라는 브랜치를 새로 생성하는 경우, -c를 붙인다.
git switch -c feature
# checkout이라는 명령어도 사용 가능
git checkout -b feature

# 기존에 있던 main 브랜치로 HEAD를 변경하려면, -c를 붙이지 않는다.
git switch main
git checkout main

📖 브랜치 합치기 (git merge)

• 기능 개발이 끝나면 브랜치를 main 브랜치와 합칠 수 있다.

# 기능 개발이 진행됨.
git commit -m "기능1의 세부 기능1"
git commit -m "기능1의 세부 기능2"
git commit -m "기능1 개발 완료"
# 머지를 위해 main 브랜치로 전환
git switch main
# main 브랜치로 feat/todo 브랜치를 병합
git merge feat/todo

• 실제 개발 시에는 로컬에서 합치기보단 깃헙의 Pull Request 기능을 이용하여 변경 내역 확인 후 머지, 로컬에서 머지하지 않고 feature 브랜치를 push하여 pull request 요청 권장

# 기능 개발이 진행됨.
git commit -m "기능1의 세부 기능1"
git commit -m "기능1의 세부 기능2"
git commit -m "기능1 개발 완료"
# Github 리포지토리로 푸시
git push origin feat/todo
# Github에서 Pull Request 한다.

📖 브랜치 삭제하기 (git branch -d)

• 원격 리포지토리에서 pull request가 성공적으로 마무리된다면 브랜치 Delete branch로 삭제

로컬에서는 git branch -d feat/todo 형식으로 삭제 가능
-D 옵션으로 머지되지 않은 브랜치도 삭제 가능

---

📔 Git flow

• 브랜치의 종류를 나눠 관리하는 브랜칭 전략 중 가장 유명한 전략

📖 Coz' Git flow

• 파생된 여러 Git flow 중 단순화한 전략
  

• 핵심 브랜치
  • main 브랜치
    사용자에게 언제든 제품으로 출시할 수 있는 브랜치
    • 대표적인 기능이 완성
    • 기존 기획했던 레이아웃이나 전체적인 디자인이 얼추 완성
    • 클라이언트, 서버, 데이터베이스가 공개된 웹에서 정상적 통신
    • 최소한의 보안
  • dev 브랜치
    다음 버전 배포를 위한 개발중 브랜치

• 보조 브랜치
  • feature 브랜치
    기능개발, 리팩토링, 문서 작업, 단순 오류 수정 등 작업 기록을 위한 브랜치

---

📜 개발 환경 구성

• IDE : 인텔리제이
• JDK11
• Spring-boot 2.7.1 버전
• Gradle 빌드 방식git