SK networks AI Camp - 버전관리 시스템&Git

버전 관리 시스템

: 문서나 설계도, 소스 코드 등의 변경점을 관리해주는 소프트웨어

○ 버전 관리 필요성

  : 파일을 편집할 때마다 매번 복사하는 일은 번거롭고 실수할 가능성 多

 

○ 버전 관리 장점

    ● 변경점 관리 : 어떤 내용을 누가 작성해서 어느 시점에 들어갔는지 확인 가능
    ● 버전 관리 : 특정 시점에 Tag를 달아 버전 표시, branch를 통해 동시에 여러 버전 개발 가능
    ● 백업&복구 : 잘못될 경우 다시 특정 시점으로 돌아갈 수 있고, 복구도 가능

버전 관리 종류

○ 로컬 버전 관리

    ● 버전관리를 위해 디렉토리로 파일을 복사하는 방법을 사용
    ● 간단하므로 자주 사용 But 뭔가 잘못되기 쉽고, 파일을 잘못 수정/복사/삭제 가능

 

○ 중앙 집중식 버전 관리

    ● 프로젝트 진행 시 함께 작업하는 경우 多. 이럴 때 발생하는 문제 해결을 위해 CVCS(중앙집중식 VCS) 사용

    ● 몇가지 치명적 결점 존재 : 중앙서버에 문제가 발생할 경우

 

○ 분산 버전 관리 시스템

    ● Git, Mecurial, Bazaar, Darcs 같은 DVCS에서의 클라이언트는 단순히 파일의 마지막 스냅샷을 Checkout 하지 않음

    ● 저장소를 히스토리와 더불어 전부 복제, 서버에 문제 발생 시 복제물로 다시 작업 가능

    ● 클라이언트 중에서 아무거나 골라도 서버 복원 가능(Clone은 모든 데이터를 가진 진정한 백업)

---

Github 저장소

: 원격 저장소와 로컬 저장소 두 종류의 저장소를 제공

 - 원격 저장소(Remote Repository) : 원격 저장소 전용 서버에서 관리되며 여러 사람이 함께 공유하기 위한 저장소

 - 로컬 저장소(Local Repository) : 내 PC에 파일이 저장되는 개인 전용 저장소 

Git 상태

○ Committed : 데이터가 로컬 DB에 안전하게 저장됐다는 것 

○ Modified : 수정한 파일을 아직 로컬 DB에 커밋하지 않은 것

○ Staged :  현재 수정한 파일을 곧 커밋할 것이라고 표시한 상태

○ 다른 버전 관리 시스템과 달리, Git은 커밋 이전에 스테이징(Stage area) or 인덱스라 불리는 상태를 가짐

   이 상태에서 커밋 내역을 검토하고 특정 파일만 먼저 커밋하고 일부 파일은 나중에 커밋 가능

브랜치(Branch)

○ 여러 개발자들이 동시에 다양한 작업을 할 수 있게 만들어 주는 기능

○ 각자 독립적인 저장소 안에서 마음대로 코드 수정 가능

○ 이렇게 분리된 작업 영역에서 변경된 내용은 나중에 원래 버전과 비교해서 하나의 새로운 버전으로 만들어 낼 수 있음

○ 이렇게 만들어진 브랜치는 다른 브랜치와 병합(Merge)함으로, 작업 내용을 다시 새로운 하나의 브랜치로 모으기 가능

브랜치 전략

Git Flow의 특징: 브랜치가 5가지로 나뉜다는 특징

○ main(master) : 서비스를 직접 배포하는 역할

○ feature(기능) : 각 기능 별 개발 브랜치

○ develop(개발) : feature에서 개발된 내용이 저장되는 브랜치

○ release(배포) : 배포하기전 QA(품질 검사)하기 위한 브랜치

○ hotfix(빨리 고치기) : main 브랜치로 배포를 하고 나서 버그를 생겼을 때 빨리 고치기 위한 브랜치

---

Git 기본 명령어

○ git init : (로컬)저장소 생성

○ git status : 현재 상태 확인

○ git add : 현재 상태 추적

○ git commit : 현재 상태 저장

○ git log : 커밋 히스토리 조회

○ git reset : 이전 상태로(이력제거)

○ git revert : 이전 상태로(이력 유지)

---

branch 사용법

○ git switch -c -브랜치 생성

    - 새 브랜치를 만들 때, 현재 브렌치를 기준으로 만들기 때문에 현재 브랜치 확인이 중요!!!

  ● 작업

    - 브랜치 확인 → 새로운 브랜치 생성

git status
git switch -c add-color

* git switch의 -c 옵션은 브랜치 생성과 이동을 한번에 수행하여 아래의 명령어와 동일

git branch add-color
git switch add-color

○ add-color 브랜치에서 작업

  ● 작업

    - green, blue 파일 추가

    - 전체 변경사항을 인덱스에 추가

    - 커밋 작성

