[오픈소스] - Git을 활용한 소스코드 관리

< 버전관리 >

- 공학과 소프트웨어 개발에서 팀 단위로 개발 중인 소스 코드나 청사진 같은 설계도 등의 디지털 문서를 관리하는데 사용됨

- 소스 관리, 소스코드 관리

 

< 버전관리 시스템 >

- 동일한 정보에 대한 여러 버전을 관리 (공동 프로젝트 관리, 프로젝트 백업, 데이터 동기화 / 파일 변화를 시간에 따라 기록하여, 나중에 특정 시점의 버전을 다시 꺼내 올 수 있는 시스템)

- 로컬 파일 버전 관리 ( 파일을 편집 전 상태로 되돌리고 싶을 때 : 편집 하기 전 파일 복사 -> 파일 or 폴더명에 날짜, 버전)

- 로컬 버전 관리 시스템 (LVCS) : 간단한 데이터베이스를 사용하여 파일의 변경 정보 관리

- 중앙집중식 버전 관리 시스템 (CVCS) : 파일을 관리하는 서버가 별도로 존재하고, 클라이언트가 중앙 서버에서 파일을 받아서 사용 (클라이언트 서버 모델, 중앙 저장소에서 프로젝트 관리의 모든 것을 처리)

- 분산 버전 관리 시스템 (DVCS) 
    -> 단순히 파일의 마지막 스냅셧을 체크아웃 하지 않음
    -> 저장소 전부를 복제
    -> 모든 체크아웃은 모든 데이터를 가진 진정한 백업, 서버에 문제가 생기면 어떤 클라이언트 중에 하나를 골라도 서버를 복원할 수 있음
    -> ex. Git

 

 

< Git >

- 소스코드 관리를 위한 분산 버전 관리 시스템

- 2005년 4월 리눅스 토발즈가 오픈소스 리눅스 커널 개발의 효율성을 높이기 위해 개발

- 라이선스 : GNU GPL 2.0

- 프로그래밍 언어 : C, Shell, Perl, Tcl, Python

 

< Git의 핵심 >

- 차이가 아닌 스냅샷 

   -> 데이터를 파일 시스템 스냅샷으로 취급

   -> 파일이 달라지지 않으면, 파일 새로 저장 안 함 ( 이전 상태의 파일에 대한 링크 저장)

   -> 데이터를 스냅샷의 스트림처럼 취급

- 거의 모든 명령을 로컬에서 실행

  -> 원격 저장소 vs 로컬 저장소

      -> 평소에는 내 PC의 로컬 저장소에서 작업하다가 작업한 내용을 공개하고 싶을 때 원격에 업로드 ( 원격에서 타인이 작업한 것도 나의 로컬로 가져올 수 있음)

     -> 거의 모든 명령이 로컬 파일과 데이터만 사용
     -> 히스토리가 로컬 디스크에 있기 때문에 모든 명령이 순식간에 실행

     -> 오프라인 상태에서도 작업 가능 ( SVN은 오프라인으로 편집은 가능하지만 커밋은 불가능 )

- Git의 무결성

   -> Git은 데이터를 저장하기 전에 항상 체크섬을 구하고, 그 체크섬으로 데이터를 관리

   -> Git 모르게 파일이나 디렉토리 수정하는 것은 불가능

   -> Git은 모든 것을 이 해시 값으로 판별

- Git은 데이터를 추가할 뿐

   -> Git으로 무엇을 하든 Git 데이터베이스에 데이터가 추가됨

   -> 커밋을 하고 나면, 변경사항들을 잃어버리거나 망칠 것을 걱정할 필요가 없음

 

- Git의 3가지 상태

   1. Modified : 파일을 수정하긴 했지만, 아직 로컬 데이터베이스에 Commit하지 않은 상태

   2. Staged : 현재 수정한 파일이 다음 커밋 스냅샷에 포함될 거라고 표시한 상태

   3. Committed(unmodefifed) : 데이터가 로컬 데이터베이스에 안전하게 저장됐다는 것을 의미

- Git의 구조

    1. Working Directory : 프로젝트에서 하나의 체크아웃 버전

    2. Staging Area : 다음 커밋에 대한 어떠한 내용이 포함될 것인지를 저장하는 파일

    3. .git directory : Git이 프로젝트의 메타데이터와 객체 데이터베이스를 저장하는 장소

