버전 관리 시스템 (VCS : Version Control System)

• VCS : 소프트웨어의 파일(코드, 구조 등)에 가해진 변경을 추적하여 관리하는 소프트웨어.
  SCM(Source Code Management System)이라고도 불린다.

• 다양한 종류의 VCS가 사용되고 있음.

  • RCS, CVS : 요즘은 거의 사용되지 않음
  • Subversion(SVN) :
  • Git : 최근에 가장 많이 사용됨

• 역할 :

  • 모든 팀원이 접근할 수 있는 하나의 master repository를 제공함
  • 현재 버전과 백업버전을 포함하여, 소스코드의 여러 버전을 관리함
  • 팀원들이 어떠한 변경을 가했는지 알 수 있도록 해줌
  • 여러 팀원이 같은 소스파일에 가한 변경의 충돌을 관리해줌
  • 소프트웨어 코드 뿐만 아니라 다른 리소스(사진, 여러 문서 등)에도 적용 가능

---

Repository

• Repository : SW의 변경사항들을 기록해주는 Database

Centralized VCS

• 중앙집중식 버전 관리 시스템 : 가장 일반적인 방법
  

Distributed VCS

• 분산형 버전 관리 시스템 :
  더욱 복잡한 시스템에 쓰이고, computer들끼리도 동기화.
  

---

Git

git :
Linus Torvalds가 linux kernel을 개발하기 위해 만들어 졌다.
지금은 많은 SW 회사들이 사용하고 있다.

Git Advantages

• Speed
• Simple design
• support for non-linear development (thousands of parallel branches)
• Fully distributed
• Able to handle large projects

Git uses snapshot storage

• delta storage :
  변경이 가해지면, diff만 저장하여 original file에 diff를 적용함.
  최종적으로 생성된 file은 original file에서 모든 diff를 적용하기 때문에
  overhead가 크고, 시간이 오래 걸린다.
  
• snapshot storage :
  변경이 일어난 파일들만 copy 파일을 저장.
  파일 사이즈가 작기 때문에 저장용량 측면에서 큰 차이가 없음.
  

Three states

• Three states
  
  • git repository (Commited) :
    repository에 실제적으로 저장되어 있는 directory.
  • working directory (Modified) :
    git repository에 있는 project의 copy를 나의 local directory로 복사해 온다.
    = git repository에 있는 project를 checkout해오고 나서, 소스 코드를 수정한다.
  • staging area (Staged) :
    수정한 file을 바로 commit하는 것이 아니라,
    중간에 staging area라고 하는 일종의 buffer에 저장한다.
    가한 변경이 적절하게 변경되었는지 review하고 나서 최종적으로 commit한다.

Basic workflow

• Basic workflow
  
  1. (init or clone) Init a repository
  2. You modify files in your working directory
  3. You stage the files to your staging area
  4. You do a commit, which stores the files in staging area permanently in your Git directory.

---

Getting Started

Installing Git

https://git-scm.com/book/en/v2/Getting-Started-Installing-Git

• On Ubuntu : sudo apt-get install git
  

First-time Git setup

https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup

• Your Identity :
  
• Your Editor : 주로 사용하는 editor 지정
  
• Checking your settings :
  

Getting a Git repository

• A basic workflow :
  
  1. Init a repository or Cloning an existing repository
  2. Edit files :
     
  3. Stage the changes :
  4. Review your changes :
     git add hello.txt
     git status
     
  5. Commit the changes :
     git commit -m "commit에 대한 설명"
     

• View history : 현재까지의 변경사항을 보여준다
  git log
  • options :
    git log -p : to check specific diff
    git log --stat : to check summarized changes
    git log --since=1.days : to check changes since 1 days ago

---

Branching and Merging

• 우리가 개발하는 SW에 main line이 있는데,
  main line에서 벗어나 별도로 다른 방향으로 SW를 개발할 때, branching한다고 한다.
  branching한 작업을 main line으로 합치는 과정을 merging이라고 한다.
  ➡️ non-linear하게 동시에 여러가지 일을 개발할 수 있기 때문에 사용함

