'checkout'에 해당하는 글 4건

git remote branch

Tool/Git 2017. 2. 3. 01:01

원격 저장소에 push 할 로컬 branch 가 아니라면 브랜치 생성이든 삭제든 아무래도 상관없다. 단지 로컬 저장소에서만 이루어 지는 작업이기 때문에.

하지만 브랜치를 협업 등의 이유로 팀원과 공유하려면 원격 저장소에 해당 브랜치를 push 하고 팀원들이 fetch 받아 브랜치를 연결(tracking) 하면 된다.



1. 원격 저장소로 브랜치 공유하기


기존의 커밋들을 push 한다고 해서 내가 만들어 놓은 branch 까지 자동으로 올라가지는 않는다.

원격 저장소에도 별도로 브랜치를 만들고 로컬 저장소 브랜치와 연결을 시켜줘야 한다.


iss53 이라는 로컬 브랜치가 있다면 다음 명령어로 간단히 원격 저장소(origin)에 push 할 수 있다.


$ git push origin iss53
cs


위 명령은 $ git push origin iss53:iss53 과 같다. 만약 원격 저장소의 브랜치 이름을 issue 로 바꾸려면 다음 명령을 사용한다.


$ git push origin iss53:issue
cs


이 명령으로 원격저장소에 issue 브랜치가 생성되었고 로컬 저장소의 iss53 브랜치와 연결되었다.



2. 원격 저장소에서 브랜치 가져오기


팀원이 원격 저장소에 올려놓은 브랜치를 가져오려면 fetch 나 pull 명령을 사용하면 된다.

하지만 fetch 명령을 실행한다고 해서 원격 저장소의 브랜치와 동일한 브랜치를 로컬에 생성하는 것은 아니다.

fetch 명령은 단지 원격 저장소의 브랜치 중 로컬과 연결되어 있지 않은 브랜치에 대한 포인터만 생성한다.

fetch 후에 로컬 브랜치를 하나 생성하고 원격 저장소의 브랜치와 연결만 해주면 된다.


방법은 다양하다.


$ git fetch origin
 * [new branch]      iss55    -> origin/iss55
$ git checkout iss55
cs


$ git checkout -b iss55 origin/iss55
cs


$ git checkout --track origin/iss55
cs


위 명령들은 모두 로컬에 생성된 iss55 브랜치가 origin/iss55 브랜치를 바라보는 동일한 동작을 한다.


만약 이미 생성해 놓은 브랜치와 origin/iss55 브랜치를 연결하고 싶다면 -u (--set-upstream-to) 옵션을 사용하여 연결한다.


$ git branch -u origin/iss55
cs



3. 브랜치 삭제


iss55 브랜치 작업을 끝내고 다른 브랜치와 merge 하고, 더 이상 iss55 브랜치를 사용하지 않는다면 삭제를 해도 된다.


- 로컬 브랜치 삭제


$ git branch -d iss55
cs


- 원격 브랜치 삭제


$ git push origin --delete iss55
cs




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

git branch & merge

Tool/Git 2017. 2. 2. 21:36

브랜치 작업을 하거나 충돌날 때마다 도움을 요청하는 중생들을 줄이고자, git 세미나를 준비하면서 정리한 내용들이다.


* 목표

- 쫄지말고 브랜치(branch) 사용하기.

- 충돌(conflict)이 나더라도 쫄지 않기.


(기본적인 push, pull 정도는 할 줄 안다는 가정하에 불필요한 내용은 생략한다.)



1. 우리는 이럴 때 branch 를 사용한다.


다음 케이스를 보자.

master 브랜치 하나만 가지고 있으면서 이 작업물로 운영서버에 배포를 한다.

이 프로젝트에 [기능] 추가 요청이 들어왔고 팀원들과 협업이 필요하다.

협업이 필요하기 때문에 원격 저장소에 소스를 공유해야 한다.

기능 추가 작업중에 심각한 [버그] 를 발견하여 수정하고 다시 배포를 해야 한다면, 아직 완료되지 않은 [기능] 추가 작업이 같이 배포되어 버린다.

이를 방지하기 위해 필요한 것이 바로 branch 이다.


2. branch 란?


현재 브랜치(예를 들어 master) 에서 해오던 작업은 branch 를 추가하는 순간 별도의 공간에서 추가적으로 개발할 수 있다.

branch 는 이름 그대로 나뭇가지 처럼 작업을 분리시키는 것이다.

master iss53 이라는 브랜치가 있다면 master 에서 작업하는 내용은 iss53 에 영향을 미치지 않으며, iss53 에서 작업하는 내용 역시 master 에 영향을 미치지 않는다.