- Git의 워크플로우

   - 워킹트리에서 파일을 수정 (modified)

  - Staging Area에 파일을 스테이징해서 커밋할 스냅샷을 만듦

  - Staging Area에 있는 파일들을 커밋해서 Git 디렉토리에 영구적인 스냅샷으로 저장 (committed)

 

 

< Git 최초 설정 >

git config
① /etc/gitconfig
• 시스템의 모든 사용자와 모든 저장소에 적용되는 설정
• git config --system 옵션으로 이 파일을 읽고 쓸 수 있음
② ~/.gitconfig, ~/.config/git/config
• 특정 사용자에게만 적용되는 설정
• git config --global 옵션으로 이 파일을 읽고 쓸 수 있음
③ .git/config
• 이 파일은 .git directory에 있고, 특정 저장소 (혹은 현
재 작업 중인 프로젝트)에만 적용됨
• git config –local 옵션으로 이 파일을 읽고 쓸 수 있음
- 우선순위: 3 -> 2 -> 1

 

- 설정확인 : git config --list

- 도움말 보기 

  1. git help <verb>

  2. git <verb> --help

  3. man git -<verb>

 

 

< Git 기초 >

1. Git Repository 만들기

- git init : 기존 디렉토리를 git 저장소로 만들기

mkdir my_repo
cd my_repo
git init

기존 프로젝트를 git으로 관리하고 싶을 때 사용

.git디렉토리 생성

아직 어떤 파일도 관리하지 않음

 

- git clone : 기존 저장소를 clone하기

git clone <repo주소>

 

- file lifecycle

 

 

< Git 기본 명령어 >

- git add : 변경사항을 스테이징 에리어(index)에 반영

- git status : 현재 파일 상태 (커밋, 브랜치 등 ) 볼 수 있음

- git commit : 변경사항 커밋하기 (staged 상태의 파일들을 커밋)

- git commit - m : 변경사항 커밋하기 (인라인 메세지)

- git log : commit history 조회

- git rm : 파일 삭제하기

- git restore --staged : 되돌리기 (staging area의 파일을 HEAD로부터 복구 (파일 두 개 수정하고서 따로 커밋하려 했지만, 실수로 git add * 한 경우)

- git restore (--worktree) : 워킹 디렉토리의 파일을 스테이징 에리어의 파일로부터 복구

- git commit --amend : 완료한 커밋 수정하기

- git rebase -i : 대화형 모드로 rebase수행 

- git rm --cached : staging에서만 제거하고 working tree에는 유지

- git diff : staged & unstaged 상태의 변경 내용 보기

 

< commit convention & message >

① commit의 종류 명시
• feat
• fix
• chore
• refactor
• docs
• style
• test
• perf
• ci
• build
• revert

② 제목과 본문을 빈 행으로 구분
③ commit message에 공백오류가 포함되지 않도록
④ 불필요한 구두점 제거
⑤ 제목은 마침표로 끝내지 말 것
⑥ 제목과 각 문단의 시작은 대문자로
⑦ 제목은 명령조로 쓸 것

⑧ 본문에는 무엇(what)이 바뀌었는지, 왜(why) 그것을 만들었는지 쓸 것(Not how)
⑨ 코드 리뷰어가 원래 문제가 무엇이었는지 이해하고 있다고 가정하지 말고, 어떤 문제를 해결하는 commit인지 작성
⑩ 작성한 코드가 너무 간단해서 설명이 필요 없는 코드라고 생각하지 말 것
⑪ 팀에서 정한 commit convention을 따를 것

 

** commit 이란 ?

- staged 상태에 있는 변경사항들을 로컬 레포에 반영하는 명령

- 커밋을 위해서는 커밋 메세지 필요

 

 

 

< Git : 계통 관계로 commit 표현 >

 계통 관계 예시
- HEAD^: HEAD의 부모 (즉, 바로 이전 Commit)
- d921970^2: d921970의 두 번째 부모
• Merge의 경우에만 두 번째 부모(대상 Branch) 존재
- HEAD~: HEAD의 첫 번째 부모
- HEAD~2: 첫 번째 부모의 첫 번째 부모
• == HEAD^^
- HEAD~3^2: 첫 번째 부모의 첫 번째 부모의 첫 번째 부모의 두 번째 부모

 

< Git reset 이해하기 >

Restore vs. Reset
- Restore
• Commit 영역과 Staging 영역으로부터 파일을 WorkingDirectory에 복구하는 용도
• Branch를 업데이트하지 않음

- Reset
• Branch를 업데이트하여, Commit들을 삭제하거나 추가할수 있음
• Commit History에 영향을 줌