• 시나리오 1
  git commit -m "my first commit"git commit
  git commitgit checkout -b bug123 ➡️ 기존의 master에서 bug123으로 branch하겠다.
  git branch ➡️ "master, bug123(*)" 출력git commit
  git commit
  git checkout master ➡️ pointer를 master branch로 옮기기
  git merge bug123 ➡️ 현재 branch와 bug123 branch를 merge하라.git branch -d bug123 ➡️ bug123 branch를 없애라.
  

• 시나리오 2 :
  master branch와 bug456 branch는 서로 다른 작업으로 진행되고 있다.
  git checkout mastergit merge bug456만약 두 branch를 merge할 때,
  master branch의 D, E 변경과 bug456의 F, G 변경이 disjoint하다면 문제 없이 merge된다.
  예를 들어, mastser branch에서는 func1을 update했고, bug456은 func2를 update 하면? 문제 없음.
  하지만 두 branch에서 동일한 함수에 대해서 변경이 있었다면, merge가 자동적으로 될 수 없다.
  이렇게 conflict가 발생한다면, 우리는 conflict가 발생한 부분을 직접 고쳐야 한다.
  그리고나서
  git branch -d bug456

---

GitHub 실습

1. clone

• 실습할 디렉터리에 clone하여 project 가져오기
  

git log

• git log
  
• git log -p
  
• git log --oneline
  
• git log --oneline --graph
  
• git log --stat
  

git checkout, git branch, git status, git add, git commit, git merge

• git checkout d379
  "d3797da402568f3aa72cb511666a3307b0f86474"는 hash code이다.
  commit한 지점마다 hash code가 생성되는데,
  앞의 4글자 "d379"만을 이용하여 해당 지점으로 jump할 수 있다.
  "d379" 지점은 main 함수에서 goo()함수를 호출하기 직전 버전이다.
  가장 최신(현재) 버전
  "d379" commit 시점 버전
• git branch :
  현재 main branch와 "d379"에서의 branch가 있다.
  현재 branch는 "d379" branch이다.
  
• git branch myexp :
  "d379" version에서 myexp라는 새로운 branch를 생성.
  
• git checkout myexp :
  새로 만들어진 myexp branch에서 zoo()라는 함수 개발해보자.
  개발하기 위해 기존 code들 변경.
• git status :
  위에서 변경했던 사항들을 확인.
  아직 staging area에 보내지지는 않고, modified만 된 상태이다.
  
• git add :
  modified된 사항들을 staging area로 보내기.
  
• git commit :
  stage된 파일들을 commit하기
  
• git checkout main; git merge(myexp) :
  zoo()함수 개발이 끝났으니, main branch로 전화하여 myexp branch와 merging.
  
• git branch -d myexp :
  myexp branch 제거하기
  
• git branch -M <바꿀 branch명> :
  branch명을 바꾸기
  

2. init

• git init
  
• include/funcs.h 생성하고, initial commit하기.
  
• Makefile 생성하고, commit하기
  
  1. 방법 git restore --staged bin/myapp obj/*.o :
     bin/myapp과 obj/*.o file들은 굳이 저장할 필요 없으니까 staging area에서 제외시킨다.
  2. 방법 .gitignore file 생성 :
     매번 "git restore --staged bin/myapp obj/*.o" 작성하는 것은 귀찮으니까
     .gitignore file에 staging, commig하지 않을 파일들을 지정해준다.
     (bin/, obj/ file들이 생겼어도 staging되지 않은 것을 알 수 있다.)
• zoo() 함수 추가하기.
  
• zoo() 함수 추가하기 전으로 branching해서, koo() 함수 만들고,
master branch와 merging하기.
  master branch와 kooexp branch merge하기.conflict가 발생하여, 기존의 zoo() 함수 지우고, 새로 개발한 koo() 함수로 변경.
• git remote add origin <생성된 github 원격 repository link> :
  
• git branch -M main :
  master branch name을 "main"으로 바꾸기
  
• git pull main == git fetch origin; git merge origin/main :
  git pull main
git fetch origin; git merge origin.main