git 기초 사용법 (repo)

 

명령어	뜻
git clone	git clone [directory] -b dev (-b dev 꼭 추가하기!!) (git clone 시, local 에 편집할 파일을 저장, origin 에 remote 의 data의 포인터를 저장. origin 만 업뎃을 하려면 : fetch. origin과 local 편집을 비교하여 어떤 부분이 새로 고쳐졌는지를 보여준다. origin 과 local 을 모두 업뎃을 하려면 git pull. git clone 을 할때, 디렉토리 내에 .git 파일이 생긴다.)
origin	서버 위치를 가리킨다
origin/~	working 브랜치, 읽기 영역 서버와 동기화 된 시점의 local 쪽
git pull	파일 가져오기 git pull origin dev -> remote 에서 dev branch 를 현재의 branch 으로 가져오기 -> 어차피 내쪽으로 가져오니 ":" 앞쪽에는 아무것도 안쓴다. git pull --rebase: 내가 수정하는 도중 remote 에서 수정된 것을 다 쌓고 난 뒤에 내 수정된 파일이 올려짐
repo sync	git pull 과 동일
git status	git 추가하거나 변경할 폴더나 파일 확인
git add	git으로 추가하거나 변경할 폴더나 파일 추가 -> git 에서 추적되지 않은 파일을 등록하는 것. 버전 관리 시스템에 파일을 관리(staging)하는 것 (해당 파일은 터미널에서 "untracked files:" 문구 하위에 뜰 것) "untracked file" 은 반드시 add 후 commit을 해야 한다. add 하지 않으면 commit이 되지 않는다.
git commit	commit -m "[내용 추가할 것]"  ( []: log 남기기, 커밋할 때 log 을 잘 쓰자) (add 을 안할 경우, 커밋 하나에 자동으로 add까지 포함되었을 것이다) --amend : 가장 최근 커밋을 수정 --amend file0, file1 : file0, file1 을 변경사항에 업데이트  (뒤에 파일을 추가하지 않으면 메세지만 수정된다.) --amend -a : 모든 파일 git 에서는 시스템 해시코드를 바꾼다. 기존에 쓰는 것을 지우고 새로 쓴다. gerrit 에서는 기존것을 수정해서 바꾸는 것이라고 알고 있음. 따라서 굳이 abandon 을 할 필요가 없다. 그러나 git 은 아니기 때문에 push 한 것을 amend 해서는 안된다. (git pull 하는 순간 엄청 꼬일 것이다) commit 한 코드에서 메인 branch 에서는 에러(오류)가 발생하고, 임시 branch 에 올라가져 있는 경우 (서버에서는 merge 되지 않은 상태) amend 을 사용하면 간단하게 해결할 수 있다.
git push origin dev:dev (git push origin dev) (git push origin HEAD:dev)	git push origin dev:dev ([local branch name]:[server remote branch name]) - 근데 우리 센터는 gerrit 으로 이러한 다이렉트 push는 막혀 있음. - 보통 이름이 같으니 축약해서 git push origin dev -> 보통 local branch 이름과 remote branch 이름을 동일하게 하는 것이 안전하다
[gerrit] git push origin HEAD:refs/for/dev	remote 의 dev branch 으로 업로드
git log	commit 한 내역을 확인하는 방법
scp -p -P [ID] [hostname]@[server]:hooks/commit-msg .git/hooks/	새로 directory를 만든 뒤에 git에 올릴때, git push 에서 오류가 발생하게 되면 Hints: 문구에서 해당 부분을 찾아서 commit-msg 를 hook 에 설치할 것
git add -u	잘못 올린 파일들 삭제 시, 이와 같이 입력해야 삭제된 파일이 git 에도 반영 삭제 이후에 commit -m 을 해줘야 한다.
gitk	git merge, commit push 등을 gui 로 확인할 수 있는 방법 특정 디렉토리 내에서   gitk .   이라고 치면 해당 디렉토리 내의 git log 을 확인할 수가 있게 된다.
git revert	remote 에 반영돼 버려서 기존 커밋을 수정할 수 없을 때, 취소 커밋을 발행 어떤 특정 커밋에 대해 취소하는 새로운 커밋을 만든다는 뜻.  이 또한 commit 이기에 새로운 push 을 해야 한다. "git revert HEAD" HEAD: 최신 커밋을 가리키는 포인터. (엄밀하게는 HEAD~0 )
git reset --hard (HEAD) [ID] (HEAD 을 안쓰면 default 로 HEAD가 적용)	현재(working) branch 의 HEAD를 변경하는 명령. - 특정 커밋으로 HEAD를 이동시키고, 변경사항을 제거 - 커밋을 제거한다. git reset aaaaa: HEAD 의 포인터를 aaaaa 으로 다시 이동해라 (gitk 에서) [ID] 위치까지 git reset (이때, 로컬에서 수정된 부분은 전부 git으로 덮여쓰여져서 날라감) (status가 STAGED -> MODIFIED -> COMMITED 상태로 한번에 돌아감) (STAGED: commit 준비 상태) "--hard" 없으면 가장 최근 commit 내용까지 되돌려놓음. (HEAD: 가장 최신 commit 시점을 가리키는 포인터) >> git reset HEAD~1 - HEAD 하나 이전 커밋으로 돌아가게 된다.
git reset --hard origin/dev	(working branch 에서) origin/dev: 읽기 영역의 dev 의 최신으로 reset -> 근데 해당 시점은 서버에서 git clone 한 시점이기에, 항상 서버와는 동기화되어 있다고 볼 수는 없다. branch 이동은 하지 않는다!!
git reset --soft [ID]	(git reset 의 default 버전) 로컬 수정부분은 안 덮여쓰여짐 (staging 영역에 유지)
git reset --mixed [ID]	커밋을 취소하고, staging에서만 제거 (modified 된 상태에서만 둔다)
git checkout	file, commit, branch 을 이동하는 명령. (주기능) 파일 또는 디렉토리의 상태 복구. 변경사항 내용을 되돌림 (버림). COMMITED 상태의 깨끗한 상태로 돌아옴. (working하고 있는 HEAD의 branch 를 바꿀 수 있음, 예) git checkout dev: 다른 branch 에 있는 HEAD을 dev branch으로 바꿀 수 있음)  dev 에서 작업을 하다가 trunk 으로 넘어가면 commit을 하지는 않았기에 작업내용이 같이 넘어가게 된다. 조심! 예) git checkout dev -- a.v : dev branch 에만 존재하는 a.v 파일을 현재의 branch 로 가져오는 것. 그리고 MODIFIED 상태로 된다. git checkout --file0: 특정 file0 에서만 수정한 내용이 전부 지워진다. >> git checkout -b [local branch] [remote branch] [local branch] 을 만들면서 거기 branch 으로 이동하는데, 이때 [local branch]는 [remote branch] 에서 복사해온다.
git stash	수정한 내용을 commit 하지 않고 다른 데로 잠시 넘어갈 수 있음 나중에 다시 불러오려면 git stash pop 으로 꺼내면 된다.
git branch	git branch [branch_name] : [branch_name] 이라는 branch 생성 (-b 을 붙여줄 경우, 로컬의 working HEAD를 생성된 branch 로 바로 이동함, checkout 을 할 필요가 없음) 활성 branch는 별표(*)로 표시 git branch : 현재 working HEAD 가 어디인지를 보여줌 git branch -D [branch_name] : [branch_name] 을 삭제 해당 branch는 서버의 branch가 아니라 로컬의 branch. (HEAD detached at   aaaaaaaa) 명시적인 branch가 없는 경우 임시적으로만 가지고 있는다. 따라서 branch 을 dl이동하게 되면 사라진다.   비슷한 개발 방식). 어떠한 파일을 수정하다가, 기존의 수정한 파일을 ctrl+CV 한 뒤, 기존 파일을 파일명을 바꿔서 추가작업을 할 경우에 대한 명령어를 사용. - branch : cp - checkout: mv  와 유사하다고 보면 된다.  -vv : 해당 로컬 branch 가 서버의 어떠한 branch 에서 가져와졌는지를 확인
git branch -r	remote tracking branch 가 무엇이 있는지를 보여줌
git diff HEAD origin/dev	HEAD와 origin/dev 의 git 을 비교
git difftool -t meld -d [branch]	더 예쁘게 잘 비교
git fetch	remote 의 내용을 가져오되, local 의 수정 내용은 지우지 않는 방법 git fetch origin dev: remote 의 내용을 local 의 dev 쪽으로 가져오는 것. (이때 origin 은 remote 서버의 내용) >> 내가 작업을 하다가 (이미 git 이 새롭게 push된) 서버와 sync 를 맞추고 싶으면 git fetch 이후 git reset
git merge	working branch에 지정하는 브랜치를 병합 - git merge [병합할 브랜치 이름] 예). trunk branch 에서 git merge dev 커밋 하나하나마다 jenkins 에 다 올라가게 된다. merge 커밋이 하나 생기가 된다. 방식: -> 3-way merge: 히스토리 명확하게 추적, 긴 히스토리로 내용 파악이 어려울 수 있다. -> fast-foward: 가독성이 높을 수 있다. 변경사항 추적이 어렵다. 근데 ff 방식은 변경이력을 그대로 가져온다. 심지어는 commit ID과 Change-ID 까지도 그대로 가져온다. (따라서 --no--ff 을 사용해야 할 때가 필요. 아래쪽에 후술) 예). Common lib 에서 수정이 생기면, 수정 이후 Enc, Dec 으로 merge 각 Enc, Dec top 은 자체적인 branch >> git merge --no --ff dev 에서 파생된 working branch 이랑 dev 와 다시 merge 하려고 할때, 만일 기존 dev branch 에서 변경사항이 없을 경우 사용, 사실상 항상 쓰는 게 좋을지도 (gerrit 으로 인해 발생하는 문제)
git log	git log -2: 마지막 2개의 git log 볼 수 있다. git log --graph: merge 같은 그래프를 시각적으로 볼 수가 있게 된다.
vim ~/.config	git 정보 확인 가능
git rebase	comit 한 것을 다시 갖고 와서 무엇인가를 바꿀 때 쓴다. 1. $git checkout dev 2. $git rebase trunk -> trunk 을 기준으로 dev 브랜치를 재배치 그렇게 되면 HASH 가 변경된다. 그래서 바로 merge가 되는 것이 아니라, no fast foward 방식으로 재배치가 된다. 해당 문제는 HASH 가 바뀌는 데에서 발생하게 된다. 1. $git rebase trunk 2. $git checkout origin/dev 깨끗한 상태의 origin/dev 를 서버에서 가져온 다음, 그것을 기준으로 trunk 내용을 뒤에 붙인다.  --abort: git rebse 를 나가는 방법 -i HEAD~3 : git 에서 3번째 전까지 나온다. 여기에서 pick 을 골라서 고를 수 있게 된다. --continue : 넘긴다. -- 이전 커밋과 합치려면 rebase i HEAD~2 이후 두번째 pick 에서 s 로 교체
git conflict	두 브랜치가 같은 파일의 같은 위치를 다르게 수정하여 발생하는 에러 일반적으로 merge 를 시도할 때 발생 로컬의 수정사항 HEAD 과 다른 브랜치의 수정사항을 개발자가 직접 보고 수정해야 한다. <<<<<<<<<<< HEAD 현재 브랜치에서 수정된 내용 =========== 병합하려는 브랜치에서 수정된 내용 >>>>>>>>>>>> feature branch conflict 이전 상태로 원복하고자 할때: $git merge --abort $git rebase --abort

 

