본문 바로가기

분류 전체보기99

Git - 3.5 브랜치 Rebase 하기 Git에서 한 브랜치에서 다른 브랜치로 합치는 방법으로는 두 가지가 있다. 하나는 Merge 이고 다른 하나는 Rebase 다. 기존 브랜치에서 작업한 내용을 패치로 저장소에 적용하여 새로운 커밋을 만든다. Rebase 의 위험성 Rebase가 장점이 많은 기능이지만 단점이 없는 것은 아니니 조심해야 한다. 그 주의사항은 아래 한 문장으로 표현할 수 있다. 이미 공개 저장소에 Push 한 커밋을 Rebase 하지 마라 로컬 브랜치에서 작업할 때는 히스토리를 정리하기 위해서 Rebase 할 수도 있지만, 리모트 등 어딘가에 Push로 내보낸 커밋에 대해서는 절대 Rebase 하지 말아야 한다. 위 내용은 아래 사이트에서 읽은 후 정리하였습니다. https://git-scm.com/book/ko/v2 2020. 7. 5.
Git - 3.4 리모트 브랜치 리모트 브랜치를 통하여 수정 후 서버 저장소로 추가 리모트 트래킹 브랜치의 이름은 / 형식으로 되어 있다. 예를 들어 리모트 저장소 origin 의 master 브랜치를 보고 싶다면 origin/master 라는 이름으로 브랜치를 확인하면 된다. Push 하기 로컬의 브랜치를 서버로 전송하려면 쓰기 권한이 있는 리모트 저장소에 Push 해야 한다. 로컬 저장소의 브랜치는 자동으로 리모트 저장소로 전송되지 않는다. 명시적으로 브랜치를 Push 해야 정보가 전송된다. 따라서 리모트 저장소에 전송하지 않고 로컬 브랜치에만 두는 비공개 브랜치를 만들 수 있다. 또 다른 사람과 협업하기 위해 토픽 브랜치만 전송할 수도 있다. serverfix 라는 브랜치를 다른 사람과 공유할 때도 브랜치를 처음 Push 하는 것.. 2020. 7. 5.
Git - 3.3 브랜치 - 브랜치 워크플로 Long-Running 브랜치 Git은 꼼꼼하게 3-way Merge를 사용하기 때문에 장기간에 걸쳐서 한 브랜치를 다른 브랜치와 여러 번 Merge 하는 것이 쉬운 편이다. 그래서 개발 과정에서 필요한 용도에 따라 브랜치를 만들어 두고 계속 사용할 수 있다. 그리고 정기적으로 브랜치를 다른 브랜치로 Merge 한다. 이런 접근법에 따라서 Git 개발자가 많이 선호하는 워크플로가 하나 있다. 배포했거나 배포할 코드만 master 브랜치에 Merge 해서 안정 버전의 코드만 master 브랜치에 둔다. 개발을 진행하고 안정화하는 브랜치는 develop 이나 next 라는 이름으로 추가로 만들어 사용한다. 이 브랜치는 언젠가 안정 상태가 되겠지만, 항상 안정 상태를 유지해야 하는 것이 아니다. 테스트를 거쳐.. 2020. 7. 4.
Git - 3.2 브랜치와 Merge의 기초 브랜치와 Merge의 기초 실제 개발과정에서 겪을 만한 예제를 하나 살펴보자. 브랜치와 Merge는 보통 이런 식으로 진행한다. 웹사이트가 있고 뭔가 작업을 진행하고 있다. 새로운 이슈를 처리할 새 Branch를 하나 생성한다. 새로 만든 Branch에서 작업을 진행한다. 이때 중요한 문제가 생겨서 그것을 해결하는 Hotfix를 먼저 만들어야 한다. 그러면 아래와 같이 할 수 있다. 새로운 이슈를 처리하기 이전의 운영(Production) 브랜치로 이동한다. Hotfix 브랜치를 새로 하나 생성한다. 수정한 Hotfix 테스트를 마치고 운영 브랜치로 Merge 한다. 다시 작업하던 브랜치로 옮겨가서 하던 일 진행한다. 브랜치의 기초 먼저 지금 작업하는 프로젝트에서 이전에 master 브랜치에 커밋을 몇 .. 2020. 7. 4.

티스토리툴바