수업 71일차

✔ CI/CD

개요

• CI
  - Continuous Integration(통합)
• CD
  - Continuous Delivery(서비스 제공), Continuous Deployment(배포)
• 애플리케이션 개발 단계를 자동화해서 애플리케이션을 보다 짧은 주기로 고객에게 제공
• 새로운 코드 통합으로 개발 및 운영 팀에 빈번히 발생했던 Integration Hell 문제를 해결하기 위한 방법
• 지속적인 통합이 제대로 구현되면 애플리케이션 코드의 새로운 변경 사항이 정기적으로 빌드 및 테스트를 거쳐 공유 레포지토리에 병합되므로 여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌이 발생하는 문제를 해결할 수 있음

지속적인 통합

• 개발 팀이 작은 변경 사항을 구현하고 코드를 버전 제어 레포지토리에 자주 체크인하도록 하는 코딩 철학이자 관행
• 최신 애플리케이션은 다양한 플랫폼 과 도구에서 코드를 개발해야 하기 때문에 팀은 변경 사항을 통합하고 검증하기 위한 메커니즘이 필요
  이러한 문제 때문에 버전 제어 레포지토리를 사용할 때 IDE가 제공하는 기능을 사용하지 않고 Command Line Interface 에서 명령어를 이용합니다.
• 소프트웨어 공학에서는 지속적 통합은 지속적으로 품질 관리를 적용하는 프로세스를 실행하는 것
• 버전 관리 소프트웨어를 이용해서 소스 코드를 업로드 하고 통합하는 작업

지속적인 제공(Continuous Delivery)

• 개발자들이 애플리케이션에 적용한 변경 사항이, 버그 테스트를 거쳐 레포지토리에 자동으로 업로드 되는 것
• 운영 팀은 이 레포지토리에서 애플리케이션을 실시간 프로덕션 환경으로 배포
  - 어떤 애플리케이션은 자동 배포가 안되는 경우가 있음
• 어떤 액션이나 이벤트를 이용해서 레포지토리를 업로드하는 것

지속적인 배포(Continuous Deployment)

• 개발자의 변경 사항을 레포지토리에서 고객이 사용 가능한 프로덕션 환경까지 자동으로 릴리스하는 과정
• 애플리케이션 제공 속도를 저해하는 수동 프로세스로 인한 운영 팀의 프로세스 과부하 문제를 해결
• 웹 서비스의 경우는 클라우드 환경을 적절히 이용하면 지속적인 배포가 가능

✔ 지속적 인도

전통적인 방식

• 고객
• 개발자
  - 분석, 계획, 구현, 단위 테스트, 시연
  - Scrum이나 Kanban같은 Agile 기법을 활용해서 개발 속도를 높이고, 이해 관계자와 원할하게 의견을 주고 받음
  - 제품을 시연하는 자리를 만들어서 빠르게 피드백을 받고, TDD나 Extreme Programming 같은 알려진 개발 기법을 적극 수용
  - 구현이 끝나면 QA팀에게 넘김
• QA
  - 통합테스트, 인수 테스트, 비기능 분석
  - UAT(사용자 인수 테스트)를 수행하게 되는데, 테스트에 영향이 없도록 트렁크 코드를 프리징하고 진행
  - 테스트를 진행해서 버그가 발견되면, 개발팀에게 할당하고 승인을 하면 릴리즈
• 운영팀
  - 릴리즈, 모니터링
  - 운영 과정 중 문제가 발생하면, 다시 개발자에게 연락해서 수정하기

문제점

• 느린 인도 기간
• 느린 피드백 주기
• 자동화 미비
• 위험한 핫픽스
  - 간단한 테스트만 수행하거나, 테스트 생략
• 의사 소통 부족
• 책임 분산
• 낮은 업무 만족도
• 스트레스

최근의 방식

• 별도로 업무를 나누지 않고 하나의 팀이 개발부터 운영까지 모두 담당

장점

