장점
1. 가지 치기와 병합
여러가지 작업을 독집적으로 작업 할 수 있다.
2. 가볍고 빠르다.
서버와의 통식없이 로컬에서 진행된다.
다른 사람과 코드를 공유 할 때만 중앙 서비스에 접속하면 되므로 네트워크 속도와 관계없이 작업을 빠르게 진행 할 수 있다.
3. 분산 작업
분산 작업에 효율적 이다.
사용자들은 전체 코드를 다 가지고 있고 통합 관리자의 역할을 분담한다.
이 통합 관리자들은 개발된 코드를 병합하는데 집중한다.
4. 데이터 보장(무결성 보장)
모든 파일은 checksum이라는 검사 과정을 거치면서 버전 관리가 매우 수월해 진다.
5. 준비 영역
수정한 내용을 반영하기 전 검토하는 단계가 있다.
6. 오픈소스
누구나 볼 수 있게 공개되어 있다.
7. git호스팅 서비스
GitHub, Atlassian Bitbucket, GitLab
설정
버전 확인
git --version
이름 생성
git config --global user.name "F*****n"
프로젝트 별로 다르게 하고 싶다면
git config user.name "F*****n"
이메일 생성
git config --global user.email "s********@gmail.com"
프로젝트 별로 다르게 하고 싶다면
git config user.email "s*******@gmail.com"
저장소 생성
git init
리스트 확인
git config --list
원격 저장소 추가
git remote add origin <https://gitlab.com/group/project>
연결된 원격 저장소 확인
git remote git remote -v // 지정한 저장소의 이름과 주소를 함께 볼 수 있다.
한눈에 다 살펴보기
git remote show origin
원격 저장소 이름 변경
git remote rename origin git_test원격 저장소의 단축 이름을 origin으로 지정한다는 의미이다.
다른 이름으로 지정해도 된다.
하지만 default값이 origin이다. 그래서 clone으로 복사해온 저장소의 이름은 origin이다.
원격 저장소 삭제
git remote rm git_test
원격 저장소에서 원격파일 url로 받아오기
git clone <https://gitlab.com/group/project>
git Repository File을 로컬로 내려 받는 방법
git clone -b (브랜치이름) --single-branch (저장소 URL)
이 방법을 사용하는 이유
원격 저장소에서 원격파일을 url로 받아오려고 clone 하였으나 merge를 하지 않아서 그런지 빈 파일만 다운로드가 되었다. 그래서 특정 브랜치만 clone 하였다.
소스 기록, 커밋, 업데이트, 복원
파일 영역의 LifeCycle
준비 영역(Staging area)에 파일 추가
git add main.js
모든 파일 추가
git add .
Staging 상태 확인 (파일의 상태 확인)
git status
커밋(commit)
git 저장소 내에 Staging 파일 저장
git commit git commit -m "Initial commit" // 반영한 내역을 추후에 쉽게 알수 있도록 메세지를 넣음
git commit -- amend // 메세지에 오타가 있거나 누락된 파일이 있을때 수정
저장소 반영 내역
git log git log -p -2 // -p,--patch : diff와 같은 역할, -2(n) : 상위 2(n)개의 commit만 보여준다.
git log --stat // 어떤 파일이 commit에서 수정되고 변경되었는지 확인 git log --pretty=oneline // 각 commit을 한 줄로 출력
git log -- graph // commit간의 연결된 관계를 아스키 그래프로 출력한다. branch와 효율좋다.
git log -S function_name //-S는 코드에서 추가되거나 제거된 내용 중 특정 텍스트(function name)가 포함되어 있는지 검사
commit된 파일 중 변경된 사항을 비교
git diff
준비 영역(staging area)에서 삭제
git reset README.txt
업데이트(update)
다른 사람이 커밋한 파일은 직접 업데이트를 해야 동기화가 된다.
master 브랜치를 pull하여 업데이트
git pull origin master원격 저장소에있는 변경사항들을 로컬저장소로 가져와서 병합한다.
pull은 merge 까지 한다. 즉 fetch + merge 이다.
master 브랜치를 fetch하여 업데이트
git fetch origin master // master로 불러옴
원격 저장소에 있는 변경사항들을 로컬저장소로 가져오기 전에 변경내용을 확인할때 사용한다.
즉, 원격 저장소에 변경사항이 있는지만 확인하고 변경된 데이터를 로컬저장소에 실제로 가져오지 않는다.
복원(reset)
실수로 잘못된 작업을 올리거나 예전 버전으로 롤백된 경우 예전 버전으로 리셋할수 있다.
git add한 main.js를 스테이지에서 내리기
git reset HEAD main.js
git commit한 상태에서 가장 마지막에 한 커밋 취소하기
git commit -am "Second_Commit" // 스태이징, 커밋 git reset HEAD^ // 커밋 취소
git reset --soft HEAD^ // 최신 커밋을 하기 전 상태로 되돌린다.
git reset --mixed HEAD^ // 최신 커밋과 스테이징 하기 전 상태로 되돌린다. (default)
git reset --hard HEAD^ // 최신 커밋과 스테이징 파일 수정 하기 전 상태로 되돌린다. (복구 불가)
브랜치(branch)
가지(branch)라는 뜻으로 가지를 펼치듯이 하나의 뿌리에서 여러 갈래로 쪼개어 관리할수 있다.
독립적으로 어떤 작업을 진행하기 위한 개념이다.
각각의 branch는 다른 branch의 영향을 받지 않는다.
메인 branch : 배포할 수 있는 수준의 안정적인 branch
토픽 branch : 기능 추가나 버그 수정과 같은 단위 작업을 위한 branch
Git branch 생성
git branch Front_Son // 브랜치 이름
현재의 branch 확인
git branch
처음 branch를 만들고 확인하면 master에 위치해 있다.
master에서 생성된 브런치(Front_Son)으로 이동해야 할 경우
branch 전환
git checkout Front_Son // Front_Son 로 브랜치 변경
branch 생성과 이동을 동시에 하기
git checkout -b Front_Son
생성한 Front_Son 브랜치는 현재 로컬에 저장되어 있으므로 생성한 브랜치를 원격 저장소에 등록해야 한다.
branch 원격 저장소 등록
git push origin Front_Son
branch 삭제
git branch -d Front_Son
병합(merge)
병합을 하려면 우선 master 브런치로 이동을 해야한다.
git checkout master
그 다음 merge를 한다.
merge
git merge Front_Son
충돌(conflict)
브랜치를 병합(merge)할때 동일한 파일을 수정한 경우 충돌(conflict)가 발생한다.
해결방법
1. 병합(merge) 취소
이전 상태로 돌아간다.
git merge --abort
2. 충돌난 부분 수정
- 충돌이 발생하면 git status로 어떤 부분에서 충돌이 발생하였는지 파일이름을 보여준다.
- 충돌이 일어난 파일을 열어본다.
- <<<< HEAD 부터 ====== 까지 충돌이 발생한 지점을 볼 수 있다. 이부분은 master 브랜치가 가리키던 최신 커밋 파일이다.
- =====부터 >>>> Front_Son 까지 가 Front_Son 브랜치가 가리키던 최신 커밋 파일이다.
- master 브랜치의 파일 내용을 선택 or Front_Son 브랜치 파일 내용 선택 or 새로운 내용입력
- 수정된 파일을 저장한다.
- git add main.js
- git commit -m "fixed_file"
여러개의 파일이 충돌이 난 경우에도 충돌이난 파일 전부다 들어가서 수정해서 다시 커밋하면 된다.
