머리가 나뻐서 삽질 SAP(Study And Programming)

git merge와 git rebase의 차이점에 대해서 알아보고, 실무에서 어떻게 사용했는지 기록을 남긴다 지난글에 이어서 이번에는 git rebase에 대해서 정리해본다 git rebase 실습하기) git rebase 실습을 위해서 일일이 구성물을 만드는게 번거로운 작업이 될 수 있다 따라서 실습을 위해서 git 환경을 터미널로 빠르게 구성해보고 학습하기로 한다 지금 이 글을 작성하는 개발환경은 `MacOS Ventura 13.3.1` 에서 `git version 2.39.0` 으로 수행하였다. (2023.10) 다음의 git merge step1 ~ step6 까지를 드래그하여 터미널에 복사-붙여넣기 하여 실습을 위한 환경을 구축할 수 있다 step을 나눈 이유는 몽땅 드래그해서 붙여넣으면 터미널..

git merge와 git rebase의 차이점에 대해서 알아보고, 실무에서 어떻게 사용했는지 기록을 남긴다 intro) 먼저 내가 실무에서 사용했던 레퍼지토리의 구성은 다음과 같았다 가장 중요한 브랜치는 develop 이고, 이 develop 브랜치를 원본으로 각 3개의 브랜치를 만들어서 동시에 작업하게 되는 상황이다 - develop => feature(기능) - develop => hotfix(버그수정) - develop => refactor(코드개선) 그림으로 보면 다음과 같다 만약 git merge를 사용한 경우 대략 아래와 같은 구성이 될 것이다 위 그림을 보면 feature 브랜치에서, hotfix 브랜치를 병합하고 또 refactor 브랜치를 병합시킨다 이렇게 feature 브랜치에 모두 ..

한개의 Repository에서 여러개의 remotes를 포함하고 있을 때, 브랜치를 가져온 뒤 pull 하는 경우 "git refusing to merge unrelated histories" 이런 에러를 만난다면 다음의 case일 확률이 높다. 현재 상황 $ git remote origin tutorial2 여기에서 원격의 tutorial2/main 브랜치를 로컬로 가져와서 동기화($ git pull) 하고 싶다. git pull 하면 refusing 에러가 난다. 당연하다. 에러가 나는 이유? 조금만 생각하면 당연하다. *origin/master에서 분기 처리하여 만든($ git checkout -b main)브랜치는 "origin =/= tutorial2" 로 저장소가 다른 브랜치 이다. maste..

Merge Request by GitLab Merge Request(GitLab)를 통해서 작업내역 업로드 합니다. 승인자 혹은 협업하는 팀원이 코드리뷰를 통해 Master에 병합합니다. [ 작업자 ] 원본의 저장소에 Fork 하기 [ 작업자 ] Fork 된 저장소를 Clone, remote [ 작업자 ] branch 생성하기 [ 작업자 ] 실제 작업하기 (코딩, 문서 등) [ 작업자 ] 작업된 내역 업로드 하기 add, commit, push [ 작업자 ] GitLab - New Merge Request [ 승인자 ] GitLab - New Merge Request 확인하기 [ 승인자 ] 작업자에게 코멘트 남기고 Master 에 병합하기 [ 승인자 ] Master에 병합한것 취소 하기 [ 작업자 ] 승..

# remote 추가해서 쓰고있는 상황 git remote add origin https://mygit.git # remote를 한개 더 추가하면 git remote set-url --add origin https://newgit.git # 아래 처럼 remote 주소가 여러개 입력되어있다 git remote -v git remote set-url --delete origin https://mygit.git (fetch) git remote set-url --delete origin https://mygit.git (push) git remote set-url --delete origin https://newgit.git (push) # 특정 주소를 삭제 하고 싶다면 아래와 같이 삭제가 가능! git r..

새 repository를 만들때 ignore 또는 readme를 추가하고 바로 git pull origin master 를 하고 프로젝트를 시작한다면 문제가 없지만, 이미 진행중이던 프로젝트가 있는 경우 충돌이 발생한다. 에러 코드는 다음과 같다. ! [rejected] master -> master (non-fast-forward) error: failed to push some refs to 'https://github.com/?????/server-study.git' hint: Updates were rejected because the tip of your current branch is behind its remote counterpart. Integrate the remote changes (..

15. 브랜치 충돌 최소화 하기 - 브랜치를 한방에 master 통합하려 하지 말고 - 브랜치가 master, A, B, C, Z 가 있는경우 - 미리미리 A, B, C 에서 한 작업을 Z 에 동기화 했다가 - Z => master 통합하면 충돌 최소화 할 수 있다. 그림 : https://www.youtube.com/watch?v=UscVvA0eyaM

14. 브랜치 충돌 - 앞서 설명했던 충돌과 똑같은 맥락이다. - 브랜치 끼리 병합할 때, 똑같은 소스코드의 내용이 수정되어 있는 경우 어떤 소스가 우선권 있는지 모르므로 사용자에게 충돌을 알린다. 1. 브랜치 한개 더 추가 - anotherVer 라는 브랜치를 한개 더 추가한다. - 아래처럼 총 3개 master, ajax_use(이하 A), anotherVar(이하 B) 브랜치가 존재 하는 상황 2. anotherVer 브랜치에서 소스 수정 - B 브랜치에서 소스 수정한다. - 일부러 Anohter Branches 버전이라고 넣었다. 3. master에 B 병합해보자 - Merge anotherVer into current branch 선택 4. master 소스와 겹쳐서 에러난다. 5. 수동으로 소..

13. 브랜치 만들기 - 브랜치 : 코드를 통째로 복사하고 나서 원래 코드와는 상관없이 독립적 개발 진행할 수 있는 상황에서, 이렇게 독립적 개발하는 버전이 브랜치다. - 사실 다른 브랜치관점에서 보면 Master 브랜치도 특별하지 않다. 내부적으로 git init 명령으로 초기화 할 때 자동으로 이 Master 브랜치가 만들어 진 것일뿐. 1. 브랜치 만들기 - Git_Local 탭에서 > 상단의 Branch 클릭 - New Branch 팝업에서 아래와 같이 이름적고 Create Branch - 브랜치 생성됨을 확인 2. 소스코드 편집하고 Commit 까지 해보자 - 소스 내용에 일부러 Branches 문자를 넣었다. 3. 이제 Master에 브랜치 를 병합해보자 - 브랜치가 선택된 상태에서 ( 브랜치..

12. Conflict 충돌 - Git_Local : 소스 코드 7번째 줄 라인을 수정 => 커밋이후 원격으로 Push- Git_Clone : 소스 코드 7번째 줄 라인을 수정 => 커밋이후 원격에서 로컬로 Pull ( 결과 ) - Pull 하여 소스 병합할때 같은 소스 라인이 수정되었기 때문에 충돌이 일어난다. - 충돌 부분을 수동으로 해결한 다음 직접 Commit 해야한다. 1. 충돌 해석 - '======' 을 기준으로 > code : 병합하려는 대상 여기에서 직접 수동으로 소스 수정하고 저장해야한다. - 소스 수정이 끝났으면 Resolve conflicts > Mark Resolved 하여 해결했음을 알린다.