위 케이스에서 [기능] 추가 작업시 iss53 이라는 브랜치를 새로 생성해서 작업한다면,

또 [버그] 수정 역시 hotfix 라는 브랜치를 새로 생성해서 작업한다면, master 에서 bugfix 를 merge 하고 배포하면 끝이다.

다시 iss53 브랜치를 checkout 하여 [기능] 추가 작업을 계속 하면 된다.


3. merge 란?


branch 가 작업을 분리시키는 명령이라면, 반대로 분리한 작업을 다시 합쳐주는 명령이 바로 merge 이다.

우리는 이미 pull 을 수도 없이 사용하면서 자동 merge 를 사용해 왔다. (pull 명령은 fetch + merge 를 한번에 실행해 주는 명령이다.)

master 브랜치에서 git merge hotfix 명령으로 수정된 버그를 해결하고, git merge testing 명령으로 기능까지 추가한다면,

master 브랜치는 최신 상태의 소스가 되고 배포할 준비가 된다.


branch 와 merge 는 이게 끝이다.


이제 실제로 위 케이스를 실행해 보자.


최종적으로 위와 유사한 결과를 도출할 수 있어야 한다.


[기능] 추가 요청에 대한 iss53 이라는 브랜치 생성.


$ git checkout -b iss53
cs


위 명령은 아래 두개의 명령을 한번해 실행해 줌.


$ git branch iss53
$ git checkout iss53
cs


작업 및 커밋진행


$ git commit -m 'description'
cs


도중에 [버그] 수정 요청에 대한 hotfix 라는 브랜치 생성.

master 에 기반한 브랜치를 생성해야 하므로 master 브랜치를 이동하여 브랜치를 생성.


$ git checkout master
$ git checkout -b hotfix
cs


버그를 수정한 후 커밋을 진행.


$ git commit -m 'description'
cs


수정한 버그를 master 에 합치기 위해 master 브랜치로 이동하여 merge 실행


$ git checkout master
$ git merge hotfix
cs


master 브랜치는 hotfix 브랜치를 생성한 이후에 커밋을 진행하고 있지 않았으므로 단순히 브랜치 포인터만 hotfix 의 최신 커밋으로 이동함. (fast-forward 방식)

다시 iss53 으로 이동하여 [기능] 추가 작업 마무리 하고 커밋하고 master 와 합치기 위해 merge 실행.


$ git checkout iss53
$ git commit -m 'description'
$ git checkout master
$ git merge iss53
cs


master 브랜치는 iss53 브랜치를 생성한(조상) 이후에 커밋이 진행되었으므로 그림처럼 두개의 브랜치가 합쳐지는 3-way merge 처리.

3-way merge 의 결과로 별도의 커밋이 만들어진다.


추가적으로 브랜치를 변경할 때는 기존의 staged 를 깨끗하게 정리하는 것이 좋다. 

commit 이나 staged 를 사용하여 충돌을 체크 및 예방한다.




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

git branch

Tool/Git 2013. 3. 23. 00:30

master branch 에서 HEAD 상태에 놓은 작업물들을 원격 저장소에 적용하기 전에,
branch 란 것에 대해서 조금 더 알아보겠습니다.

 

지금까지는 첫번째 commit 후에 master branch가 생성되었고, 현재도 master에서 작업 중입니다.
이 쯤에서 기존의 파일을 디버깅한다던지, 기능을 추가한다던지 하는 이슈가 생겼을 때,
현재 작업해 놓은 master 에서 가지(branch)를 쳐서 새로운 branch를 생성하여,
기존 master는 보존하고, 새로운 branch에서 이슈를 해결할 수 있습니다.
이렇게 한 개 이상의 branch가 생성되었을 때 각각의 branch에서 독립적으로 작업을 진행할 수 있으며,
작업을 완료하고 나서는 새로 생성한 branch와 master를 병합(merge)할 수 있습니다.

 

 

 

git branch 명령은 현재 보유중인 branch 들을 모두 출력하며,
현재 작업 중인 branch를 (*) 마크로 표시합니다.
새로운 branch를 생성하려면 git branch <new branch> 라고 명령합니다.

 

지금까지 작업한 master에서 commit 로그를 살펴보겠습니다.

 

$ git branch
* master
$ git log
commit 3e9f5ffc4fea440b2f23830e395797a5c571a99b
Author: ggamzzak <ggamzzak@test.com>
Date:   Tue Mar 19 11:15:12 2013 +0900

 

    modify file1 2nd

 

commit 449512a3e4e10093e0631af0733b493147c3eee2
Author: ggamzzak <ggamzzak@test.com>
Date:   Tue Mar 19 11:09:09 2013 +0900

 

    modify file1

 

