git on LaMelD

1장 : 깃 시작하기

Fri, 29 Nov 2019 17:38:30 +0900

1. 깃으로 무엇을 할 수 있을까?

버전관리
- local 저장소에 관련된 내용 :: git
백업하기
- remote 저장소에 관련된 내용 :: github
협업하기
- git, github 다루기

2. 깃 설치하기

기본적인 설치
- 깃 설치 사이트에서 설치할 수 있다.
- 설치과정은 기본적으로 설정되어있는 것을 따라간다.
- 설치가 완료되면 윈도우 작업 표시줄의 검색 창에 git이라고 입력한 후 검색 결과 중에서 Git Bash를 누른다.
- git이라고 입력한 수 enter를 눌러보면 깃 명령에서 사용할 수 있는 여러 옵션이 표시된다면 설치 성공이다.
깃 환경 설정
- 사용자 설정을 위해 git config 명령을 사용합니다. 여기서 –global 옵션은 현재 컴퓨터에 있는 모든 저장소에서 같은 사용자 정보를 사용하도록 설정한다.
```
$ git config --global user.name "사용자 이름"
$ git config --global user.email 사용자@이메.일
```

3. 리눅스 명령 연습

~ : 홈 디렉토리
pwd : 현재 작업 디렉토리
ls : 디렉토리 내용 확인
cd : 디렉토리 이동
. : 현재 디렉토리
.. : 상위 디렉토리
mkdir : 디렉토리 생성
rm : 파일 제거
- rm -rf : 파일, 디렉토리를 가리지 않고 삭제(-r : recursive, -f : force)
vim : 편집기
- 기본 편집기 변경하기
- git config -- global core.editor "notepad++"
touch : 빈 파일 생성
cat : 파일 내용 확인
- cat [파일이름]
- cat [파일1], [파일2], [파일3], ... , [파일n] > [새파일] : 파일n 개를 차례로 연결해서 새로운 파일을 만든다.
- cat [파일1] >> [파일2] : 파일1의 내용을 파일2 끝에 연결한다.

2장 : 깃으로 버전 관리하기

Fri, 29 Nov 2019 17:38:30 +0900

1. 깃 저장소

깃 초기화 하기
- 디렉토리를 하나 새로 만들고 내부를 살펴본 뒤 git init을 하면 .git이라는 디렉토리가 새로 생긴다.
- .git : 깃을 사용하면 버전이 저장될 ‘저장소’
```
$ mkdir hi-git
$ cd hi-git
$ ls -al
$ git init
$ ls -al
```

2. 버전 만들기

깃에서 버전이란
- 문서를 수정하고 저장할 때마다 생기는 것
- 원래 파일 이름은 그대로 유지하면서 파일에서 무엇을 변경했는지를 변경 시점마다 저장할 수 있다.
- 각 버전마다 작업했던 내용을 확인할 수 있고, 그 버전으로 rollback할 수 있다.
스테이지와 커밋 이해하기
- 작업트리 :: workspace
  - 파일 수정, 저장 등의 작업을하는 디렉토리
- 스테이지 :: index
  - 버전으로 만들 파일이 대기하는 곳
  - 명령어
```
$ git add [파일 또는 디렉토리]
```
- 저장소 :: local repository
  - 스테이지에 대기하고 있던 파일들을 버전으로 만들어 저장하는 곳
  - 명렁어
```
$ git commit -m "커밋 메시지 입력"
```
- 순서
  1.작업트리에서 작업을 한다.
  2.작업물을 스테이지에 올린다.
  3.스테이지에 있는 모든 것을 로컬 저장소에 저장한다.
- 스테이징과 커밋 한꺼번에 처리하기
  - 한 번이라도 커밋한 적이 있는 파일을 다시 커밋할 때 사용할 수 있다.
  - git commit -am "커밋 메시지"
- 현재 깃 상태 확인 :: git status
- 깃의 로그 확인 :: git log
  - 여러가지 옵션을 줄 수 있다.
  - 대표적인 옵션 :: –oneline, –branches, –graph
- 변경 사항 확인하기 :: git diff
  - 작업 디렉토리와 저장소의 차이를 볼 수 있다.
