참고 자료

• Git-scm
• edwith Git과 GitHub 활용 특강

1. 버전 관리

---

어떤 파일을 만들 때, 수정 중간중간 포인트를 찍어 파일을 만들어 두는 것을 버전이라고 한다. 우리는 버전을 많이 사용해봤다.

* 최종
* 진짜-최종
* 진짜-진짜-최종
* 진짜-진짜-진짜-최종

뭐 이런 식으로. 하지만 이러한 방법으로 버전을 관리하는 구조, 즉 이러한 버전 관리 시스템(VCS - Version Control System)은 단점이 있다.
마지막 버전을 잘못 가져온다거나, 파일이나 폴더를 삭제해버리는 경우...으악

그래서 개발자들은 고민했다.

1) RCS (Revision Control System)

---

파일에서 새롭게 변경되는 부분에 대해 저장(Patch Set)한다.

A -△a-> B

△a 에 대해 저장하는 것이다. 단순하다.

그런데, 다른 개발자와 함께 작업하고 싶다면 어떻게 해야할까?
즉, 여러 사람마다 여러 버전이 생길 때 어떻게 해야할까?

2) CVCS (중앙집중식 VCS, Centerlized Version Control System)

파일을 중앙 서버에 두고, 클라이언트가 서버에서 받아서 사용하는 구조이다.
하지만 이러한 시스템은 서버가 문제가 생기거나, Client A가 파일에 대한 업데이트 작업을 수행하고 있을 경우, lock(OS에서 배웠던 그 개념!)이 걸려 다른 사용자가 파일 업데이트 작업을 수행할 수 없다. 으악!

3) DVCS (분산 VCS, Distributed VCS)

각 client가 파일을 전부 복제하여 가져간 후 수정하는 구조이다. 파일의 lock 문제가 생기지 않는다. 그런데, 그러면 여러 사람에게 수정된 여러 파일을 어떻게 합칠까? 일일히 비교하며 해야할까?

Git

그래서 Linux 창시자가 만든 도구!

• 모든 명령을 로컬에서 진행 : 각자의 컴퓨터에서 진행한다
• 모든 변화를 파일의 스냅샷으로 취급 : 전체를 복사해온다!
• 데이터를 추가할 뿐 삭제나 변경하지 않음 : 1-1 = 1+(-1) : 삭제했다는 사실을 추가할 뿐

어어 잠깐 GitHub는 무엇일까

Git은 우리 컴퓨터에서 작동되며,
그걸 GitHub에 올리는 것이다. 서버인셈!
자세한 건 아래에서!

Git의 단계

파일을 수정한 후, staging area에 임시로 스냅샷을 만들고, commit을 통해 git directory에 저장한다.

Git의 파일 상태

그래서 git은 단계별로 파일 상태를 구분해 둔다.

• Modified
  수정한 파일을 아직 로컬 데이터베이스, staging area에 추가하지 않음
• Staged
  현재 수정한 파일을 곧 커밋할 것이라고 표시함. staging area에 추가함
• Commited
  데이터가 로컬 데이터베이스에 안전하게 저장됨. git directory에 commit 완료

2. Git 설정

git을 컴퓨터에 설치한 후,
(windows 기준) window + x > Windows powershell 또는 window + r > cmd를 이용하여 명령창을 띄운다.
(※ 참고 | powershell은 cmd와는 다르게 객체를 사용한다고 한다)

git config --global user.name "Huttzza"
git config --global user.email "hi.huttzza@gmail.com"

이름과 이메일을 설정한다.

설정 확인은

git config --list

로 할 수 있다.

3. staging area : git의 file lifecycle

1) 먼저, working directory 만들기

git init

git init

.git이라는 하위 디렉토리가 생성된다.

git clone

git clone <url>

참고 : git status

git status

를 통해 현재 staging area의 파일 상태를 확인할 수 있다.

2) staging area

woring directory의 모든 파일은 Tracked, Untracked로 나뉜다.

