반응형

Git 을 사용하면서 pull 을 받을때 다른 브랜치를 pull 받는 경우가 있다.

예를 들어서 나는 현재 A 브랜치에서 작업을 하고 있다. 그런데 B 브랜치의 내용을 A 브랜치로 pull 을 받아야 한다. ( 왜 이렇게 사용하냐고 묻는 다면.. 어쩌다 보니 이렇게 사용하게 됐다..)

 

그래서 한가지 궁금한게 생겼다. 

다른 브랜치를 pull 받는것과 merge 하는것과 차이가 있을까???

그럼 한번 실험을 해보자.

- master 브랜치, dev01 브랜치 생성

먼저 위 그림을 보자. 위 상황은 다음과 같다.

 

1. master 브랜치에서 test1.md 파일 생성후 커밋

2. dev01 브랜치 생성

3. dev01 브랜치에서 test2.md 파일 생성

 

- dev02 브랜치 추가 , test3.md 파일 추가 

그럼 위와 같은 상태가 된다.

 

- dev01 브랜치로 돌아가서 test2.md 파일 수정

1. dev01 브랜치로 checkout

2. test1.md, test2.md 파일 수정

3. 커밋

 

- dev02 브랜치로 가서 dev01 브랜치 pull

dev02 브랜치에 있는 tet1.md 파일과 test2.md 파일은 변경이 되지 않은 상태이다.

여기에서 다음가 같이 명령어를 쓴다.

 

git pull . dev01

 

리모트 저장소에 push 된 상태라면 명령어는 다음과 같이 된다. (지금 화면에서는 내가 리모트 저장소에 push 를 안한 상태로 local 만 사용중이기 때문에 . 을 사용한다.)

 

git pull origin dev01

음??  merge 를 한다고 나오네??

저장을 하게 되면 Git graph 는 다음과 같이 나온다.

결과적으로 서로 다른 브랜치에서 pull을 하게 되면 merge 를 하는것과 동일하게 동작을 한다.

 

-  Merge 확인해보기

dev03 브랜치를 만들어서 dev01 로 merge 를 해보자.

dev03 브랜치에서 test4.md 파일을 만들고 커밋을 했다.

dev02 에서 merge 를 한다는 것이 dev01 에서 merge 를 해서  dev01 도 표현이 되었다.

위와 약간 차이가 있어서 다시 해보겠다.

 

위 사진은 다음과 같이 실험한 결과이다.

1. dev02 브랜치에서 test5.md 생성 후 커밋

2. dev03 브랜치 checkout

3. dev03 브랜치에서 test4.md 파일 수정 후 커밋

4. dev02 브랜치로 다시 checkout

5. dev02 브랜치에서 dev03브랜치 merge

 

결과적으로 아래 Merge branch 'dev01' into dev02 와 동일한 그래프가 나타난다.

내가 내린 결론은 현재 브랜치에서 다른 브랜치를 pull하게 되면 merge와 동일한 동작을 하게 된다 라는 것이다.

 

 

....  혹시 글을 읽고 잘못된 점이 있으면 댓글로 알려주세요. (제가 잘못 이해한것 일수도 있어서..)

 

728x90
반응형

'Development > Git' 카테고리의 다른 글

git cherry pick  (0) 2024.01.05
Git Contribute 절차  (0) 2021.12.10
github page 에 테마 설치  (0) 2020.10.20
github 에 page 만들기  (0) 2020.10.15
Git local, remote branch 삭제  (0) 2020.09.08
반응형

가끔 이런 경우가 있다.

 

1. master 브랜치에서 현재 소스 기준으로 tag 를 생성한다. 

 

git tag release-v1.0

 

2. 그리고 나서 다른 작업들이 쭉~~ 진행 된다. 그러다가 갑자기 release-v1.0 에 대한 버그가 발견되었다. 그럼 어떻게 하지?? 

 

master 브랜치에는 신규기능을 개발중이거나 다른 작업들이 진행중이어서 bug fix 를 반영하더래도 v1.0 하고는 소스가 다른데... 구글링을 해보니 다음과 같은 절차를 이야기 해주고 있다.

 

git checkout -b bugfix1 release-v1.0

 

이렇게 한 후 버그를 고치고 commit 을 한다. 

 

git tag release-v1.1

 

그리고 버그를 수정한 거에 대한 tag 를 다시 생성한다. 이렇게 하면 이제 release-v1.1 소스를 가지고 배포를 하면 된다. 

그리고 마지막으로 현재 수정한 bug 를 master 에도 반영한다.

 

git checkout master

git merge bugfix1

 

버전관리 하면서 알아두면 유용하게 사용할수 있을것 같다. 

 

참고url 

https://gist.github.com/adonaldson/1205902

 

Fixing a bug in a tagged release

Fixing a bug in a tagged release. GitHub Gist: instantly share code, notes, and snippets.

gist.github.com

 

728x90
반응형
반응형

명령어 절차를 매번 찾기 귀찮아서 이렇게 기록 놓기로 했다.


1. 먼저 Github에 새로운 Repository 하나를 생성한다.



2. 실제 repository에 올리고 싶은 프로젝트의 로컬 디렉토리로 이동해서 git init 명령어를 실행한다. 그리고 git status 를 실행하면 아래와 같이 나온다.



3. git add . 명령어를 실행한다. 



4. git commit -m "커밋 메세지" 를 실행한다.



5. 1번에서 만들어 놓았던 repository 의 주소를 복사한다.


6. git remote add origin 복사한 주소 를 실행한다.


7. git push -u origin master 를 실행한다. 그런 다음 아무 에러가 안나면 끝난다. 

그런데 이때 reject 가 나오는 경우가 있다. Git Repository 를 생성할때 ReadeME  파일을 생성하도록 하면 이미 commit 한 내용이 있기 때문에 pull 을 받으라고 나온다.



 그런데 막상 pull을 받으면 아래와 같이 메세지가 나온다.



이때에는 git pull origin master 라고 입력해주면 된다. 


그리고 또 혹~~ 시라도 아래와 같은 메세지가 나오는 경우가 있다.


fatal: refusing to merge unrelated histories


이 에러는 각각의 history를 가진 프로젝트를 병합 하려고 할때 나온다고 한다. 그럴 경우에는 아래와 같이 옵션을 추가해서 pull을 받아야 한다.


git pull origin <branch name> --allow-unrelated-histories


참고 사이트

https://help.github.com/articles/adding-an-existing-project-to-github-using-the-command-line/

https://hongjinseob.wordpress.com/2017/11/24/git-fatalrefusing-to-merge-unrelated-histories-%ED%95%B4%EA%B2%B0/

728x90
반응형

+ Recent posts