버전 만드는 단계마다 파일 상태 알아보기
- tracked 파일과 untracked 파일
  - untracked 파일 :: 한번도 깃에서 버전 관리를 하지 않았기 때문에 수정 내역을 추적하지 않음.
  - tracked 파일 :: untracked 파일이 아닌 파일
- unmodified, modified, staged 상태
  - tracked 파일의 상태 확인
  - unmodified : 커밋된 이후 수정되지 않은 상태
  - modified : 커밋된 이후 수정된 상태
  - staged : modified 상태에서 git add [파일 또는 폴더]를 실시하여 스테이지에 올려놓은 상태(커밋 직전의 상태)
  - 커밋을 실시하면 unmodified 상태로 돌아간다.
.gitignore 파일로 버전 관리에서 제외하기!
- 버전 관리 중인 디렉토리 안에 버전관리를 하지 않을 특정 파일 또는 디렉토리가 있다면 .gitignore 파일을 만들어 목록을 지정할 수 있다.
- 예시
```
$ cat .gitignore
mynote.txt # 파일을 ignore
temp/ # 폴더를 ignore
.swp # 확장자를 ignore
```
작업 되돌리기(Rollback)
- 작업트리에서 수정한 파일 되돌리기 :: git checkout -- [수정한 파일]
  - checkout으로 되돌린 내용은 다시 복구할 수 없습니다.
- 스테이징 되돌리기 :: git reset HEAD [파일이름]
  - 수정된 파일을 스테이징 했을 때, 스테이징을 취소한는 방법
- 최신 커밋 되돌리기 :: git reset HEAD^
  - 가장 마지막에 한 커밋을 취소하는 방법
  - git reset 명령의 옵션
    - git reset --soft HEAD^ : 최근 커밋을 하기 전 상태로 작업 트리를 되돌립니다.
    - git reset --mixed HEAD^ : 최근 커밋과 스테이징을 하기 전 상태로 작업 트리를 되돌린다. 기본값
    - git reset --hard HEAD^ : 최근 커밋과 스테이징, 파일 수정을 하기 전 상태로 작업 트리를 되돌린다. 되돌린 내용은 복구 불가능
    - HEAD^ 부분에 커밋해시를 넣어주면 특정 커밋 상태로 되돌아갈 수 있습니다.
  - 특정 커밋으로 되돌아간다면 그 이후의 버전을 삭제할 수 있다.
- 버전 삭제하지 않고 되돌리기 :: git revert [커밋 해쉬를 넣는다]
  - 나중에 사용할 것을 대비해서 커밋을 되돌리더라도 취소한 커밋을 남겨두어야 할 때가 있다.
  - 이때는 git reset이 아닌 git revert를 사용한다.

3장 : 깃과 브랜치

Fri, 29 Nov 2019 17:38:30 +0900

1. 브랜치(branch)

분기점
- master에서 commit한다.
- 현 상태에서 Feature-1 브랜치를 만들어 새로운 내용을 추가하여 commit한다.
- master에서 새로운 내용을 넣어 commit한다.
- 현 상태에서 Feature-2 브랜치를 만들어 새로운 내용을 추가하여 commit 한다.
- Feature-1과 master를 merge(병합)한다.
- Feature-2와 master를 merge(병합)한다.

2. 브랜치 만들기

실습 환경 설정하기
```
$ mkdir branchtest
$ cd branchtest
$ git init
$ vim work.txt
$ git add work.txt
$ git commit -m "work 1"
```
- 새로운 저장소를 만든다.
- 새로운 파일을 만들고 commit까지 실시한다.
새 브랜치 만들기
- 브랜치 확인 :: git branch
- 브랜치 생성 :: git branch [브랜치 이름]
```
$ git branch
$ git branch apple
$ git branch ms
$ git branch google
```
브랜치 이동하기 :: git checkout [브랜치 이름]
- master에서 work.txt를 수정하고 커밋한다.
- git log --oneline으로 로그를 보면 master와 다른 브랜치의 상태가 다른 것을 확인 할 수 있다.
- apple 브랜치로 이동하여 git log --oneline으로 로그를 보면 HEAD가 apple를 가리키고 있는 것을 볼 수 있다.
- work.txt를 cat으로 확인해보면 master에서 수정한 내용이 반영되지 않았음을 확인할 수 있다.

