'Tool/Git'에 해당하는 글 24건

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 checkout branch

Tool/Git 2017. 1. 5. 12:43

IntelliJ 에서 다른 작업자가 추가한 Remote Branch 를 처음 가져오려고 봤더니, 원격의 최신 branch 상태가 나타나지 않았다.

pull 메뉴에서는 최신 branch 가 나타났지만, 현재 로컬 branch 와 merge 하게 되서 최신 branch 가져오는 새로고침만 강타했는데,

branch 메뉴에서는 최신 Remote Branch 가 나타나지 않았다.


결국 현란한 구글링 후,

메뉴에서 [ VCS | Git | Fetch ] 로 Remote Branch 를 가져왔다. (git fetch)

fetch 는 저장소의 작업물을 로컬로 가져올뿐 merge 를 하지는 않는다.

fetch + merge = pull




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

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

Switch Accounts

Tool/Git 2016. 12. 10. 03:05

$ git push


remote: Permission to username1/repo.git denied to username2.

fatal: unable to access 'https://github.com/username1/repo.git/':

The requested URL returned error: 403



github 에 등록된 계정간 전환 불가.

해당 프로젝트의 git config 에 user.name / user.email 를 변경했는데도 자꾸 기존 username 으로 push 를 시도하는 이 퐝당한 순간.

검색하다가 ssh-key 를 생성하는 뻘짓까지 했지만 내가 원한 해답이 아니었던 이문제...


키체인 삭제로 해결!

해결법이 더 퐝당함...




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

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

git config

Tool/Git 2016. 2. 7. 06:56

Git 설치 후 약간의 환경 설정이 필요하다.

git config 도구로 설정 내용을 저장하는데 Git 프로젝트 별, 사용자 별, 전체 설정 이렇게 3가지 설정이 있다.


  1. .git/config
    Git 프로젝트 디렉토리에만 적용되는 설정이며, 3가지 설정 중 제일 우선시 된다. (--system 옵션)
  2. ~/.gitconfig
    특정 사용자에게 적용되는 설정이다. (--global)
  3. /etc/gitconfig
    모든 사용자와 모든 Git 프로젝트에 적용되는 설정이다.



사용자 정보 설정


Git 은 commit 할 때마다 환경 설정에 저장되어 있는 사용자 정보(이름, 이메일)가 사용되므로, 반드시 필요한 설정이다.


$ git config --global user.name "ggamzzak"
$ git config --global user.email test@test.com
cs



환경 설정 확인


$ git config --list
 
user.name=ggamzzak
user.email=test@gmail.com
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
remote.docker.url=https://github.com/ggamzzak/docker_ubuntu.git
remote.docker.fetch=+refs/heads/*:refs/remotes/docker/*
branch.master.remote=docker
branch.master.merge=refs/heads/master
cs




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

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