untracked

git에서 관리하고 있지 않은 파일.
파일이 처음 생성되면 모두 이 상태다.

git add [filename/.]

를 통해 tracked로 옮길 수 있다. 즉 staged 상태, committed 대상자 상태(changes to be committed)가 된다.

modified

git이 관리할 파일이고, 변경사항이 발생했을 때
다시 git add를 통해 tracked(staged 상태)로 옮길 수 있다.

참고 : git status -s

git status -s를 통해 상태를 짧게 출력할 수 있다.

• A git에 추가되었다.
• ?? git 당황 untracked
• M 변경사항 있다!
• D 지워진 게 있다.
• R 변경된 것이 있다!

참고 : .gitignore

git이 무시해도 되는 파일 목록이다.

참고 : git diff

git diff

unstaged 상태인 tracked 파일에 대한 변경사항을 확인할 수 있다.

• -로 표시되어 볼 수 있다.

3) commit

staged 상태에 저장된 수정 사항은 commit을 통해 git repository(local repository)에 저장된다.

• git commit vi 등의 편집기로 자세하게 수정할 수 있다.
• git commit -m "message" 간단하게 요로케

참고 : git commit -a

staging area를 아예 생략하고 tracked 파일을 자동으로 commit 한다.
git add를 안 해도 된다.
하지만 추가하지 말아야할 변경사항도 추가되기 때문에 주의해야한다.

참고 : git rm

rm하면 status가 unstage상태로 간다.
git rm file 하면 status가 staged 상태로 감, commit 해주어야 한다.

참고 : git mv

파일 이름 바꾸기

참고 : git log

git log commit기록 확인 가능

• git log -p 옵션은 diff 결과를 보여주기 때문에 유용하다.

4. Git reset 되돌리기

git restore

git restore <file>

modified된 파일을 되돌리기

git restore --staged <file>

staged 상태의 파일을 unstaged 상태로

git --ammend

git commit --ammend를 통해 커밋 재작성 가능/메시지 없이 기존 커밋 덮어쓰기

GUI 소프트웨어
그런데, 이렇게 콘솔창에서 명령어 치는 거 말고, GUI에서 시각적으로 할 수 있는 방법이 있다.

• 무료
  • git fork
  • sourcetree
    
• 유료(학생은 무료)
  • TOWER
  • Gitkraken

Visual Studio Git
참고
extension이 있다고 한다.
Visual Code Git
이미 탭에 기능이 있다! 와웅

5. Github

혼자 개발하는 것도 중요하지만, 더 중요한 것은 팀 개발

팀단위 개발의 어려움

• 동일한 함수를 동시에 수정
• 변수/함수/클래스명 겹침
• 버그 서로 떠밀기

"Manage Issue, Review Code"

• '코드'를 관리하는 게 아니라, 'issue'를 관리!
  누가 이 코드 짰냐, 따지는 것은 상처만 남음
  (Jira, Trello, RedMine)
• 모든 코드는 동료가 '읽을 수 있어야' 하기 때문에 '동료 평가(peer review)'가 필요
  (Gerrit, Crucible)

GitHub는 issue와 review system(PR, pull request)을 제공한다

6. Branch

독립적으로 개발을 진행할 수 있는 공간
스냅샷 : 전체 복사. 각 commit마다 갖고 있다.

이런 구조의 스냅샷이

이렇게 포인터로 연결되어 있다.

git log시 스냅샷 역순으로 출력된다. (c->b->a)

branch 생성

git branch <branch name>

로 생성할 수 있고, git branch로 확인할 수 있다.
가장 기본 branch는 master이다.

git checkout

$ git checkout <branch name>

branch 옮겨가기 = head pointer 이동하기, 스냅샷 복사

commit은 head를 이동시킨다.

branch를 옮겨갔을 때, head를 이동시키는 것이기 때문에, 스냅샷의 위치가 다를 수도 있다. 따라서

• testing 이라는 branch를 생성하고
  
• test라는 파일을 하나 만들어, commit을 한 후,
  
• master로 head를 이동시키면,
  
• test 파일이 생성되지 않은 시점으로 돌아간다.
  
  (이거 때문에 pintos 플젝 하다가 모든 파일이 날아간줄 알고 식은땀 흘리던 기억이 떠오른다. git 안쓸래..무서워..이랬다가, 지금 공부하니 알겠다. 별거 아니였다..ㅠㅠ)
  
  그리고 이 작업에 대해 확인하고 싶다면,
  git log --oneline --decorate --graph --all로 볼 수 있다.

어떤 작업을 할 때 내가 현재 어느 branch에 있는지 꼭 확인할 것

이러식으로 우리는 이전 버전으로의 복구가 가능하다.

참고) git checkout -b

git checkout -b <branch name>

이렇게 하면, branch를 만들면서 checkout을 할 수 있다.

7. Merge

주의할 점!

• old <- new 병합을 해야지,
• new <- old 병합을 해버리면..결과물은 old가 된다...!으악

즉, old로 이동한 후 new를 병합해야한다.

이렇게 hotfix라는 branch를 하나 생성한 후, commit을 했다.
master <- hotfix로 병합하려고 할 때, 먼저 master로 이동한 후, merge를 해주어야 한다.

git checkout master
git merge hotfix

작업이 끝난 branch 지우기

git branch --merged를 통해 merge 한 브랜치 목록을 확인하고, *이 붙어있지 않은 브랜치를 삭제한다.

git branch -d hotfix

conflict

같은 파일에 대해서 충돌이 일어났을 때는 우리가 해결해야 한다.
파일을 아예 새로 만들거나, 특정 브랜치에서는 파일을 지우거나 등의 어떤 해결책을 선택하여 수행해야 한다.
어려운 것 아니니 걱정말자.

8. Github에 연결하기

Remote

remote 저장소는 인터넷이나 네트워크 어딘가에 있는 저장소이다. 이는 여러 개가 있을 수 있다.
: 어떤 서버를 특정해서 쓸 수도 있는 건가?

1. github repository를 추가하고,
2. 2-1. repo가 없다.
   1) git init
   2) git add README.md
   3) git commit -m <message>
   4) git remote add origin <git 주소> : origin이라는 이름으로 git 주소에 올린다.
   (이 origin은 자동으로 등록되어 있는 remote 저장소/ remote 브랜치)
   5) push -u origin master : master 브랜치를 업로드
   
   2-2. repo가 이미 있다.
   1) git remote add origin <git 주소>
   2) push -u origin master

참고 : git remote

• git remote : remote 저장소를 볼 수 있다.
• git remote -v : url과 함께 볼 수 있다.
• git remote add <remote 이름> <url> : remote 저장소 추가하기

Clone

단순히 다운로드하면 .git폴더가 없다. clone 주소를 가져와서 하자.
git clone <url>

이들 또한 GUI로 할 수 있다.
merge 작업은 github에서도 가능하다.
github의 issue, merge 탭을 활용해보자. 담당자(assignees)를 지정할 수 있고, 어떤 작업인지 Label을 달 수도 있다. 또한 동료들과 review를 달아 의견을 제시할 수도 있다.

Patch

현재 local repo에서 변경사항이 있는지 확인할 수 있다.
그리고 pull을 통해 업데이트할 수 있다.

참고

git alias

Github 플로우

1. 프로젝트를 Fork 한다. : 자신의 repo 생성됨
2. master 기반으로 브랜치를 만든다. : 새로운 브랜치 생성 후
3. 수정해서 커밋한다.
4. 자신의 github 프로젝트에 push한다.
5. github에 pull request를 생성한다. : 나의 repo에서 자동으로 뜬다. 자세히 설명하여 작성한다.
6. 토론하면서 계속 커밋한다.
7. 프로젝트 소유자는 pull request를 merge하고 닫는다.
   참고 블로그