버전 관리 시스템 (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 (Working in a team)

• shared repository model(remote repo)이 있음.
  각각의 개발자들은 그 remote repo을 checkout해서, 본인의 작업을 수행.

• Github는 shared repository model(remote repo)를 만들 수 있게 하는 대표적인 서비스

---

Git 실습

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명을 바꾸기
  

• github remote repository에 내가 생성한 remote repository add하기
  
• remote repository 다시 삭제하기
  

2. init하여 초기화 (새로 개발)

• git configuration
  

• git init
  

• git add .: stating area로 보내기
  

• • .gitignore
    바로 위에서 git add를 했는데 object file이나 library file들이 포함되어있다.
    이들을 빼고 싶음..
    1. (비추천) git resotre --staged {파일명}
       매번 git add 할 때마다 해줘야 하니까 추천되지 않는 방법이다.
       그래도 일단 실행해보면,,, 지금 첫 commit을 하지 않은 상태니까 위 명령어가 먹지를 않는다.
       이럴 때는 git rm --cached {파일명}
       
    2. (추천) .gitignore 파일에서 변경을 추적하지 않을 파일들을 명시해줄 수 있다
       (before .gitignore)
       (after .gitignore) object files나 library들이 추적되지 않는 것을 볼 수 있다.

• git commit -m "message"
  

• git remote repository 생성 후, local repository를 remote repository에 연결
  (아직 remote repository에 연결되어 있지 않다.)
  

• git push -u {리모트이름} {localbranch이름}
  이제 remote repository에 local repository를 push.
  그 전에 우선 local branch명을 master에서 main으로 변경.(github repository 새로고침)
  

• 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

---

Github 실습

week09_git/ 생성,
add, sub, mul, div하는 프로그램 빌드 (make file 사용 X)
조건 1: build시, make file 이용 X
조건 2: myadd, mysub, mymul, mydiv에 대한 각각의 object file들을 공유 라이브러리 /lib/myops.so로 만들기
조건 3: myapp.c와 linking하여 최종 실행 파일로 빌드

현재까지 진행상황을 commit하고, remote repository에 push

새로운 advanced_dev branch 생성 후, commit
mypow mymod 개발하여 프로그램 빌드
조건 1: build시, make file 이용 X
조건 2: mymod, mypow에 대한 각각의 object file들을 공유 라이브러리 /lib/myops.so로 만들기
조건 3: myapp.c와 linking하여 최종 실행 파일로 빌드

main branch로 checkout 후, advanced branch와 merge

merge하지 않았으니 main branch는 아직 advanced branch에서의 변경사항이 적용되지 않음.

remote repository에 push

아래 사진에서 보이듯, 현재 local branch가 remote branch보다 1 commit 앞서있는 상황이므로 remote branch에 현재 변경 사항을 push해줘야 함.

위에서 최종적으로 빌드했던 bin/myapp을 makefile을 이용하여 빌드할 것임.
makefile 생성 후, push

remote repository에서 README.md 생성 또는 수정 후, local repository로 git pull (fetch + merge)

이제 remote repository에서 가한 변경을 local에 가져오기 pull(fetch + merge)
git pull origin main = git fetch origin; git merge origin/main