• 빠른 제품 인도
• 빠른 피드백 주기
• 위험도가 낮은 릴리즈
• 유연한 릴리즈

✔ 자동 배포 파이프라인

• 코드 레포지토리에 변경이 발생할 때 마다 실행되는 일련의 스크립트로, 프로세스가 성공하면 프로덕셔 ㄴ환경으로 배포가 되는 것으로 마무리

지속적인 통합

• 각기 다른 개발자가 작성한 코드가 통합되었는지 확인
• 개발자에게 첫 번째 피드백을 제공하는 단계
• Repository에서 코드를 체크 아웃 하고, 이를 컴파일한 뒤, 단위 테스트를 실행하고 코드 품질을 검즈
  - 최근에는 테스트를 하면서 개발하기도 합니다.
• 어떤 단계에서든 실패한다면, 파이프라인 실행이 중단되므로 개발자가 첫 번째로 할 일은 CI 빌드를 수정하는 것이다.
• 이 과정을 수행하는데 걸리는 시간을 측정해서 개발자가 이 시간보다 빠르게 커밋하지 않도록 해야 합니다.

자동 인수 테스트

• 개발자가 구현한 기능이 고객의 요구사항과 맞는지 확인하는 과정
• 이전에 수동으로 진행하던 테스트를 고객과 QA팀이 자동으로 수행할 수 있도록 작성한 일련의 테스트
• 프로세스의 끝에서 작성하는 것이 아니라, 시작 단계에서부터 테스트 케이스를 만들고 고객과 긴밀하게 협력해야 함

인수 테스트

• 비즈니스 관점에서 본 기능적 요구 사항을 검증
  - 고객과 개발자가 합의한 소프트웨어의 동작 방식을 스토리나 예제 형식으로 제공

단위 테스트

• 버그를 최소화하고 소프트웨어 품질을 향상하도록 개발자를 지원하는 테스트

탐색적 테스트(수동)

• 수동으로 하는 블랙박스 테스팅
• 기능을 중점적으로 파악하는 테스트
  - 경험을 바탕으로 시스템의 문제를 찾거나 개선하는 테스트
  - 경험 바탕이기에 자동으로 하기 어려움

비기능 테스트

• 성능, 확장성, 보안 등과 관련된 시스템 속성을 테스트

통합 테스트

• 모듈형 애플리케이션을 개발할 떄 수행
• 마이크로 서비스에서는 단위 테스트가 통합 테스트를 대체하기도 합니다.

단위 테스트 -> 통합 테스트 -> 인수 테스트

구성 관리

• 수동 운영 단계를 대체하는 환경을 구성하고 소프트웨어를 배포
• 구성 관리는 소프트웨어와 환경 변화를 추적하고 제어하는 역할
• 환경이 변하면 어떻게 자동 배포를 할것인가?
• 필수 도구 준비와 설치, 애플리케이션 배포와 관련된 다양한 서비스 인스턴스와 배포 버전, 인프라 인벤토리 및 기타 작업의 확장 관리 등
• 앤서블이나 셰프, 퍼핏 같은 구성 관리 도구를 사용하면 구성 관리 파일을 버전 관리 시스템에 저장할 수 있고, 프로덕션 서버에서 발생한 변경 사항을 모두 추적할 수 있음
• 운영 팀의 수동 작업을 대체할 만한 분야는 애플리케이션 모니터링으로 운영 중인 시스템의 로그나 지표를 개발자나 데브옵스 팀이 모니터링하는 공통 대시보드에다 실시간으로 스트리밍

✔ 구성 도구

• 컨테이너 관련
  - Docker, Kubernetes
• CI/CD 파이프라인과 자동화 스크립트 작성
  - Jenkins
• 버전 관리 시스템
  - Git Hub
• 프로시저닝과 구성 관리 및 배포 도구
  - Ansible, Argro CD
  

✔ 버전 관리 시스템

개요