3. 브랜치 정보 확인하기

apple에서 work.txt를 수정하고 커밋한다.
git log --oneline --branches --graph를 한다면 분기되었음을 그래프로 확인할 수 있다.
git log master..apple : master 브랜치를 기준으로 apple과 비교하여 차이점을 알 수 있다.
git log apple..master : apple 브랜치를 기준으로 master와 비교하여 차이점을 알 수 있다.

4. 브랜치 병합하기

서로 다른 파일 병합
- 새로운 저장소를 만든다.
- work.txt 파일을 만들어 ‘1’을 입력하고 저장
- add 해주고 commit을 실행하는데 메시지를 “work 1"으로 한다.
- b1 브랜치를 생성해준다.
- master 브랜치에서 master.txt 파일을 만들어 ‘master 2’를 입력하고 저장
- “master work 2"라는 메시지와 함께 커밋
- b1 브랜치로 이동하여 b1.txt 파일을 만들어 ‘b1 2’를 입력하고 저장
- “b1 work 2"라는 메시지와 함께 커밋
- git log --oneline --branches --graph로 현재 상태를 확인한다.
- master 브랜치로 이동하여 git merge b1을 입력하여 병합한다. :: master 브랜치를 b1과 병합한 결과를 master 브랜치에 적용한다.
```
$ mkdir man1
$ cd man1
$ git init
$ vim work.txt
$ git add work.txt
$ git commit -m "work 1"
$ git branch b1
$ vim master.txt
$ git add master.txt
$ git commit -m "master work 2"
$ git checkout b1
$ vim b1.txt
$ git add b1.txt
$ git commit -m "b1 work 2"
$ git log --oneline --branches --graph
$ git checkout master
$ git merge b1
$ ls -al
```
같은 파일 다른 위치 수정후 병합
- 새로운 저장소를 만든다.
- work.txt 파일을 만들어 아래와 같이 입력하고 저장
```
#title
content


#title
content
```
- add 해주고 commit을 실행하는데 메시지를 “work 1"으로 한다.
- b1 브랜치를 생성해준다.
- master 브랜치에서 work.txt 파일을 아래와 같이 수정하여 “master work 2” 메시지로 커밋한다.
```
#title
master content 2


#title
content
```
- b1 브랜치로 이동하여 work.txt 파일을 아래와 같이 수정하여 “b1 work 2” 메시지로 커밋한다.
```
#title
content


#title
b1 content 2
```
- master 브랜치로 이동하여 merge를 실시한 뒤 work.txt를 cat으로 확인하면 자연스럽게 합쳐진 모습을 볼 수 있다.
```
$ git init man2
$ cd man2
$ vim work.txt
$ git add work.txt
$ git commit -m "work 1"
$ git branch b1
$ vim work.txt
$ git commit -am "master work 2"
$ git checkout b1
$ vim work.txt
$ git commit -am "b1 work 2"
$ git checkout master
$ git merge b1
$ cat work.txt
```
같은 파일 같은 위치 수정후 병합
- 깃에서는 줄 단위로 변경여부를 확인한다.
- 같은 줄을 수정했을 때 브랜치를 병합하면 브랜치 충돌이 발생
- 새로운 저장소를 만든다.
- work.txt 파일을 만들어 아래와 같이 입력하고 저장
```
#title
content

#title
content
```
- add 해주고 commit을 실행하는데 메시지를 “work 1"으로 한다.
- b1 브랜치를 생성해준다.
- master 브랜치에서 work.txt 파일을 아래와 같이 수정하여 “master work 2” 메시지로 커밋한다.
```
#title
content
master content 2
#title
content
```
- b1 브랜치로 이동하여 work.txt 파일을 아래와 같이 수정하여 “b1 work 2” 메시지로 커밋한다.
```
#title
content
b1 content 2
#title
content
```
- master 브랜치로 이동하여 merge를 실시하면 CONFLICT 메시지가 출려된다.
- 편집기로 work.txt를 열어서 필요없는 내용 <<<<HEAD, >>>>b1, =====을 삭제한 뒤 저장하고 편집기를 종료한다.
- 수정한 work.txt를 스테이지에 올리고 커밋하면 충돌을 해결하고 커밋한 것이다.
- git log --oneline --branches --graph로 지금까지 만든 브랜치와 커밋의 관계를 한눈에 확인할 수 있다.
```
$ git init man2
$ cd man2
$ vim work.txt
$ git add work.txt
$ git commit -m "work 1"
$ git branch b1
$ vim work.txt
$ git commit -am "master work 2"
$ git checkout b1
$ vim work.txt
$ git commit -am "b1 work 2"
$ git checkout master
$ git merge b1
$ vim work.txt
$ git commit -am "merge b1 branch"
$ git log --oneline --branches --graph
```
브랜치를 병합할 때 편집기
- 편집기 열리게 하기 : git merge b1 --edit
- 편집기 열리지 않게 하기 : git merge b1 --no-edit
병합 및 충돌 해결 프로그램

