Fullstack-Study

Git

1. Git 기본 개념

• 분산 버전 관리 시스템(DVCS) 으로, 모든 개발자는 자신의 로컬 저장소를 가지고 코드 변경 이력을 기록하고 관리할 수 있음
• 버전 관리 목적 : 코드 변경 추적, 협업 시 충돌 최소화, 이전 버전 복원, 배포 관리 용이
• Git 저장소 구조 :
  • Working Directory : 현재 작업 중인 코드
  • Staging Area (Index) : Git Index라고도 부르며, 커밋 전에 변경 내용을 임시로 올려두는 곳

  • 예시 : git add file.txt → Staging Area에 올라감

  • Repository : 실제 커밋이 저장되는 곳

2. 브랜치 전략

• 브랜치(Branch) : 독립된 작업 공간, 서로 간섭 없이 개발 가능
• 주요 전략 :
  • Git Flow : 기능 개발(feature), 배포 준비(release), 버그 수정(hotfix), 메인(master/main) 관리
  • GitHub Flow : master/main에 PR(Pull Request) 기반 merge, 단순 프로젝트에서 주로 사용
  • Trunk Based Development : 짧은 브랜치, 자주 merge, 빠른 CI/CD 반영

3. Commit / Push / Pull

• commit : 로컬 저장소에 변경 기록 저장
• push : 로컬 commit을 원격 저장소(GitHub, GitLab 등)에 업로드
• pull : 원격 저장소 변경 내용을 로컬로 가져오기
• tip : commit 메시지는 명확하게, feat: 로그인 기능 추가, fix: 버그 수정 같은 컨벤션 활용

4. Merge / Rebase

• Merge와 Rebase 모두 브랜치 합치기 목적

• 차이점은 히스토리 관리 방식:

  • Merge : 두 브랜치 히스토리가 그대로 남고, merge commit이 새로 생김

    main: A---B---C
                    \
    feature:        D---E
    merge 후 → A---B---C---M
                        \   \
                        D---E
    

  • Rebase : feature 브랜치 커밋들을 main 브랜치 끝으로 재배치 → 히스토리가 직선으로 깔끔

    main: A---B---C
    feature: D---E
    rebase → A---B---C---D'---E'
    

• merge : 브랜치 통합, 새로운 commit 생성, 히스토리 유지

  # Merge
  git checkout main
  git merge feature/login
  

• rebase : 브랜치 변경 사항을 다른 브랜치 위로 재적용, 깔끔한 히스토리 유지(브랜치 커밋 히스토리를 재작성하는 작업)

  # Rebase
  git checkout feature/login
  git rebase main
  

• 충돌 처리 :

  • merge/rebase 시 동일 코드 변경 시 충돌 발생
  • 충돌 해결 후 add → commit → push

• 실제 명령어 적용 시 주의점

  • rebase는 push 전에만 사용
  • force push 필요할 수 있음
  • 로컬 브랜치에서만 rebase하면 안전하지만, 이미 원격 브랜치에 push된 커밋을 rebase하면 히스토리가 바뀌어서 충돌 발생할 수 있음
    • 충돌 가능성 발생 원인 : 원격 브랜치와 로컬 브랜치의 히스토리 불일치

5. 협업 시 충돌 처리

• 최소화 전략

  • 기능 단위 브랜치, 자주 pull
  • PR 리뷰, 코드 스타일 가이드 적용

• 충돌 해결 :

  1. git pull → 충돌 발생
  2. 파일에서 <<<<<< HEAD >>>>>> 확인
  3. 코드 수정 후 git add → git commit → git push

---

CI/CD & DevOps

1. 개념

• DevOps : 개발(Development) + 운영(Operations) 결합 → 코드 작성부터 배포, 운영까지 자동화와 협업 강화
• CI (Continuous Integration) : 코드 변경 시 자동 빌드 & 테스트 → 안정성 확보
• CD (Continuous Delivery / Deployment) : CI 후 자동 배포 가능.
  • Delivery : 배포 준비 상태 , 수동 배포 가능
  • Deployment : 자동 배포
• CI/CD는 DevOps 실행 방식 중 하나
• Jenkins, Docker, Kubernetes 등은 DevOps 도구

Jenkins, GitHub Actions

• Jenkins : 오픈소스 CI/CD 서버, 파이프라인 기반 자동화
• GitHub Actions : GitHub 내 CI/CD 도구, push/PR 이벤트 시 자동 워크플로 실행
• 자동화 예시 :
  • 코드 push → 빌드 → 테스트 → Docker 이미지 생성 → Kubernetes 배포
• 테스트 자동화 : Unit Test, Integration Test 자동 실행
  • Unit Test(단위 테스트) : 함수, 클래스 단위 테스트 → 독립적, 빠름
    • 예 : add(a,b) 함수가 정상 작동하는지 테스트
  • Integration Test(통합 테스트) : 여러 모듈/서비스 연동 테스트 → 실제 시스템 시뮬레이션
    • 예 : 로그인 API 호출 후 DB에 정상 저장되는지 확인

---

Docker & Kunbernetes (컨테이너 & 오케스트레이션)

1. Docker

• 컨테이너 : 가벼운 가상화 기술, 애플리케이션 + 실행 환경을 패키징
• Docker 이미지 : 앱 + 실행 환경 + 라이브러리 → 배포 패키지
• Docker 컨테이너 : 이미지 실행 시 만들어지는 인스턴스 → 실제 서비스 구동
• 장점 :
  • 환경 일관성 : 개발 / 테스트 / 운영 동일 환경
  • 빠른 배포, 리소스 효율적
• 명령어 예시 :

  docker build -t my-app .
  docker run -p 8080:8080 my-app
  docker ps
  docker stop <container_id>     
  

2. Kubernetes (K8s)

• K8s : 컨테이너 오케스트레이션 툴, 여러 컨테이너를 클러스터 단위로 관리
  • 오케스트레이션 : 여러 컨테이너를 관리/조율하는 자동화 작업
    • Pod 스케일링, 네트워크, 배포, 업데이트, 장애 복구 등
• 핵심 개념 :
  • Pod : 하나 이상의 컨테이너 그룹 (실행 단위)
  • Service : Pod 접근을 위한 네트워크 추상화 (관리/접근 단위)
  • Deployment : Pod 복제/업데이트 관리
  • Namespace : 리소스 격리
• 장점 :
  • 확장성 : 트래픽에 따라 Pod 자동 증가
  • 자가 복구 : 장애 시 자동 재시작
  • 롤링 업데이트 : 서비스 중단 없이 버전 변경

3. Docker + K8s + CI/CD

• Docker/K8s 파이프라인 = 이미지 생성 → Registry에 이미지 업로드 → K8s Deployment 실행 → Pod 생성(Registry에서 이미지 Pull → 컨테이너 실행)
• CI/CD 파이프라인 예시 :
  1. Git push -> Jenkins / GitHub Actions 빌드
  2. Docker 이미지 생성 → Registry 업로드
     • 컨테이너는 아직 생성 안됨
  3. K8s Deployment 업데이트 → 새 버전 배포
     • 새로운 Pod 생성(Registry에서 이미지 Pull → 컨테이너 실행)
  4. 테스트/모니터링 자동 수행