• 파일의 변화를 시간에 따라 기록한 뒤, 과거 특정 시점의 버전을 다시 불러올 수 있는 시스템
• 모든 컴퓨터의 파일이 버전 관리의 대상
• 이미지나 레이아웃을 다루는 그래픽 디자이너나 웹 디자이너도 버전 관리 시스템을 사용하는 것이 현명한 선택
• 개별 파일 혹은 프로젝트 전체를 이전 상태로 되돌리거나 시간에 따른 변경 사항을 검토할 수 있으며, 문제가 되는 부분을 누가 마지막으로 수정했는지, 누가 언제 이슈를 만들어냈는지 등을 알 수 있기 때문입니다.

종류

• 로컬 버전 관리 시스템
  - 로컬 컴퓨터에 버전 관리에 필요한 파일을 복사해두던지 데이터베이스에 변경 사항을 기록하는 방법
• 중앙 집중식 버전 관리 시스템(클라이언트 - 서버 모델)
  - 외부에 있는 개발자와의 협업 문제를 해결하기 위해서 개발
  - CVS, Subversion, Perforce와 같은 시스템들이 여기에 속하는데, 모든 파일을 저장하는 하나의 서버와 이 중앙 서버에서 파일들을 가져오는 checkout을 수행하는 다수의 클라이언트가 존재
  - 누구나 다른 사람이 무엇을 하고 있는지 알 수 있고, 관리자는 누가 무엇을 할 수 있는지 관리할 수 있으며, 이 방식이 수많은 클라이언트들의 로컬 데이터베이스를 관리하는 것 보다는 쉽다.
  - 중앙 서버가 잘못되면 모든 것이 잘못된다는 치명적인 단점이 존재, 즉 단일 장애점을 가지고 있다.
• 분산 버전 관리 시스템
  - Git, Mercurial, Bazaar, Darcs 등이 대표적인 분산 버전 관리 시스템인데, 파일들의 마지막 스냅샷을 가져오는 대신, 저장소를 통째로 복사하는 방식
  - 서버에 문제가 생겨도, 어느 클라이언트든 복제된 저장소를 서버에 복사하면 서버가 복구되는 형태로, checkout을 할 때마다 전체 백업이 일어나는 방식임
  - 다수의 원격 저장소를 갖는 것이 가능하기 때문에, 동시에 여러 그룹과 여러 방법으로 함께 작업할 수 있어서, 중앙 집중 시스템에서는 할 수 없는 계층 모델 등 다양한 작업 방식을 사용할 수 있다.

실례

• CVS
  - 클라이언트 서버 방식의 버전 관리 시스템
• Subversion
  - CVS의 단점을 개선한 클라이언트 서버 방식의 버전 관리 시스템
• Mercurial
  - 구글에서 관리를 지원하고 있는 분산 모델의 버전 관리 시스템
• Git
  - 분산 버전 관리 시스템
  - 자유 소프트웨어
  - git을 이용하는 저장소 공유 사이트가 많음 (Git Hub)
  - 많은 튜토리얼과 프로젝트가 존재함
  

✔ Git

개요

• 컴퓨터 파일의 변경 사항을 추적하고 여러 명의 사용자들 간에 해당 파일들의 작업을 조율하기 위한 분산 버전 관리 시스템 혹은 명령어
• 리누스 토발즈가 리눅스 커널에 대한 코드를 공유한 목적으로 개발
• 자유 소프트웨어(누구나 쓸 수 있다)

장점

• 이력 기록 및 추적
• 전 세계의 수 많은 사용자가 사용 중
• 서버 역할을 하는 원격 저장소와 각 개발자의 로컬 저장소에 git은 소스코드와 변경 이력을 분산 저장하기 때문에, 원격 저장소에 문제가 발생해도 로컬 저장소를 이용해서 복원이 가능함
• 변경 이력을 병합하는 것도 가능함

Git Hub

• Ruby on Rails로 작성된 분산 버전 관리 툴인 git의 원격 저장소 호스팅 서비스
• 영리적인 서비스와 오픈 소스를 위한 무상 서비스를 모두 제공
• git은 일반적으로 텍스트 명령어 방식인데, Git Hub는 GUI를 제공함
• git hub는 깃 프로젝트 저장소 역할 외에도 다양한 기능을 제공
  - git action과 gib hub deployment api등을 제공
  - project boards를 제공해서 협업 가능

원격 저장소와 로컬 저장소

• 로컬 저장소
  - 내 PC 안에 파일이 저장되는 개인 저장소
  - 새로 직접 만들거나, 원격 저장소를 로컬 저장소로 복사해서 생성
• 원격 저장소
  - 파일 원격 저장소 전용 서버에서 관리되며, 여러 사람이 함께 공유하기 위한 저장소
  

Commit

• 파일 및 디렉토리의 추가/변경 사항을 로컬 저장소에 기록하는 것
• Commit을 하게 되면, 이전 Commit 상태부터 현재 상태까지의 변경 이력이 기록된 Revision이 생성됨
• Commit은 순서대로 저장되므로, 최근 Commit부터 거슬러 올라가면, 과거 변경 이력과 관련된 내용을 알 수 있음
• 각 Revision은 영문과 숫자로 구성된 40자리의 고유 이름이 붙는데, 이름을 보고 각 Revision을 구분하고 선택함
• Commit은 이력을 남기는 작업이기 때문에 Commit을 수행할 떄는 메시지를 필수로 입력해야 하는데, 권장사항은 변경내용을 요약하고 빈 줄을 하나 주고, 변경 사유를 작성하도록 합니다.

Work Tree

• ?
• Index
  - Commit을 실행하기 전의 젖아소와 Work Tree 사이에 존재하는 공간
• 저장소 <-> 인덱스 <-> 작업 트리
• 작업 트리 내에서 어떤 파일과 디렉토리만 버전 관리를 할 지 선택할 수 있는데, 이 선택된 내용이 Index에 기록이 됩니다.
• 인덱스에 기록이 안된 파일은 저장소에 기록이 안됨
• git의 commit 작업은 작업 트리에 있는 변경 내용을 저장소에 바로 기록하는 것이 아니라 그 사이 공간인 인덱스에 파일 상태를 기록(staging)하게 되어 있기 때문에, 저장소에 변경사항을 기록하기 위해서 기록하고자 하는 모든 변경 사항이 인덱스에 존재해야 합니다.

설치

• windows
  - https://git-scm.com/dowloads 에서 다운로드 받아 설치하기
• 설치 확인
  - git --version

Git의 기본 branch 이름을 main으로 변경

• git 기본 branch는 master, git hub의 기본 branch 는 main이다.
• git push origin main 에서 브랜치 오류난다면, 아마 master로 되어있어서 그런 것이다.
• git config --global init.defaultBranch main

로컬 저장소에 git hub 사용자 등록

• git config --global user.name 이름
• git config --global user.email 이메일
• --global을 제외하면 현재 프로젝트에만 적용

✔ git 버전 만들기

git init

• 로컬 저장소를 만드는 명령
• 성공하면 메시지가 출력되고 현 디렉토리에 .git이라는 디렉토리가 생성
  - 숨김디렉토리임

git status

• 현재 상태 확인 명령
• a.txt 파일을 생성해서 작성하고 명령 수행
  - a.txt가 untracked files라는 메시지와 함께 출력
  - 변화가 발생하였지만 추적하지 않는 파일이다. (인덱스 영역에 포함 X)

git add

• 스테이지에 올리는 명령
• 이제 파일의 변경 내용을 추적하라는 의미
• 형식
  - git add <파일경로>
• a.txt 파일을 스테이지에 추가해보자.
  - git add a.txt 하면 된다.
  - 물론 해당 디렉에 있는 파일 전부라면 . 을 쓰면 된다.
  - 이후 git status를 해보면, changes to be committed라는 메시지 출력됨
  

git commit

• 현재까지의 추적 내용을 로컬 저장소에 반영하는 명령
• 기본 형식
  - git commit --message "메시지"
  - git commit -m "메시지"
• 명령을 성공적으로 수행하면, 새로운 버전을 만들어 냅니다.

git log

• 로컬 저장소의 commit 목록을 출력함
• 커밋 해시, 만든 사람, 날짜, 메시지가 출력됨
• HEAD는 현재 사용중인 branch를 나타냄
• 형식
  - git log

git commit -am "message"

• git add . 와 git commit -m 명령을 합친 명령어
• 얘는 근데 파일 두개를 할 때는 추가된 파일이 적용이 안될 수 있다.
  - a.txt 있는 상태에서 a 수정하고 b.txt 생성해서 -am 해보면 b.txt가 추적이 안되는 상태임을 확인할 수 있다.

Commit 메시지 본문 작성

• 메시지는 제목과 본문으로 구성
• git commit -m "제목"
  - 사실 본문이 아니라 제목이었던 것이다.
  - 지금알았네;;
• 메시지를 작성하고자 하는 경우는 git commit 명령을 수행하면 된다.

a.txt 수정하고 commit을 해볼까?

• 수정하고 add하고 git commit하면 editor가 나온다
  
• 에디터를 사용할 줄 알아야 한다
• 수정하자 (i 누르면 insert 모드 변경)
• 저장하고 나오자
  - esc하고 :wq! 하면 저장하고 나온다
  
• git log를 찍으면 이제 제목과 본문 다 나온다.

git log

• 커밋을 조회하는 명령
• 단순한 형태로 조회를 한다면 git log --oneline
  
• 자세히 조회를 한다면 git log --patch, -p도 가능
  
• 안나가지면 :q 해보기
• 그래프 형태로 조회하기 git log --graph
  - 왼쪽에 보면 선이 그어져있음
  - 트리 형태
• 모든 브랜치의 커밋 명령을 조회 git log --branches

태그 관리

• 태그는 커밋에 붙일 수 있는 서브 타이틀
• 태그를 이용해서 버전을 표시하는 경우가 많음
• git tag 태그를 수행하면 현재 브랜치에 태그가 추가됩니다.
• 특정 커밋에 추가하고자 하는 경우에는 git tag <태그> <커밋>
• 현재 커밋에 v1.0.0 태그 추가 : git tag v1.0.0
• 다른 커밋에 v1.0.1 태그 추가 : git tag v1.0.1 해시
  - git log --oneline에서 나오는 해시값 적으면 된다.
• 태그를 조회하고 싶어
  - git tag --list
• 태그 삭제하고 싶어
  - git tag --delete <태그> 또는 git tag -d <태그>
  

파일 상태 확인

git 작업 트리

• git은 관리하는 프로젝트의 작업을 효율적으로 처리하는 작업 트리라는 개념을 이용함
• 작업 트리는 git이 추적하는 파일과 추적하지 않는 파일으 ㄹ구분하고 추적하는 파일들의 상태를 구분짓는 영역
  - 이 내용은 .git이라는 숨김 디렉토리에서 관리
  - .git 디렉토리를 삭제하면 git과 관련된 모든 내용이 소멸됩니다.
• 이 영역은 3개의 영역으로 구성됩니다.

Working Directory

• 실제 작업 중인 파일들이 존재하는 영역으로 파일을 생성하거나 기존 파일을 수정한다면 이는 Working Directory에서 작업 중

Staging Area

• 작업 디렉토리의 파일 중 git이 추적하는 파일을 식별하는 영역
• .git 디렉토리 내부의 index 파일에서 추적하는 파일을 식별합니다.

Local Repository

• Staging에서 추적하는 파일이 Commit으로 등록되는 영역으로, Staging Area의 파일 혹은 파일들이 하나의 변경 단위인 Commit으로 등록되는 곳
• 작업 디렉토리에서 스테이징 영역으로 등록하는 명령이 git add가 되는 것이고, 스테이징 영역에서 local repository로 이동하는 명령이 git commit이 된다.

파일 상태

• untracked 상태
  - 현재 작업 디렉토리에는 존재하지만, git이 추적하지 않는 파일 상태
