일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- relative path
- html video
- hyperledger transaction
- html5 new tag
- #android activity
- html multimedia
- #CallByAddress
- html object
- #다차원포인터
- html code
- docker example
- #bubbleSort
- #C++ 연산자함수오버로딩
- #1차원배열
- html youtube
- #binary
- git flow
- html charset
- #3차원배열
- html id
- 토큰경제
- #자바상속#자바이즈어#is~a
- #C++ has~a
- html plug-in
- #성적관리프로그램
- border-box
- #JAVASCRIPT
- mac terminal command
- #2차원배열
- 하이퍼레저패브릭
- Today
- Total
A sentimental robot
Git Basic - Step.1 본문
Git 은 프로그램 등의 소스 코드 관리를 위한 분산 버전 관리 시스템이다.
git 상태 (local repo기준)
-
tracked : git이 추적하고 있는 상태
-
modified : 수정한 파일을 아직 로컬 저장소에 커밋하지 않은 상태 /working dir
-
staged : 현재 수정한 파일을 곧 커밋할 것이라고 표시한 상태 / index
-
committed : 데이터가 로컬 저장소에 저장된 상태 / head
git의 흐름 (cli 기준)
-
git init 기존 디렉토리를 git 저장소로 만들기
-
(or) git clone 기존 원격 저장소 복사, 프로젝트 히스토리를 전부 받아온다.
-
working directory에서 작업한 내용을 스테이지에 올린다. git add : modified 상태에서 staged 상태가 된다. [working dir 에서 index(staging area)]
git add는 파일을 새로 추적할 때도 사용하고 수정한 파일을 Staged 상태로 만들 때도 사용합니다.
-
staging area 에 올라간 작업 내용을 local repository에 커밋 git commit : staged 상태에서 committed 상태가 된다. [index 에서 head]
-
local repo에 커밋된 작업 내용을 원격 저장소에 푸쉬 git push
-
remote repo에 업데이트된 내역을 local repo에 업데이트 git fetch
-
local repo(.git directory)에 업데이트된 내역을 merge
-
working directory로 checkout 한 후 작업
git 명령어
commit(변경사항;이력;snapshot) : 작업한 내용을 로컬 저장소에 저장,소스 코드의 수정 내용은 commit 단위로 관리
commit --amend : 가장 최근에 작성했던 커밋을 수정한다. 너무 일찍 커밋을 했거나 저장해야할 파일을 빼먹었을 때, 커밋 메시지를 수정해야 할 때 쓰인다. 이전 커밋을 수정하고 싶다면 파일 수정 후 staging area에 추가한 다음 --amend 옵션을 사용하여 이전 커밋을 재작성한다. 이렇게 수정된 커밋은 새로운 커밋이 된다. 수정된 이전 커밋은 히스토리에 남지 않게 된다.
head : 현재 작업 중인 branch를 가리키는 포인터
branch : 가지 또는 분기점을 의미, 새로운 이슈를 처리하기 위하여 현재 상태(주로 마스터 브랜치)를 복사하여 작업을 진행, 독립된 작업 공간 확보
fetch : 원격 저장소에 새로 올라간 내역을 로컬 저장소에 배포,갱신(version update)
merge : 다른 branch의 내용을 현재 branch로 가져와 합친다.
pull : 리모트 저장소의 변경된 내용을 로컬 저장소에 적용하는 작업 (fetch+merge)
checkout : 특정 시점이나 브랜치로 이동, 체크아웃 대상은 브랜치, 커밋, 태그
fork : 저장소를 복제해서 새로운 독립된 저장소를 만드는 작업
clone: 원격에서 저장소를 최초로 가져올때 pull 대신 쓰는 명령어
origin : 기본 설정된 원격 주소에 붙는 별명
tag: 커밋에 붙는 별명
log : 저장소의 커밋 히스토리를 시간 순으로 보여준다.
reset 명령이 하는 역할
: 깃이 관리하는 세 개의 영역을 업데이트 working dir , index, head
-
head 가 가르키는 브랜치 이동 --soft 옵션: checkout처럼 head 자체를 움직이는 것이 아닌 head가 가르키는 브랜치가 가리키는 커밋을 바꾼다.
+ (soft 옵션으로 head를 이동한 후 git commit 명령을 실행하면 head가 가르키는 브랜치가 새로운 커밋을 가리키도록 업데이트 => squash : reset을 이용하여 커밋들을 합치기)
2. index 업데이트 -- mixed 옵션 (index는 커밋하기 전 상태의 영역- staging area)
reset --soft 에서 더 나아가 index를 현재 head가 가르키는 스냅샷으로 업데이트한다.
reset 명령을 실행할 때 아무 옵션도 주지않으면 기본적으로 --mixed 로 동작
3. working directory 업데이트 --hard 옵션
위험하다. 워킹 디렉토리를 head가 가르키는 스냅샷으로 업데이트한다. git에서는 데이터를 실제로 삭제하는 방법이 별로 없다. 하지만 hard 옵션은 데이터를 복구하는 것이 불가능하다.
reset과 checkout 혼동하지 않기
reset은 head가 가르키는 브랜치를 움직인다. (head열에 ref 라고 적힘)
checkout은 head 자체가 움직인다. (head 열에 head라고 적힘)
WD Safe? 라는 열을 주의하자. no라고 적혀있다면 워킹 디렉토리에 저장한 내역이 안전하지 않다.
git flow model
git flow란 저장소를 보다 고수준으로 관리하기 위한 기법이다.
git flow model은 2개의 핵심 브랜치와 3개의 서브 브랜치 총 5개의 브랜치를 가진다.
-
master : 모든 테스트 등이 끝나고 상용화가 가능한 최종 브랜치
-
develop : 현재 개발이 진행중인 브랜치
-
feature : 기능 추가 및 개발 작업 브랜치, develop 브랜치에서 파생되며 develop에 병합된다.
-
release : 배포하기 위한 브랜치, 지금까지 작업한 내역을 develop 브랜치에서 따와 배포하기 전 테스트하며 발견되는 버그들을 수정, 배포 준비가 완료되었다면 master 브랜치에 병합
-
hotfix: 갑자기 오류가 나서 디버그해야하는 경우와 같이 긴급하게 코드를 수정해야 하는 경우의 사용하는 branch ,master 브랜치에서 파생, 수정된 버그들을 반영하기 위해 develop와 master 두개의 브랜치에 병합된다. release 브랜치가 존재한다면 거기에도 반영되어야 한다.
'Git' 카테고리의 다른 글
Git flow strategy (0) | 2019.06.05 |
---|---|
Git Basic - Step.3 (0) | 2019.04.14 |
Git Basic - Step.2 (0) | 2019.04.08 |
CLI환경에서 GIT 사용하기 (0) | 2018.11.02 |