touch green blue #1
echo "green1" >> green
echo "blue1" >> blue
git add -A #2
git commit -m "add green, blue" #3

○ git switch - 브랜치 변경

  ● add-color 브랜치에서 진행한 작업이 기존 main 브랜치와 독립적인 것을 확인

  ● 작업

    - 현재(add-color) 파일 확인

    - 브랜치 리스트 확인

    - master 브랜치로 이동

    - 파일 다시 확인 ==> green, blue 파일이 없음(= main 브랜치와 독립적임)

ls #1
git branch # 2. : 나가기; q
git switch master # 3
ls #4

○ update-red 브랜치 추가

  ● 작업

    - update-red 브랜치 생성 후 이동

    - red 파일 내용 변경

    - 전체 변경사항을 인덱스에 추가

    - 커밋 작성

git switch -c update-red #1
echo "red11" >> red #2
git add -A #3
git commit -m "update red" #4

○ 현재 브랜치 상황

  ● master : red, orange, yellow

  ● add-color : red, orange, yellow, green, blue

  ● update-red : red(변경), orange, yellow

 

○ git merge - 브랜치 합치기

  ● 작업

    - master 브랜치로 이동

    - add-color 브랜치 수정사항을 master 브랜치로 merge

    - add-color에서 작성한 커밋로그가 master 브랜치에도 추가된 것을 확인

    - master 브랜치에서 green, blue 파일이 추가된 것을 확인

git switch master #1
git merge add-color #2
git log #3
ls #4

○ 결과 정리

  ● add-color에서 작업한 내용(파일들)이 master 브랜치로 머지됨

  ● master 브랜치에 green, blue파일 추가된 것을 확인

  ● add-color에서 작성한 커밋 로그가 master 브랜치에도 추가된 것을 확인

 

○ conflict - 충돌 해결

update-red 브랜치에서 수정한 red 파일을 master 브랜치에서도 수정하여 충돌상황을 생성해보기

  ● 작업

    - master 브랜치에서 red 파일 수정

    - 전체 변경 사항을 인덱스에 추가

    - 커밋 작성

    - update-red 브랜치를 master 브랜치로 머지

   ==> 충돌 발생

echo "red111" >> red
git add -A
git commit -m "update red111"
git merge update-red # 충돌!

○ 충돌내용 확인

  ● red 파일 확인(충돌내용 확인!)

cat red

○ 충돌 해결

    - red파일에서 필요없는 내용 모두 삭제(수정)

    - 전체 변경사항을 인덱스에 추가

    - 커밋 진행

      ==> vi 창이 열리면, ecs 누르고 :x를 입력 후 엔터

git add -A
git commit

---

.gitignore

○ 프로젝트 작업시 로컬 환경의 정보나 빌드 정보 등 원격 저장소에 관리하지 말아야되는 파일에 대해 지정해

   원격 저장소에 실수로 올라가지 않도록 관리하는 파일

○ 정의한 정보들에 해당하는 파일에 대해 git track하지 않도록 설정하는 역할

○ 사용 규칙

    ● '#'로 시작하는 라인은 무시

    ● 슬래시(/)로 시작하면 하위 디렉터리에 적용되지 않는다.

    ● 디렉터리는 슬래시(/)를 끝에 사용하는 것으로 표현

    ● 느낌표(!)로 시작하는 패턴의 파일은 무시 안됨

○ 예시

// 1. '파일명'으로 제외 (* 경로 상관없이 지정한 파일명으로 모두 제외 가능)
ignoreFileName.js

// 2. 특정 '파일'만 제외 (* 현재 기준을 .ignore파일이 있는 경로라고 생각)
src/ignoreFileName.js

// 3. 특정 '디렉토리' 기준 이하 파일들 제외
node_module/

// 4. 특정 디렉토리 하위의 특정 '확장자' 제외
src/*.txt

// 5. 특정 디렉토리 하위의 그 하위의 특정 '확장자' 제외
src/**/*.txt

// 6. 특정 '확장자' 제외 
.txt

// 7. 4번 특정 '확장자'에서 일부 제외 할 파일 
!manual.txt

○ .gitignore 파일 생성

  ● 직접 파일 생성

    1. VSCode 폴더의 최상위에서 새파일 생성

    2. 파일이름을 .gitignore 라고 지정된 이름으로 생성

  ● 터미널 명령어

    - 생성하려는 Repository의 최상위에서 아래의 명령어 입력

touch .gitignore

○ gitignore 필요한 내용 사이트

https://www.toptal.com/developers/gitignore

gitignore.io

○ gitignore가 작동되지 않을 때 대처법

git rm -r --cached .
git add .

○ commit/push된 파일 제외 방법

git rm .env --cached
git add .
git commit -m "remove .env file from git"
git push

○ .gitignore에서 제외할 파일

  : "!" 기호를 파일명 앞에 적어두면 해당 파일은 제외되지 않음

# *.keystore
!debug.keystore
my-release-key.keystore