commit 28713cea1fe5722c24caaa605e6810caf094d955
Author: ggamzzak <ggamzzak@test.com>
Date:   Tue Mar 19 10:35:55 2013 +0900

 

    first file added

 

 

이번에는 testing 이란 새로운 branch를 만들고,
포인트 개념의 HEAD가 testing 을 가리키도록 checkout 명령을 사용합니다.

git branch B, git checkout B 의 명령을 -b(branch) 옵션을 사용하여 git checkout -b B 라고 한번에 명령할 수 있습니다.
병합 후 필요없는 branch는 -d(delete) 옵션으로 삭제합니다. git branch -d B

 

$ git branch testing
$ git branch
* master
  testing

$ git checkout testing
Switched to branch 'testing'
$ git branch
  master
* testing

$ git log
commit 3e9f5ffc4fea440b2f23830e395797a5c571a99b
Author: ggamzzak <ggamzzak@test.com>
Date:   Tue Mar 19 11:15:12 2013 +0900

 

    modify file1 2nd

 

commit 449512a3e4e10093e0631af0733b493147c3eee2
Author: ggamzzak <ggamzzak@test.com>
Date:   Tue Mar 19 11:09:09 2013 +0900

 

    modify file1

 

commit 28713cea1fe5722c24caaa605e6810caf094d955
Author: ggamzzak <ggamzzak@test.com>
Date:   Tue Mar 19 10:35:55 2013 +0900

 

    first file added

 

(*)은 현재 작업 중인 branch라고 했습니다.
checkout 명령으로 작업 중인 branch를 변경할 수 있었습니다.
새로 생성된 testing의 log를 보면 master의 commit 히스토리가 그대로 복제되었습니다.
이제 이 두 branch는 독립적으로 작업할 수 있습니다.
master에서 commit을 해도 testing에 적용되지 않으며,
testing에서 commit을 해도 master에는 적용되지 않습니다.

 

이렇게 testing 에서 이슈를 완료하면 merge 명령을 사용하여 master와 병합하고,
필요에 따라 testing 을 삭제하면 됩니다.

 

 

 

위의 예와 비슷한 그림입니다.
master 브런치에서 세번의 commit을 실행했고,
testing 브런치를 생성한 뒤에 testing 브런치에서 한번의 commit 을 실행한 것을 나타낸 그림입니다.

 

checkout 명령을 사용해서 branch 간 이동할 때 유의할 점은, 커밋 직전(Staged)의 파일이 이동할 branch 파일과 충돌한다면 branch를 변경할 수 없습니다. 브랜치를 변경할 때에는 status로 확인하여 Working Directory를 정리하는 것이 좋습니다.

 

$ git checkout master
error: Your local changes to the following files would be overwritten by checkout:
        file1.txt
Please, commit your changes or stash them before you can switch branches.
Aborting


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

git add

Tool/Git 2013. 3. 21. 00:10

3. add 후의 status

 

$ git add file1.txt
$ git branch
$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#       new file:   file1.txt
#

 

Working directory -> Staging area -> HEAD 로 가는 세가지 단계에서 위의 file1.txt 파일은,
add 이전은 Working directory,
add 이후는 Staging area에 놓이게 됩니다.
Staging area에 놓인 작업물들은 commit시에 HEAD로 전달됩니다.
commit 시에 전달되서는 안되는 작업물이 Staging area에 포함되어 있다면
git rm --cached <file>... 명령으로 unstage 상태로 되돌릴 수 있습니다.

 

$ git rm --cached file1.txt
rm 'file1.txt'

 

 

만약 add 명령으로 Staging area에 놓인 파일을 git이 알 수 없는 일반 rm 명령으로 삭제 시켜버렸다면 commit시에 에러가 발생할 것입니다. Staging area에서 commit 대기하던 작업물이 사라졌으니까요.
그 상황을 만나게 된다면 우리는 삭제된 파일을 살리던지(checkout), Staging area에서도 삭제를 시키던지 해야 합니다.

 

$ git add file1.txt
$ rm file1.txt
$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#       new file:   file1.txt
#
# Changes not staged for commit:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       deleted:    file1.txt
#

 

status를 보자면 add 명령으로 인해 file1.txt 파일이 commit 대기 중입니다.
그런데 git이 알 수 없는 rm 명령으로 file1.txt 파일이 삭제가 되었기 때문에 작업을 계속 하려면,
git이 인식할 수 있도록 죽이던지 살리던지 해야 합니다.
$ git rm --cached file1.txt
명령으로 file1.txt 파일을 Staging area 에서 삭제 시키던지,
$ git checkout -- file1.txt
명령으로 제거된 file1.txt 파일을 복구할 수 있습니다.


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret