Git Command
Git을 사용해서 프로젝트 관리하는 것에 대한 명령어를 배워봅니다.
Git의 기본 개념인 push, pull, commit, branch 등에 대해 알아보며 windows에서의 실행을 전제로 합니다.
Git Working Flow - 작업 흐름
여러분의 로컬 저장소는 git이 관리하는 세 그루의 나무로 구성되어 있습니다.
첫번째 나무인 작업 디렉토리(Working directory)는 로컬(실제) 파일들로 이루어져있고, 두번째 나무인 인덱스(Index)는
준비 영역(staging area)의 역할을 하며, 마지막 나무인 HEAD는
최종 확정본(commit)을 나타냅니다.
Git 저장소 만들기
Git 저장소를 만드는 방법은 두 가지입니다.
기존 프로젝트를 Git 저장소로 만드는 방법이 있고 다른 서버에 있는 저장소를 Clone하는 방법이 있습니다.
기존 디렉토리를 Git 저장소로 만들기
기존 프로젝트를 Git으로 관리하고 싶을 때, 프로젝트의 디렉토리로 이동해서 아래과 같은 명령을 실행합니다.
git init이 명령은 .git이라는 하위 디렉토리를 만든다.
.git 디렉토리에는 저장소에 필요한 뼈대 파일(Skeleton)이 들어 있 이 명령만으로는 아직 프로젝트의 어떤 파일도 관리하지는 않습니다.
즉, 새로운 git 저장소가 만들어집니다.
Git이 파일을 관리하게 하려면 저장소에 파일을 추가하고 커밋해야 합나다. git add 명령으로 파일을 추가하고 커밋합니다:
$ git add *.c
$ git add README
$ git commit -m 'initial project version'매우 짧은 시간에 명령어를 몇개 실행해서 Git 저장소를 만들고 파일이 관리되게 될 것입니다.
기존 저장소를 Clone하기
다른 프로젝트에 참여하거나(Contribute) Git 저장소를 복사하고 싶을 때 git clone 명령을 사용합니다.
이미 Subversion 같은 VCS에 익숙한 사용자에게는 checkout이 아니라 clone이라는 점이 도드라져 보일 것입니다.
Git이 Subversion과 다른 가장 큰 차이점은 서버에 있는 모든 데이터를 복사한다는 것이다. git clone을 실행하면 프로젝트 히스토리를 전부 받아옵니다.
실제로 서버의 디스크가 망가져도 클라이언트 저장소 중에서 아무거나 하나 가져다가 복구하면 됩니다.(서버에만 적용했던 설정은 복구하지 못하지만 모든 데이터는 복구된다)
git clone [url] 명령으로 저장소를 Clone합니다. Ruby용 Git 라이브러리인 Grit을 Clone하려면 아래과 같이 실행합니다:
git clone git://github.com/schacon/grit.gitgit clone [url] 명령으로 저장소를 Clone합니다. Ruby용 Git 라이브러리인 Grit을 Clone하려면 아래과 같이 실행한다:
이 명령은 "grit"이라는 디렉토리를 만들고 그 안에 .git 디렉토리를 만든다. 그리고 저장소의 데이터를 모두 가져와서 자동으로 가장 최신 버전을 Checkout해 놓는다.
grit 디렉토리로 이동하면 Checkout으로 생성한 파일을 볼 수 있고 당장 하고자 하는 일을 시작할 수 있습니다.
아래과 같은 명령을 사용하여 저장소를 Clone하면 "grit"이 아니라 다른 디렉토리 이름으로 Clone할 수 있다:
git clone git://github.com/schacon/grit.git mygrit디렉토리 이름이 mygrit이라는 것만 빼면 이 명령의 결과와 앞선 명령의 결과는 같습니다.
Git은 다양한 프로토콜을 지원합니다.
이제까지는 git:// 프로토콜을 사용했지만 http(s)://를 사용할 수도 있고 user@server:/path.git처럼 SSH 프로토콜을 사용할 수도 있습니다.
수정하고 저장소에 저장하기
위와 같이 진행했다면 만질 수 있는 Git 저장소를 하나 만들고 워킹 디렉토리에 Checkout도 했을 것입니다.
이제는 파일을 수정하고 파일의 스냅샷을 커밋해 봅니다. 파일을 수정하다가 저장하고 싶으면 스냅샷을 커밋합니다.
워킹 디렉토리의 모든 파일은 크게 Tracked(관리대상임)와 Untracked(관리대상이 아님)로 나누어 집니다.
Tracked 파일은 이미 스냅샷에 포함돼 있던 파일이고, Tracked 파일은 또 Unmodified(수정하지 않음)와 Modified(수정함) 그리고 Staged(커밋하면 저장소에 기록되는) 상태 중 하나입니다.
그리고 나머지 파일은 모두 Untracked 파일이다. Untracked 파일은 워킹 디렉토리에 있는 모든 파일이 스냅샷에 포함돼 있는 것은 아니고 Staging Area에 있는 것도 아닙니다.
처음 저장소를 Clone하면 모든 파일은 Tracked이면서 Unmodified 상태가 됩니다. 파일을 Checkout하고 나서 아무것도 수정하지 않았기 때문에 그렇습니다.
git status - 파일의 상태 확인하기
파일의 상태를 확인하려면 보통 git status 명령을 사용한다. Clone한 후에 바로 이 명령을 실행하면 아래과 같은 메시지를 볼 수 있습니다:
git status
On branch master
nothing to commit, working directory clean위의 내용은 파일을 하나도 수정하지 않았다는 것을 말해줍니다. Tracked나 Modified 상태인 파일이 없다는 의미이고, Untracked 파일은 아직 없어서 목록에 나타나지 않습니다.
그리고 현재 작업 중인 브랜치를 알려줍니다. 기본 브랜치가 master이기 때문에 현재 master로 나오는 것입니다.
브랜치 관련 내용은 차차 알아봅니다.
git add - 파일을 새로 추적하기
git add 명령으로 파일을 새로 추적할 수 있습니다. 아래 명령을 실행하면 Git은 README 파일을 추적합니다:
git add READMEgit add를 하기 전에 어떤 파일을 만들었다면 git status를 실행해 보면 파일중에 Git은 Untracked 파일을 보여줍니다.
이것은 아직 스냅샵(커밋)에 넣어지지 않은 파일이라고 보고 파일이 Tracked상태가 되기 전까지는 Git은 절대 그 파일을 커밋하지 않습니다.
그렇기 때문에 git add 명령어로 직접 Tracked 상태로 만들어 파일을 추척하도록 만드는 것입니다.
git add 를 한 후 git status 명령을 다시 실행하면 README 파일이 Tracked 상태이면서 Staged 상태라는 것을 확인할 수 있습니다:
git status
On branch master
Changes to be committed:
(use "git reset HEAD ..." to unstage)
new file: README 'Changes to be committed' 에 들어 있는 파일은 Staged 상태라는 것을 의미합니다.
커밋하면 git add를 실행한 시점의 파일이 커밋되어 저장소 히스토리에 남습니다. 앞에서 git init 명령을 실행했을 때, 그 다음 git add (files) 명령을 실행했던 걸 기억할 것입니다.
이것은 작업 디렉토리에 있는 파일들을 추적하기 시작하게 하기 위함입니다.
git add 명령은 파일 또는 디렉토리의 경로명을 아규먼트로 받고 만일 디렉토리를 아규먼트로 줄 경우, 그 디렉토리 아래에 있는 모든 파일들을 재귀적으로 추가할 것입니다.
그리고 git add는 파일을 새로 추적할 때도 사용하고 수정한 파일을 Staged 상태로 만들 때도 사용합니다.
그리고 다음과 같은 명령어 중 하나 선택하여 실행할 수도 있습니다. 이는 위 작업흐름 중 인덱스에 추가하는 것입니다.
git add <파일 이름>
git add *
git add *.*
git add .git commit - 변경사항 커밋하기
수정한 것을 커밋하기 위해 Staging Area에 파일을 정리했습니다. Unstaged 상태의 파일은 커밋되지 않는다는 것을 기억해야 합니다.
Git은 생성하거나 수정하고 나서 git add 명령으로 추가하지 않은 파일은 커밋하지 않습니다. 그 파일은 여전히 Modified 상태로 남아 있을 것입니다.
커밋하기 전에 git status 명령으로 모든 것이 Staged 상태인지 확인할 수 있다. 그리고 git commit을 실행하여 커밋하도록 합니다:
실제로 staged 변경 내용을 확정하려면 아래 명령을 실행해야 합니다.
git commit -m "변경된 메시지 내용을 입력"git에서 커밋은 변경사항을 내 컴퓨터에 저장한다는 의미입니다. 위 명령어를 실행하면 이제 작업흐름상에 변경된 파일이 HEAD에 반영될 것입니다. 하지만, 원격 저장소에는 아직 반영이 되지는 않았습니다.
그리고 만약에 위 명령어중 -m 메세지 부분을 안적어주면 vim(내장 편집기)이 실행되니 주의바랍니다.
또한 git add 명령을 실행했을 지라도 git add 명령을 실행한 후에 또 파일을 수정하면 파일의 상태는 Ustaged 상태로 나옵니다.
그렇기 때문에 파일을 수정한 후에는 git add 명령을 다시 실행해서 최신 버전을 Staged 상태로 만들어야 합니다.
이러한 사이클을 반복하지 않기 위해서 다음과 같은 명령을 실행합니다.
git commit -am "커밋 메시지 내용"git commit 명령을 실행할 때 -a 옵션을 추가하면 Git은 Tracked 상태의 파일을 자동으로 Staging Area에 넣습니다. 그래서 git add 명령을 실행하는 수고를 덜 수 있을 것입니다.
git rm - 파일을 삭제하기
Git에서 파일을 제거하려면 git rm 명령으로 Tracked 상태의 파일을 삭제한 후에(정확하게는 Staging Area에서 삭제하는 것) 커밋해야 합니다.
이 명령은 워킹 디렉토리에 있는 파일도 삭제하기 때문에 실제로 지워집니다.
만약 Git없이 그냥 파일을 삭제하고 git status 명령으로 상태를 확인하면 Changes not staged for commit(즉, Unstaged) 에 속한다는 것을 확인할 수 있다:
git status
On branch master
Changes not staged for commit:
(use "git add/rm ..." to update what will be committed)
(use "git checkout -- ..." to discard changes in working directory)
deleted: test.txt
no changes added to commit (use "git add" and/or "git commit -a") 그리고 git rm 명령을 실행하면 삭제한 파일은 staged 상태가 될 것입니다.
$ git rm text.txt
rm 'text.txt'
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD ..." to unstage)
deleted: text.txt 커밋하면 파일은 삭제되고 Git은 이 파일을 더는 추적하지 않습니다.
이미 파일을 수정했거나 Index에(Staging Area을 Git Index라고도 부른다) 추가했다면 -f옵션을 주어 강제로 삭제해야 합니다.
이 점은 실수로 데이터를 삭제하지 못하도록 하는 안전장치입니다. 한 번도 커밋한적 없는 데이터는 Git으로 복구할 수 없습니다.
또 Staging Area에서만 제거하고 워킹 디렉토리에 있는 파일은 지우지 않고 남겨둘 수 있습니다.
다시 말해서 하드디스크에 있는 파일은 그대로 두고 Git만 추적하지 않도록 합니다.
이것은 .gitignore 파일에 추가하는 것을 빼먹었거나 대용량 로그 파일이나 컴파일된 파일인 .a 파일 같은 것을 실수로 추가했을 때 사용할 수 있습니다.
--cached 옵션을 사용하여 명령을 실행한다:
git rm --cached readme.txt여러 개의 파일이나 디렉토리를 한꺼번에 삭제할 수도 있습니다.
아래와 같이 git rm 명령에 file-glob 패턴을 사용
git rm log/\*.log*앞에 \을 사용한 것을 기억합니다. 파일명 확장 기능은 쉘에만 있는 것이 아니라 Git 자체에도 있기 때문에 필요합니다.
Windows 기본 쉘을 쓸 때는 \(역슬래시) 기호를 붙이지 않습니다.
이 명령은 log/ 디렉토리에 있는 .log 파일을 모두 삭제한다.
아래의 예제처럼 할 수도 있습니다:
git rm \*~이 명령은 ~로 끝나는 파일을 모두 삭제한다.
git push - 변경된 내용 푸쉬(발행)하기
push는 마지막으로 커밋한 사항을 git repository 에 올리겠다는 뜻입니다. push가 안되면 원격 서버에 변경사항이 저장되지 않습니다.
다시말해, 프로젝트를 공유하고 싶을 때 리모트 저장소에 Push할 수 있습니다.
이 명령은 git push [리모트 저장소 이름] [브랜치 이름]으로 단순합니다. (Clone하면 보통 자동으로 origin 이름이 생성된다)
commit 까지만 실행했다면 현재의 변경 내용은 아직 로컬 저장소의 HEAD 안에 머물고 있을 것입니다. 이제 이 변경 내용을 원격 서버로 올리기 위해 아래 명령을 실행합니다.
git push - u origin master위 명령어 중 origin과 master는 각각 리모트 저장소와 브랜치를 의미합니다.
또한 -u는 원격저장소로부터 업데이트를 받은 후 push를 한다는 의미이므로 습관적으로 -u 사용을 권장합니다.
이유는 Clone한 사람이 여러 명 있을 때, 다른 사람이 Push한 후에 Push하려고 하면 Push할 수 없기 때문에 먼저 다른 사람이 작업한 것을 가져와서 머지한 후에 Push할 수 있습니다.
그리고 다른 브랜치(가지)를 발행하려면 master를 원하는 브랜치 이름으로 바꿔주어야 합니다.
여러분이 뭔가 변경될 때마다 해야 할 일은 간단히 다음과 같을 것입니다.
pull -> commit -> push
그리고 만약 기존에 있던 원격 저장소를 복제한 것이 아니라면, 원격 서버의 주소를 git에게 알려줘야 할 것입니다.
git remote add origin <원격 서버 주소>이제 변경 내용을 원격 서버로 푸쉬(발행)할 수 있을 것입니다.
지금 git 내용은 CLI 기반의 내용이지만 GUI 기반에서 깃을 사용한다면 GUI에 따라서 푸쉬(push)는 push(푸쉬) 또는 publishing(발행)으로 사용됩니다.
아이디와 비밀번호 저장하기
git 콘솔에서 다음과 같이 한번만 입력해 놓으면 push나 pull 등 서버에 접속하면서 팝업으로 뜨는 아이디 비밀번호창을 띄우지 않도록 아이디 및 비번을 기억하도록 할 수 있습니다.
git config credential.helper store .gitignore - 파일 무시하기
어떤 파일은 Git이 자동으로 추가하거나 Untracked 파일이라고 보여줄 필요가 없을 것입니다.
보통 로그 파일이나 빌드 시스템이 자동으로 생성한 파일이 이에 해당합니다. 그런 파일을 무시하려면 .gitignore 파일을 만들고 그 안에 무시할 파일 패턴을 적습니다.
아래는 .gitignore 파일의 예이다:
$ cat .gitignore
*.[oa]
*~첫번째 줄은 확장자가 .o 나 .a인 파일을 Git이 무시하라는 것이고 둘째 줄은 ~로 끝나는 모든 파일을 무시하라는 것입니다.
.o와 .a는 각각 빌드 시스템이 만들어내는 오브젝트와 아카이브 파일이고 ~로 끝나는 파일은 Emacs나 VI 같은 텍스트 편집기가 임시로 만들어내는 파일입니다. 또 log, tmp, pid 같은 디렉토리나, 자동으로 생성하는 문서 같은 것들도 추가할 수 있습니다.
.gitignore 파일은 보통 처음에 만들어 두는 것이 편리합니다. 그래서 Git 저장소에 커밋하고 싶지 않은 파일을 실수로 커밋하는 일을 방지할 수 있습니다.
.gitignore 파일에 입력하는 패턴은 아래 규칙을 따른다:
- 아무것도 없는 줄이나, #로 시작하는 줄은 무시한다.
- 표준 Glob 패턴을 사용한다.
- 디렉토리는 슬래시(/)를 끝에 사용하는 것으로 표현한다.
- 느낌표(!)로 시작하는 패턴의 파일은 무시하지 않는다.
Glob 패턴은 정규표현식을 단순하게 만든 것으로 생각하면 되고 보통 쉘에서 많이 사용합니다.
애스터리스크(*)는 문자가 하나도 없거나 하나 이상을 의미하고, [abc]는 중괄호 안에 있는 문자 중 하나를 의미합니다.(그러니까 이 경우에는 a, b, c). 물음표(?)는 문자 하나를 말하고, [0-9]처럼 중괄호 안의 캐릭터 사이에 하이픈(-)을 사용하면 그 캐릭터 사이에 있는 문자 하나를 말한다.
다음은 .gitignore 파일의 예이다:
# a comment - 이 줄은 무시한다.
# 확장자가 .a인 파일 무시
*.a
# 윗 줄에서 확장자가 .a인 파일은 무시하게 했지만 lib.a는 무시하지 않는다.
!lib.a
# 루트 디렉토리에 있는 TODO파일은 무시하고 subdir/TODO처럼 하위디렉토리에 있는 파일은 무시하지 않는다.
/TODO
# build/ 디렉토리에 있는 모든 파일은 무시한다.
build/
# `doc/notes.txt`같은 파일은 무시하고 doc/server/arch.txt같은 파일은 무시하지 않는다.
doc/*.txt
# `doc` 디렉토리 아래의 모든 .txt 파일을 무시한다.
doc/**/*.txt되돌리기 - Undo
일을 하다보면 모든 단계에서 어떤 것은 되돌리고(Undo) 싶을 때가 있습니다. 이번에는 우리가 한 일을 되돌리는 방법을 살펴볼 것입니다.
한 번 되돌리면 복구할 수 없어서 주의해야 합니다.
Git을 사용하면 우리가 한 실수를 복구하지 못할 것은 거의 없지만 되돌리기는 복구할 수 없다는 점을 기억해야 합니다.
커밋 수정하기
종종 완료한 커밋을 수정해야 할 때가 있습니다. 너무 일찍 커밋했거나 어떤 파일을 빼먹었을 때 그리고 커밋 메시지를 잘못 적었을 때 하게 됩니다. 다시 커밋하고 싶으면 --amend 옵션을 사용한다:
git commit --amend이 명령은 Staging Area를 사용하여 커밋하는 것입니다.
만약 마지막으로 커밋하고 나서 수정한 것이 없다면(커밋하자마자 바로 이 명령을 실행하는 경우) 조금 전에 한 커밋과 모든 것이 같습니다.
이때는 커밋 메시지만 수정하면 될 것입니다.
그리고 편집기가 실행되면 이전 커밋 메시지가 자동으로 포함되며 메시지를 수정하지 않고 그대로 커밋해도 기존의 커밋을 덮어쓴다.
커밋을 했는데 Stage하는 것을 깜빡하고 빠트린 파일이 있으면 아래와 같이 고칠 수 있다:>
git commit -m 'initial commit'
git add forgotten_file
git commit --amend여기서 실행한 명령어 3개는 모두 하나의 커밋으로 기록됩니다. 두 번째 커밋은 첫 번째 커밋을 덮어씁니다.
파일 상태를 Unstage로 변경하기
다음은 Staging Area와 워킹 디렉토리 사이를 넘나드는 방법에 대해 알아봅니다.
이 방법은 두 영역의 상태를 확인할 때마다 변경된 상태를 되돌리는 방법을 알려주기 때문에 매우 편리합니다.
예를 들어 파일을 두 개 수정하고서 따로따로 커밋하려고 했지만, 실수로 git add * 라고 실행해 버렸다면 두 파일 모두 Staging Area에 들어가 있을 것입니다.
이제 둘 중 하나를 어떻게 꺼낼까? 우선 git status 명령으로 확인해보자:
git add .
git status
On branch master
Changes to be committed:
(use "git reset HEAD ..." to unstage)
modified: README.txt
modified: benchmarks.rb Changes to be commited: 밑에 git reset HEAD 이라는 문장을 볼 수 있다. 이 명령으로 Unstage 상태로 변경할 수 있다. benchmarks.rb 파일을 Unstage 상태로 변경해보자:
git reset HEAD benchmarks.rb
Unstaged changes after reset:
M benchmarks.rbgit status 를 다시 실행해 본다면:
git status
On branch master
Changes to be committed:
(use "git reset HEAD ..." to unstage)
modified: README.txt
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git checkout -- ..." to discard changes in working directory)
modified: benchmarks.rb 명령어가 낮설게 느껴질 수도 있지만 잘 동작합니다. benchmarks.rb 파일은 Unstage 상태가 된 것입니다.
Modified 파일 되돌리기
어떻게 해야 benchmarks.rb 파일을 수정하고 나서 다시 되돌릴 수 있을까?
그러니까 최근 커밋된 버전으로(아니면 처음 Clone했을 때처럼 워킹 디렉토리에 처음 Checkout 한 그 내용으로) 되돌리는 방법이 무얼까?
git status 명령이 친절하게 알려준다.
바로 위에 있는 예제에서 Unstaged 부분을 보자:
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git checkout -- ..." to discard changes in working directory)
modified: benchmarks.rb 위의 메시지는 수정한 파일을 되돌리는 방법을 꽤 정확하게 알려줍니다.(적어도 Git 1.6.1이후 버전부터). 알려주는 대로 한 번 해봅니다:
git checkout -- benchmarks.rb
git status
On branch master
Changes to be committed:
(use "git reset HEAD ..." to unstage)
modified: README.txt 정상적으로 복원된 것을 알 수 있습니다. 하지만 이 명령은 꽤 위험한 명령이라는 것을 알아야 합니다.
수정 이전의 파일로 덮어썼기 때문에 수정했던 내용은 전부 사라집니다. 수정한 내용이 진짜 마음에 들지 않을 때에만 사용하도록 합니다.
정말 이렇게 삭제해야 한다면 Stash와 Branch를 사용하는 것이 좋습니다.
Git으로 커밋한 모든 것은 언제나 복구할 수 있다. 삭제한 브랜치에 있었던 것도 --amend 옵션으로 다시 커밋한 것도 복구할 수 있다.
하지만, 커밋하지 않고 잃어버린 것은 절대로 되돌릴 수 없다.
Git 충돌 관리 - Conflict
버전 관리 툴을 사용할 때 초보자들이 가장 무서워하고 잘 못 다루는 게 충돌(conflict)인 것 같습니다.
같은 부분을 두 개발자가 동시에 고친 다음 한 명이 먼저 push를 하고, 다음 사람이 push를 하면 충돌이 일어나게 될 것이고 혼자 일할 때도 충돌을 만날 수 있습니다.
branch에서 작업을 하다가 master에서 뭔가 고친 다음, branch에서 또 같은 줄의 것을 고치면 충돌이 일어나게 됩니다.
그리고 stash 상태에서 pull을 한 뒤 git stash apply를 했을 때도 충돌이 벌어질 수 있습니다. 정확히는 모르지만 같은 걸 동시에 고치지 않았는데도 충돌이 나는 경우도 있습니다.
아무튼, git이 자동으로 병합하지 합치지 못하는 상황이 발생하게 되면 충돌이 발생하고 이는 사용자에게 충돌을 해결 할 것을 요구하게 됩니다.
그리고 우리는 충돌을 해결한 후 이를 git에게 알려줘야 합니다.
다음은 어떤 상황에서 충돌이 발생했다는 가정하에 했을 때 git에서 보여주는 메시지입니다 :
First, rewinding head to replay your work on top of it...
Applying: 더 보기 버튼 추가
Using index info to reconstruct a base tree...
M index.html
Falling back to patching base and 3-way merge...
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Failed to merge in the changes.
Patch failed at 0001 더 보기 버튼 추가
The copy of the patch that failed is found in:
/path/to/.git/rebase-apply/patch
When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".번역해 보면 다음과 같습니다.
우선, 작업을 처음부터 재실행하기 위해서 head로 되감습니다.
'더 보기 버튼 추가'를 적용중입니다.
base tree를 재구축하기 위해 색인 정보를 사용중입니다.
M index.html (index.html이 수정됐다는 뜻)
base 재구축과 3방향 합치기가 잘못되는 경우에 대한 대비책을 만들고 있습니다.
index.html을 자동으로 합칩니다.
충돌 발생 (내용): index.html에서 합치기 충돌 발생
'0001 더 보기 버튼 추가' patch 실패
실패한 patch는 다음 경로에서 볼 수 있습니다.
/path/to/.git/rebase-apply/patch
이 문제를 수정한 뒤, "git rebase --continue"를 실행하세요.
이 patch를 건너뛰려면, "git rebase --skip"을 실행하세요.
rebase를 중단하고 원래대로 되돌리려면, "git rebase --abort"를 실행하세요.사실 위쪽의 메시지 내용보다 아래쪽 세 줄이 핵심입니다.
고친 경우, 건너뛸 경우, rebase를 취소할 경우, 각각의 경우에 내려야 할 명령을 친절하게 알려 주고 있습니다.
메시지를 다시 보고 싶으면 git status를 하면 될 것입니다.
충돌된 파일을 열어보면 다음과 같은 부분이 표시되어 있을 것입니다.
<<<<<<< HEAD
<div class="list-box">
<h2 class="list-box__title">Branch 연습용 목록</h2>
<ul class="unordered-list">
<li class="list-item">이것은 1번째 li입니다.</li>
<li class="list-item">이것은 2번째 li입니다.</li>
<li class="list-item">이것은 3번째 li입니다.</li>
</ul>
</div>
=======
<h2>Branch 연습용 목록</h2>
<ul class="unordered-list">
<li class="list-item">이것은 1번째 li입니다.</li>
<li class="list-item">이것은 2번째 li입니다.</li>
<li class="list-item">이것은 3번째 li입니다.</li>
</ul>
<a href="#">더 보기</a>
>>>>>>> 더 보기 버튼 추가충돌된 파일을 살펴보면 조금 너저분해져 있는 상태를 보게 될 것입니다.
위 파일에서 ======= 기호를 기준으로 하여 <<<<<< HEAD 는 사용자가 선택한 브랜치에서 즉, checkout한 브랜치가 HEAD(사용자가 커밋한 브랜치)를 뜻하게 됩니다.
그리고 >>>>>> 기호는 다른 이가 추가하거나 수정한 내용일 수 있습니다.
이 충돌난 파일을 사용자 판단(무엇이 적합한 코드인지)하에 통합하면 될 것입니다.
아래는 더 보기 버튼이 추가되었다고 판단하여 코드를 통합한 결과입니다.
<div class="list-box">
<h2 class="list-box__title">Branch 연습용 목록</h2>
<ul class="unordered-list">
<li class="list-item">이것은 1번째 li입니다.</li>
<li class="list-item">이것은 2번째 li입니다.</li>
<li class="list-item">이것은 3번째 li입니다.</li>
</ul>
<a href="#">더 보기</a>
</div>사용자가 코드를 병합했다면 아래의 순서대로 명령을 실행합니다 :
git add <충돌난 파일명>
git rebase --continue
위와 같이 순서대로 실행했다면 충돌은 해결되었을 것입니다.
Git 자주 사용되는 명령어 정리
$ git branch -> 로컬 branch 확인
$ git branch -r 서버 branch 확인
$ git checkout -b 브랜치명 브랜치를 만들고 바로 이동
$ git branch -d(D) test 브랜치 삭제
$ git status 현재상태(머지나 추가사항) 확인
$ git add 경로 에러를 해결하고 추가하여 에러해결
$ git stash 임시저장
$ git stash pop 임시저장한파일 불러오기
$ git remote prune origin 깃랩에서 삭제한거 서버와 동기화
$ git push origin :브랜치네임 서버에서 삭제하기
$ git remote
$ git push origin dev
$ git config http.postBuffer 104857600 git오류시 해결
$ git merge --squash dev
$ git merge --no-ff feature- : 새로운 가지 따서 merge(관리상 용이)
$ git clone 주소
$ git remote set-url origin 주소 : gitlap 저장소 변경시 설정
$ git remote -v : gitlap 저장소 주소 확인
// 고아 브랜치 만드는 방법
$ git checkout master
$ git checkout --orphan c_YYMMDD_CAMPAIGNNAME
$ git rm -rf .
$ git push origin c_YYMMDD_CAMPAIGNNAME'Dev Environment > Git' 카테고리의 다른 글
| GitLab 소개 (SSH 생성) (0) | 2016.05.12 |
|---|---|
| Git 리모트 저장소 (0) | 2016.02.02 |
| Git branch(브랜치) (0) | 2016.02.02 |
| Git 개념 (0) | 2015.06.15 |
| VCS & Git/Github (0) | 2015.03.04 |
