GIT
GIT을 사용하는 이유
1. GIT의 특징
1.가지치기와 병합 ->여러가지 수정본을 만들고 그걸 병합할 수 있음. 각 작업자들이 버전 히스토리를 가질 수 있다. 2.가볍고 빠름 ->git은 로컬에서 사용자가 작업한 후, 타인에게 코드를 공유할 때만 네트워크 필요. 3.분산작업 -> 각 개발자가 중앙 집중된 서버저장소와 독립된 상태로 작업할 수 있음. 4.데이터 보장 ->commit한 사람의 ID을 알 수 있음 5.준비 영역(Staging area) 6.오픈 소스. git 저장소가 시작되지 않은 상태에서는 유저 설정 시에 반드시 --global을 입력해야한다.
2. GIT 명령어들
git init: 현재 디렉토리를 repository로 설정. 꼭 디렉토리를 제대로 설정해야 한다.
git config --global user.name "<이름>": git과 관련된 작업에 남는 이름 수정
git config --global user.email "<이름>": git과 관련된 작업에 남는 이메일 수정
git config --list : git 설정 확인(이름,이메일 등을 확인할 수 있다)
Animal폴더 아래에 Raccoon폴더가 있고 그 아래에 Doguri와 Rocket 폴더가 있다. 현재 Animal 폴더에 있고 Doguri 폴더에 저장소를 생성하고 싶다면 git init ./Raccoon/Doguri OR cd Raccoon/Doguri명령어를 사용하면 된다.
현재 실습 코드를 올리고 있는 Elice 폴더의 경로창에 cmd를 입력해 git init을 적용하니 
이미 깃을 사용했던 폴더라 reinitialized가 뜬다.
.git 폴더가 생성된 걸 확인할 수 있다.
그리고 Doguri 폴더에서 오른쪽 마우스를 클릭해 Git Bash를 실행하고 ls -a 명령어를 입력하면 숨김처리된 파일이나 디렉토리도 확인할 수 있다.
git init시에 폴더의 경로를 위처럼 입력하면 편하지만 적용이 안 되어서 귀찮더라도 cd로 경로를 옮긴 후에 사용하는 게 좋을 것 같다.
3. GIT 파일 생성하기
파일 업로드시의 루틴!
작업영역에서 git add를 사용해 스테이지 영역에 올리고, git commit으로 레포지토리에 올린다.
작업영역에 있던 파일은 untracked&unmodified상태였다가, 수정이 되면 modified, git add를 사용하면 스테이징된 상태(staged)가 된다. 이때 스테이징된 파일을 git commit으로 레포지토리에 올리면 파일은 다시 unmodified 상태가 된다.
git add file.py secondfile.html : 파일을 스테이징 영역에 올린다. 두 개 이상 올리고 싶으면 파일명 사이에 띄어쓰기를 해주면 된다. 파일명 꼭 입력하기!
git commit: 파일을 저장소(repository)에 올린다.
git commit -m "커밋시 올릴 메시지입력부분": 옵션m을 이용해 커밋시 올릴 메시지를 입력한다.
git commit --amend -m "바로 수정할 수 있음": 메시지에 오타가 있거나 누락된 파일이 있는 경우 수정할 수 있다.
git status: staging 영역의 어떤 파일이 변경되었는지 등의 파일 상태를 확인할 수 있다.
add된 파일은 Changes to be committed로 들어가고, 추가되지 않은 파일은 Untracked file로 들어간다.
git log:저장소에 존재하는 history를 확인할 수 있다. Date 아래에 있는 메세지는 커밋 메시지다.
git log -p -2 -p(diff와 같은 역할) , -숫자(상위 n개의 commit만 보여준다)
git diff: commit된 파일 중에서 변경된 사항을 비교한다.
git log --start: 어떤 파일이 commit에서 수정되고 변경되었는지, 파일내의 코드가 추가되거나 삭제되었는지 확인할 수 있다.
git log --pretty=oneline:각 커밋을 한 줄로 출력
git log --graph: commit간의 연결된 관계를 아스키 그래프로 출력
git log -S 찾고 싶은 텍스트: 코드 내에 추가되거나 제거된 내용 중 특정 텍스트가 포함되어있는지 검사
git reset: 스테이징된 파일을 초기화한다.
Git Branch
branch? brunch 아니고?
4. Git Branch
독립적으로 작업을 진행하기 위한 개념, 각각의 브랜치는 다른 브랜치의 영향을 받지 않음 master 브랜치에서 개발 목적의 develop 브랜치를 만들고, develop 브랜치에서 개발을 완료해 배포를 하려고 할 때는 다시 master 브랜치와 병합하면 된다. develop 브랜치에서도 기능,작업별로 브랜치를 만들 수 있다. 병합하기 이전까지 각각의 브랜치는 서로의 영향을 받지 않는다.HEAD는 현재 브랜치, master 브랜치는 repository 생성시 자동으로 생성되는 브랜치다.
git branch branch_name: branch_name이라는 이름의 브랜치 생성 git branch: 현재 존재하는 브랜치 확인 git checkout new_branch: new_branch로 전환. git checkout : git log로 확인한 snapshot 버전도 변경할 수 있다.
5. Git 병합하기
c2분기점에 master와 develop브랜치가 있다. master 브랜치에서 develop 브랜치에 새로운 내용(a.html,a.css)을 추가해 commit했다. 이 경우, master 브랜치의 분기점은 c2이고 새로운 내용을 커밋한 develop 브랜치는 c3이다. develop에서 모든 개발 작업이 완료되어 master로 통합하려고 한다.
git checkout master
git merge develop위의 코드를 실행하면 c2분기점에 있던 master 브랜치가 c3 분기점으로 이동하며 master 브랜치가 HEAD가 되고, develop 브랜치가 master 브랜치에 병합된다. 즉, master의 내용과 develop의 내용이 같다는 것이다.
develop 브랜치의 내용이 master 브랜치에서 업데이트된 내용이기 때문에, 곧바로 병합되는 것을 확인할 수 있는데 이것을 fast-forward라고 한다. 쉽게 말하면, master에서 변경된 것 없이 a.html과 a.css만 추가된 것이 fast-forward인 것이다! fast-forward로 병합된 경우에는 git merge 브랜치 이름에서 Fast-forward라고 적힌 것을 확인할 수 있다.
앞서 Git Branch에서 각각의 브랜치는 다른 브랜치의 영향을 받지 않기 때문에 여러 작업을 동시에 진행할 수 있다고 했다. 예를 들어, c2 분기점에 있던 master와 develop 브랜치의 작업영역에서 다른 파일을 수정할 경우에 develop은 c3분기점으로, master는 c4분기점으로 갈라지게 된다.
git log --graph --all을 사용해 commit graph를 확인할 수 있다. 아까 fast-forward에서 했던 것 과 같이 master브랜치로 checkout한 후, git merge develop을 하면 위의 예시와는 달리, "Merge made by the 'recursive' strategy 라는 문구가 나온다. 이것은 c3에 있던 develop과 c4에 있던 master가 합쳐져 master가 c5로 이동하며 새로운 분기점이 생성되었음을 의미한다. 하지만 develop은 c3, master는 c5로 fast-forward와 달리 다른 분기점에 있다. git branch --merged 를 통해 병합된 branch를 볼 수 있다. 이 경우에는 develop *master 가 표시될 것이다.
사용을 마친 브랜치는 git branch -d 브랜치이름으로 삭제한다.
6. Merge Conflict
병합한 두 브랜치에서 같은 파일을 변경했을 때, merge conflict가 발생한다.
git merge develop
Auto-merging hello.py
Merge conflict in hello.py
Automatic merge failed