프로그램	설명
P4Merge	무료이고 직관적이며 사용이 편리하고 병합 기능이 뛰어남. 단축키가 지원되지 않는 단점이 있다.
Meld	무료이며 오픈소스. 파일을 비교하는 것뿐만 아니라 직접 편집할 수 있다.
Kdiff3	무료이고 사용이 편리하고 병합 기능이 뛰어나지만 한글이 깨져보일 수 있다.
Araxis Merge	유료지만 용량이 큰 파일에서도 잘 동작함

병합이 끝난 브랜치 삭제
- git branch로 남은 브랜치 확인
- 저장소의 기본 브랜치는 master 브랜치이므로 master 브랜치로 이동하여 브랜치를 삭제하는 것이 안전하다.
- b1 브랜치의 삭제
  - git branch -d b1
  - git branch --delete b1
  - git branch -D b1

5. 브랜치 관리하기

커밋 해시를 통해서 브랜치들을 관리하고 커밋 해시(버전)으로 rollback 할 수 있다.
수정 중인 파일 감추기 및 되돌리기 :: git stash
- 아직 커밋하지 않고 작업 중인 파일들을 잠시 감춰둘 수 있다.
- stash 명령을 사용하기 위해선 파일이 tracked 상태여야 한다.(한 번은 커밋한 상태여야 한다)
- 새로운 저장소를 만들고 f1.txt, f2.txt를 생성하고 커밋한다.
- f1.txt와 f2.txt를 수정하고 저장만 한 뒤 git status로 상태를 확인한다.
- 각각의 파일이 modified 상태인 것을 확인 할 수있다.
- git stash를 실시하고 다시 git status를 해보면 modified 메시지가 사라진 것을 확인 할 수 있다.
- 같은 방법으로 여러 파일을 수정한 후 따로 보관할 수 있다.
- stash가 보관되는 공간은 stack으로 이루어져 LIFO이 적용된다.
  - 가장 최근에 보관한 stash는 stash@{0}에 담기게 된다.
- 감추어둔 파일을 꺼내와 계속 수정하거나 커밋할 수 있다.
- 이때 가장 최근 항목을 되돌리기 위해서 git stash pop을 사용한다.
```
$ git init st
$ cd st
$ vim f1.txt
$ vim f2.txt
$ git add .
$ git commit -m "add f1, f2"
$ vim f1.txt
$ vim f2.txt
$ git stash
$ git stash pop
```
stash 관련 명령어
- git stash : stash 스택에 modified 상태의 작업물을 담는다.
- git stash pop : 가장 최근의 항목을 되돌리고 stash 스택에서 제거한다.
- git stash list : stash 스택의 목록을 확인한다.
- git stash apply : 가장 최근의 항목을 되돌리고 stash 스택에 남겨둔다.
- git stash drop : 가장 최근의 항목을 삭제한다.

4장 : 깃허브로 백업하기

Fri, 29 Nov 2019 17:38:30 +0900

1. 원격 저장소와 깃허브

원격 저장소
- 지역 저장소가 아닌 컴퓨터나 서버에 만든 저장소를 말한다.
- 지역 저장소와 연결되어 있으면서 ‘백업’과 ‘협업’이라는 중요한 역할을 한다.
깃허브로 할 수 있는 일
- 원격 저장소에서 깃을 사용할 수 있다.
- 지역 저장소를 백업할 수 있다.
- 헙업 프로젝트에 사용할 수 있다.
- 자신의 개발 이력을 남길 수 있다.
- 다른 사람의 소스를 살펴볼 수 있고, 오픈 소스에 참여할 수 있다.

