Notice
Recent Posts
Recent Comments
Link
«   2025/05   »
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
Tags
more
Archives
Today
Total
관리 메뉴

리액트 정리

[생활코딩] 지옥에서 온 Git 명령어 본문

Git

[생활코딩] 지옥에서 온 Git 명령어

버그킴 2020. 7. 27. 23:58

Git명령어만 보고 쓰려니 원리가 잘 이해가 안돼서 강의를 하나 듣기로 했다.  고고// 

개념: version: 의미있는 변화. 코딩하다가 친구가 놀자~ 해서 중간에 나간다-> 의미있는 변화 x. 그 작업이 완결된 상태가 version이다. 

 

 

 

명령어

 

기본 명령어

$ git init
(이 폴더를 저장소로 쓰겠다. )
$ git status
$ git add 파일명 로 추적해주도록 (임시로 필요한 파일은 배제. 관리할 파일만 깃에게 알려줌. )
$ git config --global user.name 유저네임
$ git config --global user.email 이메일
이름과 이메일 주소를 포함한 버전으로 작성됨 - > 다른 사람이 알아볼 수 있다. 단 한번만 해주면 됨!
$ git commit
빔으로 연결. 맨 상단에 커밋메시지
$ git commit -a
: add + commit
$ git commit -am "커밋메시지"
: add + commit + commit message (에디터 켜지 않고 inline에서 커밋하기)
$ git commit --amend
: 최근 커밋 메시지 수정 (로컬)
$ git log 깃 로그 보기. (현재브랜치)

 

** 최초로 추적할 때도 add를 시키고, 파일을 수정하고 저장을 시킬때도 add를 시켜야 한다. 그런 후 commit. 

ex) f1.txt 파일 최초 생성 > git add > git status로 추적여부 확인 > git commit > f1.txt 파일 수정 > git add >git status로 추적여부 확인 > git commit

 

** stage: commit 대기하고있는 파일들이 가는 곳. (add후)

** repository: commit된 결과가 저장되는 곳. 

 

 

 

변경사항 확인하기(log&diff)

$ git log -p 해당파일경로
: 전체 커밋 내역 차이점 +-로 알려줌. 
$ git diff 커밋아이디..커밋아이디
: 둘 커밋 간 차이점 알려줌.
$ git diff
: git add전에 전체 달라진점 확인. 작업이 시작되기 전과 후 상황의 차이를 통해 내가 실수한 것은 없나 확인할 수 있는 마지막 기회를 제공한다. 

 

 

 

커밋 되돌리기 - 과거로 돌아가기 (reset v. revert)

$ git reset 3번의커밋아이디 --hard
: ex) 커밋 상태가 1, 2, 3, 4, 5 있을 때, => 3을 최신 커밋상태로 남기고 싶다 .. 날린것 처럼 보이지만 실제로는 살아있어서 나중에 복구할 수 있다.
          *** 원격저장소에 협업 - 내 저장소의 버전들을 공유하기 전에 내 컴퓨터에 있는 버전에 대해서만 reset작업을 해야 한다! 공유한 이후에는 절대 안됨. 
$ git revert
: git reset 후 새로운 버전을 추가하는 것. 

 

 

브랜치 

$ git --no-pager branch
: 브랜치 종류 확인 (-no-pager를 안하면, vim에서 열림.)
$ git branch 브랜치이름
: 브랜치 생성. 이 때, 생성되는 브런치는 현재 브랜치의 상태(커밋로그, 파일...)를 그대로 가져온다. 
$ git checkout 브랜치이름
: 들어갈 브랜치 
$ git checkout -b 브랜치이름
: 브랜치 생성 + checkout
$ git log --branches --decorate --graph --oneline
: 저장소에 있는 모든 브랜치들을 보여준다. HEAD-> 현재 checkout한 브랜치가 어디인지, 각각 브랜치의 최신 커밋 
$ git log --decorate --all --oneline --graph
$ git log master..exp
: master branch에는 없고 exp branch에는 있는것을 보여줌. (git log -p master..exp 변경여부까지 보여줌)
$ git diff
: index(staging area)의 내용과 working directory의 내용을 비교
$ git diff master..exp

 

$ stree
: 터미널에서 현재 브랜치로 소스트리 열기
$ git merge exp
: 현재 checkout한 브랜치에서 exp브랜치를 merge하기. 
$ git branch -d exp
: exp 브랜치 삭제

 

stash - 지저분한 워킹 디렉토리 내용을 저장하되 커밋에 감추기. 

커밋은 유의미한 작업만. 

미완성, 작업중인 것들은 stash로 따로 저장. => 작업 끝 => 커밋

git reset해도 stash로 저장한 작업들은 날아가지 않는다. 추후 apply + drop 가능

* 파일이 git add로 추적되고 있는 상태에만 작동함. 

 

$ git checkout -b exp(브랜치이름임)
: git branch exp + git checkout exp
$ git stash
: 작업하고 있던것 저장하기. 
$ git stash list 
: 작업하고 있던것 저장된 리스트 보기 (WIP - Work In Progress)
$ git stash apply
: stash 리스트에서 가장 위(최신)의 WIP를 브랜치에 적용하기. 
$ git stash drop
: stash 리스트에서 최신 WIP를 삭제하기. (순차적으로 apply하고 drop으로 삭제)
$ git stash pop
: apply + drop 

 

 

Merge & Conflict

1) 충돌 해결하기. 

다른 브랜치에서 같은 파일의 같은 부분을 수정하고 merge하려고 했을 때 conflict 발생. 

 

$ git merge exp -> 충돌 발생

                    |

$ git status -> unmerged... 메시지 확인. 

                    |

에디터로 들어가서 충돌난 부분 수정. 

                    |

$ git add 충돌파일

                    |

$ git commit -> 충돌났었고 수정됐다는 메시지 확인. 

더보기
function b() {
} 
<<<<<<< HEAD // 현재 checkout branch
function a(master) {
======= // 이 부분이 달라요 알아서 해결하세요
function a(exp) {
>>>>>>> exp // merge시도 branch
}
function c() {
}

/// 수정

function b() {
} 
function a(master, exp) {
}
function c() {
}

 

2) 3 way Merge

Base 브랜치를

(1) Me 브랜치에서는 AB1로 바꾸고

(2) Other 브랜치에서는 B2D로 바꿨다면

=> 어떻게 병합하고 충돌을 해결할까. 

 

- 2 way merge: Me / Other만 비교해서 병합 (안쓰는 방법. 판단의 기준이 없다. 원본대비 내용이 있는게 수정사항인지 있는게 수정사항인지.. )

- 3 way merge: Me - Base - Other을 모두 비교해서 병합

3 way merge가 충돌빈도가 적다

 

 

Reset checkout

$ git reset --hard 커밋아이디
* 이렇게 해도 그 뒤의 커밋이 사라지는건 아님. ./git/logs/ORIG_HEAD에 저장되어 있기 때문에 복구 가능. 
* reset 후 --hard, --soft를 지정하지 않으면, --mixed로 동작. 
$ git reset --hard ORIG_HEAD
: 리셋 복구하기
$ git reflog
: 리셋 로그보기

reset으로 취소되는 범위

- working directory: add 하지 않은 상태

- index, staging area: add 후 commit 전 staged된 상태, 

- repository: commit된 상태. 

 

 

 

 

원격 저장소 ----- 정리중

- 로컬저장소 생성 > cd 로컬저장소 > git init > gir remote add origin 원격저장소주소 > git push - origin master (또는 upstream 세팅) > git push

- 원격저장소 생성 > git clone 원격저장소주소 로컬디렉토리이름

git init --bare 
: 원격저장소 만들 때. 
$ git clone 원격저장소주소 로컬디렉토리이름
: 원격 저장소를 로컬 디렉토리에 복사
$ git remote add origin 원격저장소주소
: 원격 저장소를 origin이라는 이름을 붙여서 로컬 저장소에 추가
$ git remote -v
: 원격 저장소 목록 보기
$ git push -u origin master
: master 브랜치를 원격 저장소 origin에 push하겠다는 기본값 설정
$ git push
: master브랜치를 기본설정된 origin에 push
$ git pull
: 원격 저장소에서 로컬로 받아오기

 

 

Pull vs Fetch

$ git fetch
: 원격 저장소의 내용을 확인만 하고 로컬 데이터와 병합은 하고 싶지 않은 경우 (이 때 가져온 최신 커밋 이력은 이름 없는 브랜치로 로컬에 가져오게 됩니다. 이 브랜치는 'FETCH_HEAD'의 이름으로 체크아웃 할 수도 있습니다.)
$ git merge origin/master
: origin에 브랜치(master)를 병합
$ git pull 
: fetch+merge. (주로 pull 을 씀.)
 

fetch(가져오기)【원격 저장소】 | 누구나 쉽게 이해할 수 있는 Git 입문~버전 관리를 완벽하게 이��

fetch(가져오기)【원격 저장소】 | 누구나 쉽게 알 수 있는 Git에 입문하신 것을 환영합니다. Git을 사용해 버전 관리를 할 수 있도록 함께 공부해봅시다!

backlog.com

 

 

Merge vs Rebase

merge: 히스토리 파악이 어렵지만 충돌 해결이 쉬움. 

rebase: 히스토리 파악이 쉽지만 사용이 어려움. 

$ git checkout rb
$ git rebase master
: 현재 rb 브랜치의 베이스를 master 브랜치로 바꿈. R1, R2 커밋의 베이스가 master 브랜치의 최신 커밋인 M2로 바뀜

1 --- M1---M2
   \---R1---R2
 
1---M1---M1---R1---R2

(왼) rebase 전 / (오) rebase 후

 

master 브랜치를 rb 브랜치와 merge. - Fast-forward

 

 

 

 

Tag

$ git tag 태그할버전이름 브랜치이름or커밋아이디

$ git checkout 태그할버전이름
: 태그 당시 커밋 버전으로 돌아가기 
$ git tag -a 태그할버전이름 -m "태그메시지"
: 태그에 주석달기 (a: annotated) ex) git tag -a 1.1.0 -m "bug fix"
$ git tag -a 1.0 -m "first release" master
: 예시. master 브랜치의 head에 해당되는 버전에 tag생성
$ git tag
: 태그 버전들 확인. 
$ git tag -v
: 태그 주석 등 상세정보 확인 ex) git tag -v 1.1.0
$ git push --tags
: 로컬 태그 원격 저장소로 보내기 

 

 

 

 

Git Flow

 

 

 

 

 

 

 

 

* 명령어 구글 조회 빈도수

더보기

commit 

push

pull

clone

checkout

add

branch

log

diff

fetch

merge

init

status

reset

tag

rebase

 

* Git의 내부 메카니즘: 

더보기

 

blob: 파일의 내용 (내용이 같으면 파일명이 달라도 커밋아이디가 동일함. )

tree: blob에 대한 정보들

commit: 해당 파일 커밋정보, tree, parent

 

 

https://stackoverflow.com/questions/3689838/whats-the-difference-between-head-working-tree-and-index-in-git