명령어	뜻
repo sync	git pull 같은 개념
repo start [branch명] --all

 

• git push vs commit vs add

https://thenicesj.tistory.com/506

[git] commit 과 push 의 차이점

 

• 서버에 수정한 코드 올리는 법

[Gerrit] 을 사용하는 경우 1.git pull 로 최신화 2. git status 로 상태 확인 3. git add <files> 으로 코드 (디렉토리) 추가 4. git commit -m "[project name]" 5. git push origin HEAD:refs/for/dev

 

 

참고 사이트:

https://xamadas.tistory.com/entry/Gerrit-%EC%97%90%EC%84%9C-HEADrefsforbranch-%EC%9D%98%EB%AF%B8

Gerrit 에서 HEAD:refs/for/branch 의미

 

https://hungc.tistory.com/98

repo 명령어 정리

 

 

https://baby-daramg.tistory.com/5

Gerrit - Commit Message에 Change-Id 입력하도록 설정

https://baby-daramg.tistory.com/6

Gerrit 에러 - Missing Change-Id in message footer

 

 

https://velog.io/@jollyn/Git-%ED%8C%8C%EC%9D%BC%EC%82%AD%EC%A0%9C%ED%95%98%EA%B8%B0

[Git] 파일삭제하기 : git rm

 

https://lsjsj92.tistory.com/524