2. 깃허브 시작하기

깃허브에 접속한 뒤 계정을 생성한다.
무료 계정과 유료 계정의 차이 : 협업할 수 있는 계정의 수가 제한되어 있다.
깃허브에 원격 저장소 만들기
- repository를 새로 만들어 원격 저장소를 추가할 수 있다.
- Add a License : 오픈 소스 프로젝트를 위한 저장소를 만들 경우 해당 오픈 소스의 라이센스를 선택한다.

3. 지역 저장소를 원격 저장소와 연결하기

지역 저장소를 만든다.
- git init [지역 저장소 이름]
지역 저장소와 원격 저장소를 연결한다.
- git remote add [원격 저장소 이름] [원격 저장소 URL]
- 원격 저장소 이름 : 사용자 지정
- github에서 지정되어 있는 URL :: clone or download를 눌렀을 때 나오는 URL
지역 저장소와 원격 저장소의 연결 확인
- git remote -v

4. 원격 저장소에 올리기 및 내려받기

원격 저장소에 파일 올리기 :: git push
- git push origin master
  - push : 원격 저장소에 올리겠다.
  - origin : 원격 저장소의 이름
  - master : 원격 저장소에 올릴 브랜치
원격 저장소에서 파일 받기 :: git pull
- git pull origin master
  - pull : 원격 저장소에서 받아오겠다.
  - origin : 원격 저장소의 이름
  - master : 원격 저장소에 받아올 브랜치이름, 지역 저장소의 브랜치 이름

5. 깃 허브에 SSH 원격 접속하기

생략하도록 하겠다…
필요시 업데이트 하겠다…

5장 : 깃허브로 협업하기

Fri, 29 Nov 2019 17:38:30 +0900

1. 여러 컴퓨터에서 원격 저장소 함께 사용하기

원격 저장소 복제하기 :: git clone
- git clone [복사할 원격 저장소의 URL]
- 위와 같이 사용하여 원격 저장소에서 복제할 수 있다.(복제한다 == 클론 == 클로닝)
- git clone [복제할 저장소의 URL] [복제할 디렉토리]
- 복제할 디렉토리가 없으면 새로 생성해준다.
- 복제할 디렉토리를 넣지 않으면 원격 저장소의 이름과 동일하게 복제된다.
실습을 위한 두 환경 준비
- 두 환경을 만들어 각각 회사와 집이라고 생각하자.
- git_home
  - git clone [URL] git_home
- git_office
  - git clone [URL] git_office

개인 컴퓨터에서 작업하고 올리기

$ cd git_home
$ vim f1.txt
$ git commit -m "add c"
$ git push origin master

회사 컴퓨터에서 내려받아 작업하기

$ cd ~/git_office
$ git pull origin master
$ vim f1.txt
$ git commit -am "add d"
$ git push origin master

작업을 함에 있어서 항상 git pull을 통해서 원격 저장소에 새로 올라온 커밋을 가져와야한다.

2. 원격 브랜치 정보 가져오기

git pull
- 명령은 원격 저장소의 최신 커밋을 지역 저장소에 합쳐준다. 하지만 최신 커밋을 합치기 전에 원격 저장소에 어떤 변화가 있는지 먼저 살펴보아야 한다.

원격 브랜치 정보 가져오기 :: git fetch

fetch(패치) : 불러오다, 가져오다
git fetch : 어떤 변화가 있는지 원격 저장소의 정보를 가져온다.

$ cd ~/git_office
 # 원격 저장소에서 변경을 실시한다.
$ git fetch
$ git log --oneline 
 # 변화된 부분이 없다...
$ git status
 # git pull 명령을 사용하면 지역 저장소를 업데이트 할 수 있다고 한다.
$ git checkout FETCH_HEAD
 # 이제 변화된 부분을 확인할 수 있다.
$ git checkout master
$ git merge FETCH_HEAD
$ git log --oneline
 # 커밋 로그를 확인해보면 적용되어 있다.

3. 협업의 기본 알아보기

공동 작업자 추가하기(팀장)
- 누구나 프로젝트의 소스를 내려받을 수 있지만 커밋을 푸시할 순 없다.
- 공동 작업자가 커밋을 푸시할 수 있도록 권하는 주는 것이다.

작업 환경 구성하기(팀장, 팀원)

$ git init project
$ cd project
 # --global 옵션을 제거하여 현재 저장소에만 적용될 config입니다.
$ git config user.name "사용자 이름"
$ git config user.email 사용자@이메.일

원격 저장소에 첫 커밋 푸시하기(팀장)

$ vim overview.txt
$ git add overview.txt
$ git commit -m "overview"

새로운 깃허브 저장소를 만든다.

$ git remote add origin [저장소 URL]
$ git push origin master

공동 작업자 컴퓨터에서 원격 저장소 복제하기

$ git clone [저장소 URL]
 # 사용자 이름과 이메일을 설정한다.

첫 번재 커밋(팀장이 실시한)이 아니라면 풀 먼저하기
- 팀원이 작업트리에서 작업을 수행함에 있어서 팀장이 그 중에 푸시를 실시할 수 있다.
- 팀원이 작업을 완료하고 푸시하려고 할 때 팀장의 새로운 커밋이 푸시되었으므로 rejected라는 오류 메시지가 나온다.
- 이를 방지하기위해서 푸하기전에 항상 풀을 먼저 실시해야 한다.
- 같은 파일을 수정했을 경우 풀 과정에서 merge 에러가 발생할 수 있다.
- 이럴경우 수동으로 이를 해결해주어야 한다… 귀찮다…

4. 협업에서 브랜치 사용하기

협업을 하다 보면 팀원들이 각자 기능을 맡아서 작업하는 경우가 많다.
이럴 때는 각자의 작업이 master 브랜치에 있는 문서들과 섞이지 않도록 새 브랜치를 만들어서 버전을 관리한다.
각 팀원이 만든 새 브랜치 역시 원격 저장소에 그대로 푸시할 수 있다.

새로 만든 브랜치 푸시하기

$ git pull origin master
 # checkout 명령에 -b 옵션을 붙여 브랜치를 새로 만들고 이동까지 한번에
 # f 브랜치가 있다면 브랜치로 이동
$ git checkout -b f
$ vim f1.txt
$ git add f1.txt
$ git add f1.txt
$ git commit -m "feature1"
$ git push origin f

웹 브라우저로 원격 저장소로 접속하면 브랜치가 생성되어 있다.

풀 리퀘스트로 푸시한 브랜치 병합하기
1. 브랜치 설명 옆에 있는 New pull request를 누른다.
2. 풀 리퀘스트 메시지를 작성한 후 Create pull request를 누르면 협업 중인 저장소에 풀 리퀘스트가 전송된다.
3. 협업 중인 원격 저장소에 등록된 풀 리퀘스트는 공동 작업자 중 누구나 살펴보고 병합할 수 있다. 저장소 파일 위의 Pull request를 누르면 등록된 풀 리퀘스트 목록이 나타난다. 등록된 풀 리퀘스트를 누른다.
4. 풀 리퀘스트 메시지를 살펴본 다음 내용에 문제가 없으면 Merge pull request를 눌러 병합을 한다. 필요하다면 이 공간을 통해 풀 리퀘스트를 남간 사람과 메시지를 주고받을 수 있다.
5. 커밋 메시지를 직접 입력하거나 기본 메시지를 사용할 수도 있다. Confirm merge를 누르면 브랜치 병합이 끝난다.
6. 브랜치가 병합되면 해당 브랜치에 있던 파일이 master 화면에 나타날 것이다. 브랜치 상태를 알고 싶다면 파일 목록 위에 있는 2 branches를 눌러 보시오.
7. 브랜치가 병합된 상태라면 merged라고 표시되어 있다. 그리고 공동 작업자 중 누가 브랜치를 병합했는지도 알 수 있다.
8. 깃허브에서 협업할 때는 보통 작업자마다 브랜치를 만들어서 진행하고, 작업 중간 중간 풀 리퀘스트를 보내서 master 브랜치에 병합한다. 그래서 깃허브로 협업할 때는 다른 작업자의 변경 내용을 바로 반영하기 위해서 항상 풀부터 한 다음 자신의 작업을 진행하는 것이 좋다.