• tracked 상태
  - git이 추적중인 상태
  - staging area와 local repository에 있는 파일이 여기에 해당됨
• git add 명령 수행 시, warning이 발생하는 경우
  - os 마다 줄 바꿈 문자를 인식하는 방법이 달라서 발생
  - git config core.autocrlf true를 설정하면 된다.
• Unmodified 상태
  - 스테이징 영역에 존재하지만 수정하지 않은 상태
• Modified 상태
  - 스테이징 영역에 존재하고 수정한 상태
• 가장 최근 커밋 메시지 수정
  - git commit -amend -m "메시지"
• 유저 이름과 이메일도 수정 가능
  - git commit --amend --author "작성자 <이메일>"

✔ 버전 비교

get diff

• 최근 commit과 작업 디렉토리를 비교
• commit한 이후에 작업 디렉토리에서 어떤 작업이 이루어졌는지 확인하기 위해서 사용

get diff --staged

• 최근 Commit과 Stage를 비교
• stage는 add를 해야 변경이 발생한다.
• git add a.txt, git diff --staged를 해보자.

git diff <커밋> <커밋>

• commit끼리의 변경 내용을 확인
• commit은 40자리 해시를 전부 이용해도 되고 짧은 해시를 이용해도 된다.
• commit은 순서대로 적용되기 때문에 2개의 순서에 따라 결과는 반대로 출력
• 해시 코드 대신에 현재 커밋을 가리키는 HEAD를 이용하는 방법도 가능
  - 바로 이전 커밋은 HEAD^ 또는 HEAD~1로 표기하고, 그 이전의 커밋은 HEAD^^ 또는 HEAD~2로 표기하는 것이 가능
  

✔ 커밋 되돌리기

• 총 2가지이다.

revert

• 버전을 되돌리지만, 되돌아간 상태에 대한 새로운 버전을 만드는 방식

A->B->C->D->E

• 이렇게 commit을 했다고 하자, 근데 4번쨰 상태로 커밋을 되돌리기 위해 revert를 한다면 아래와 같다

A->B->C->D->E->D

• 즉, 5번쨰 상태가 없어지는건 아니다
• git revert <취소할 커밋>
• editor에서 알아서 수정하기

reset

• 되돌아갈 버전의 시점으로 완전하게 되돌아 가는 것
• 종류는 3가지 (soft, mixed, hard)
• A->B->C 해서 commit을 각각 했다고 하자. (a.txt)에서
  - 그럼 commit은 3번 수행이다.
  - 문서수정(작업) -> 스테이지 올리기 -> 커밋 이 3번 발생함

soft reset

• commit한 사실을 되돌리는 것
  - staging한 사실은 남아있다.
  - 두 번쨰 버전으로 soft reset을 했다고 한다면?
  - commit한 사실만 취소되는 것이기에 맨 마지막 commit만 안된 상태가 된다. 즉, c 추가하고 스테이지 올린것 까지만 된다는 것이다.
• get reset --soft <되돌아갈 커밋>
• get reset --soft 1q2w3e4r 이렇게

mixed reset

• commit과 stage를 되돌리는 것
  - 두 번쨰 버전으로 mixed reset 한다고 하면, c를 추가한 작업까지만 남는 것이다.

hard reset

• 작업, 즉 디렉토리 변경사항까지 되돌리는 것
  - 두 번째 버전으로 hard reset을 한다고 하면, b를 commit한 것 까지만 남는 것이다.

✔ 작업 임시 저장하기

git stash

• 변경 사항을 임시로 저장
• stash 명령은 tracked 상태의 파일에 대해서만 실행할 수 있음
• commit까지 하고 git stash -m "메시지" 이렇게 할 수 있다는 것이다.

임시 저장한 목록 확인

• git stash list
• 임시 저장한 내역은 최근의 것 부터 0부터 인덱싱 된다.

임시 저장된 작업 적용하기

• git stash apply <stash>
• 뒤의 stash를 생략하면 가장 최근의 stash가 적용됩니다.

stash#{0}을 적용해보자

• git stash apply stash@{0}
  - 적용 된 것을 확인해보자.
  

임시 작업 삭제

• drop
• git stash drop <stash>

✔ branch

• 버전을 여러 흐름으로 나누어 관리하는 것

branch를 만들어서 여러 흐름으로 나누어 관리해야 하는 이유

어느 정도 만들어진 쇼핑몰 코드를 수정해야 하는 경우

• 한 명의 개발자가 장바구니 기능을 추가하고, 다른 개발자가 주문 목록 기능을 추가하려고 하는 경우
  - 이런 경우, 서로 간의 작업 내용은 서로의 작업과 전혀 관련 없는 부분이 있을 것이고, 때로는 같은 코드를 다르게 수정하는 부분도 있음
  - branch가 없다면, 이 경우에는 코드를 하나하나 대조하고 합칠 코드를 판단하는 작업을 해야 하기에 번거롭다.
  - 수작업으로 하다 보면 오류가 생길 가능성이 존재한다.
• 이런 경우, 동일한 코드를 가지고 다른 브랜치를 만들어서 각각 작업을 하도록 하고 이를 merge하게 되면 코드를 하나하나 살펴봐야하는 번거로움이 없어짐
  - 하지만, 이 경우에도 같은 코드를 다르게 수정하는 부분은 확인해야 한다.
  - branch를 나누어서 작업할 때 주의할 점은, 동일한 코드를 다르게 수정하는 충돌의 부분이다.
  - 이렇게 된다면 어떤 작업을 적용할 지 나중에 결정해야 한다.

현재 브랜치 확인

• git branch
• git status
  - HEAD가 가리키는 것이 현재 브랜치이다.

checkout

• checkout은 해당 브랜치로 작업 환경을 변경하는 것이다.
  - git checkout <브랜치>
• 브랜치를 만들면서 체크아웃을 할 수 있음
  - git checkout -b <브랜치>

git merge <브랜치>

• 브랜치를 병합하는 기능
• 현재 브랜치에 브랜치를 병합하는 기능
  - 변경 내용을 적용
• git checkout main
• git merge <브랜치>
  - 이렇게 한다면 main 브랜치에 <브랜치>를 병합하는 것이다.
  

충돌

• 브랜치를 병합할 때 충돌이 발생할 수 있습니다.
  - 이 경우는 서로 다른 브랜치에서 동일한 파일을 서로 다른 내용을 수정한 상태에서 병합을 하고자 하는 경우입니다.
  - 변경 내용 중 하나를 선택하고, 다시 add->commit을 해야 충돌나지 않는다.
  

브랜치 삭제

• git branch -d <브랜치이름>
• git branch --delete <브랜치이름>
• 하지만 현재 브랜치는 삭제가 안되기에 다른 브랜치로 checkout을 하고 삭제를 진행해야 합니다.
• 하고 git branch를 통해 브랜치가 잘 삭제되었는지 확인해보자.

git rebase <브랜치>

• 브랜치를 재배치하는 명령
• 브랜치의 재배치는 뻗어나온 기준점을 옮기는 방법이다.

실습

• main : A->B->C
• foo : A->B->C
• main 브랜치에서 D->E를 추가해서 commit
• foo 브랜치의 기준점을 main 브랜치의 가장 최근 commit으로 이동하고 싶다
  - foo 브랜치에서 git rebase main을 수행하면 된다.
  - 기준점을 바꾼다면 merge를 하지 않아도 다른 branch의 변경 내용을 받아올 수 있다는 것이다. merge와는 다른 개념이다.

• git hub에서는 다른 유저의 프로젝트의 fork를 설정했는데, 해당 유저의 branch에 변경이 발생하면 fork된 프로젝트에는 경고가 발생한다.
  - 그런 경우에는 프로젝트를 업데이트하라는 메시지가 출력되는데, 이 작업이 rebase와 유사합니다.