본문 바로가기

코딩해보니/Git60

[Git_35] 리베이스(rebase) - 이해하기(개념 잡기) 리베이스(rebase) Git에서 브랜치를 생성하고 병합하고, 그 과정에 충돌이 발생했을 때 해결하는 부분들을 학습했습니다. 우리는 브랜치를 다른 브랜치와 합칠 때 병합(merge)을 사용했었습니다. 그런데 Git에서 브랜치를 합치는 방법으로 리베이스(rebase)가 있습니다. 이 리베이스는 커밋의 배치를 조절해서 병합한 결과를 만들어 낸다고 할 수 있습니다. 리베이스(rebase) 이해하기 지난 시간에 리베이스(rebase)를 무작정 사용해 봤습니다. 그럼, 지금까지 실행해 본 리베이스를 되짚어 보겠습니다. 결과적으로 보더라도 리베이스라는 것은 베이스(base)가 되는 커밋을 재(re, 다시) 설정한다는 의미라고 이해할 수 있습니다. 리베이스(rebase) 실행 전의 커밋 이력이 다음과 같았습니다. 여.. 2023. 1. 24.
[Git_34] 리베이스(rebase) - 무작정 따라하기 리베이스(rebase) Git에서 브랜치를 생성하고 병합하고, 그 과정에 충돌이 발생했을 때 해결하는 부분들을 학습했습니다. 우리는 브랜치를 다른 브랜치와 합칠 때 병합(merge)을 사용했었습니다. 그런데 Git에서 브랜치를 합치는 방법으로 리베이스(rebase)가 있습니다. 이 리베이스는 커밋의 배치를 조절해서 병합한 결과를 만들어 낸다고 할 수 있습니다. 무작정 따라 해 보기 일단 무작정 리베이스를 한번 해보도록 하겠습니다. 다시 실습을 위해 master와 hotfix 브랜치를 commit 5 지점으로 되돌려서 다음의 상태로 만들었습니다. 현재 상태를 그림으로 나타내면 다음과 같습니다. 여기서 hotfix 브랜치에서 filea.html 파일을 수정해 한 번 커밋하고, master 브랜치에서 file.. 2023. 1. 17.
[Git_33] 충돌(Conflict) - 해결하기 충돌(Conflict) 해결하기 지난 포스팅에서 충돌이 발생하는 상황을 만들어 봤습니다. [Git_32] 충돌(Conflict) - 충돌이란? & 충돌 상황 만들기 개요(충돌 이란?) 지금까지 Git의 기본적인 사항은 대부분 확인을 해봤습니다. 하지만, 이 외에도 아직도 많은 기능들이 있습니다. 많은 기능들이라기보다 실제 우리가 협업을 하다 보면 발생할 wishlan.tistory.com 이렇듯 충돌이 발생하면 결국 직접 코드를 보고 hotfix에서 수정한 개발자와 master에서 수정한 개발자가 함께 살펴보면서 수동으로 해결해야 합니다. 충돌이 발생한 파일을 열어보면 충돌이 발생한 지점에 Git은 충돌된 코드의 내용을 기호를 포함해 표시해 주고 있습니다. 충돌이 발생한 fileb.html을 열어보면 다.. 2023. 1. 15.
[Git_32] 충돌(Conflict) - 충돌이란? & 충돌 상황 만들기 개요(충돌 이란?) 지금까지 Git의 기본적인 사항은 대부분 확인을 해봤습니다. 하지만, 이 외에도 아직도 많은 기능들이 있습니다. 많은 기능들이라기보다 실제 우리가 협업을 하다 보면 발생할 수 있는 상황들이 다양합니다. 아직도 많은 기능들이 있다는 것은 어찌 보면 우리가 겪을 수 있는 다양한 상황을 해결하기 위해 필요한 것들이라 할 수 있습니다. 우리가 겪을 수 있는 다양한 상황들 중에 대표적인 것이 충돌(Conflict)이 발생하는 경우라 할 수 있겠습니다. 대부분의 충돌은 같은 소스의 같은 위치를 수정한 것이 그 원인인 경우가 많습니다. 앞서 병합(merge)를 실행했을 때도 병합을 문제없이 실행된 결과를 보기 위해서 이러한 경우가 발생하지 않도록 했기에 정상적으로 병합이 잘 이뤄졌습니다. 하지만,.. 2023. 1. 14.
[Git_31] 브랜치(Branch) 삭제, 이름변경 그리고 ... 브랜치(Branch) 삭제 브랜치를 병합한 후에는 병합한 브랜치를 일반적으로 삭제합니다. 앞서도 보셨지만 master도 수정되었는데, 3-way방식으로 병합 후에는 testbranch1에는 master가 수정한 사항은 반영이 되어 있지 않습니다. 그래서 추후 혼선을 없애기 위해서 병합한 후에 브랜치는 삭제하는 것이 일반적입니다. 삭제 후 필요하다면 다시 브랜치를 생성하는 것이 낫습니다. 브랜치 삭제 방법은 branch 명령어에 -d 옵션을 사용합니다. 사용법은 다음과 같습니다. # 브랜치 삭제하기 $ git branch -d 브랜치를 삭제해 보겠습니다. $ git branch -d testbranch1을 실행한 결과는 다음과 같습니다. 정상적으로 삭제되었다면 “Deleted branch testbranc.. 2023. 1. 10.
[Git_30] 브랜치(Branch) 병합(Merge) 브랜치(Branch) 병합(Merge) 브랜치를 사용하는 것은 안정적인 코드에 영향을 주지 않고 분리해 개발을 하기 위해서입니다. 버전 관리 시스템을 어떻게 운용하느냐에 따라 목적이 다를 수 있겠지만, 보통은 다음과 같이 운용합니다. master 브랜치엔 안정된 버전의 소스를 둡니다. 안정된 버전의 소스라는 것은 실제 서비스에 적용되어 있는 버전과 동일한 버전의 소스를 얘기합니다. 그래서 실제 서비스에 배포했거나 배포할 코드만 master 브랜치에 둡니다. 그리고 추가 작업들은 브랜치를 만들어서 진행하고, 테스트까지 완료되면, master와 합치게 됩니다. master와 합친 후 최종 테스트를 거쳐서 실제 서비스에 적용하게 됩니다. 이렇게 생성한 브랜치를 다른 브랜치와 합치는 작업을 병합이라고 합니다. .. 2023. 1. 4.
[Git_29] 브랜치(Branch)와 커밋(Commit) 브랜치(Branch)와 커밋(Commit) 앞서 testbranch1에서 filea.html 파일을 수정했습니다. [Git_28] 브랜치(Branch) 이동(checkout) 브랜치(Branch) 이동(checkout) 브랜치는 작업자라고 생각하면 이해가 쉬울 것이라 얘기했습니다. 나는 어느 작업자(브랜치)를 컨트롤할 것인지 정해야 합니다. 동시에 두 개 이상의 작업자(브랜치) wishlan.tistory.com 이어서 testbranch1에서 커밋을 실행해 봅니다. 여섯 번째 커밋이 됩니다. 또, 이어서 한번더 filea.html을 수정하고 커밋해 보겠습니다. 일곱 번째 커밋이 됩니다. 일곱 번째 커밋을 실행하고, 커밋 이력을 확인한 결과가 다음과 같습니다. 현재 testbranch1 에서 filea... 2023. 1. 3.
[Git_28] 브랜치(Branch) 이동(checkout) 브랜치(Branch) 이동(checkout) 브랜치는 작업자라고 생각하면 이해가 쉬울 것이라 얘기했습니다. 나는 어느 작업자(브랜치)를 컨트롤할 것인지 정해야 합니다. 동시에 두 개 이상의 작업자(브랜치)를 컨트롤할 수 없습니다. 그렇기 때문에 자신이 어느 브랜치에서 작업을 하는지 확인을 해야 하고, 또 자신이 원하는 브랜치로 이동을 할 수 있습니다. 앞서 소스트리에서 브랜치를 만들 때, 이 옵션이 있었습니다. 이 옵션에 체크를 하고 생성했더니 브랜치가 만들어 지고, 바로 새로 만든 브랜치가 선택되었습니다. 이 옵션에서 “체크아웃” 이라는 용어를 사용했습니다. 바로 브랜치를 이동하는 명령어가 checkout입니다. 터미널에서 현재 작업중인 브랜치는 경로 뒤에 표시가 되어 바로 확인이 가능합니다. 이동하기.. 2022. 12. 28.
[Git_27] 브랜치(Branch) 만들기 브랜치(Branch) 만들기 브랜치는 작업자라고 생각하기로 하고, 브랜치는 개수에 제한 없이 만들 수 있습니다. 브랜치를 만들 때는 branch 명령어를 사용하며, 다음과 같은 형식을 가집니다. # 브랜치 만들기 $ git branch branch 명령어 뒤에 브랜치 이름을 입력합니다. 작업자에게 이름을 붙여주는 격입니다. 는 입력하지 않아도 됩니다. 는 만드는 브랜치에게 시작할 작업 지점을 지정해 주는 것입니다. 를 입력하지 않으면, 현재 HEAD 포인터가 적용되어 브랜치가 만들어집니다. 현재 실습을 통해 다섯 번의 커밋을 한 상태에서 커밋 ID를 포함해 브랜치와 저장소의 관계를 조금 더 들여다보면 다음과 같다고 할 수 있습니다. 현재는 master 브랜치만 존재하고, HEAD 포인터는 마지막 다섯번째.. 2022. 12. 27.
[Git_26] 브랜치(Branch) 개념 브랜치(Branch) 개념 버전관리 시스템들에는 브랜치라는 개념이 있습니다. 브랜치(branch)의 사전적 의미는 나뭇가지, 지사, 분점이라고 하는데, 마찬가지로 버전관리에서도 브랜치는 큰 나무에서 많은 가지들이 뻗어 나오는 것처럼 같은 프로젝트를 복사해서 독립적으로 작업이 가능하게 합니다. 이런 버전관리 시스템을 사용하지 않았을 때도 사실은 브랜치 작업을 했었다고 할 수 있습니다. 버전관리시스템 없이 개발하던 때에 새로운 기능을 추가하거나, 다른 시도를 해보기 위해 작업을 시작하기 전에 작업 폴더를 통째로 복사해서 이름을 바꿔서 작업을 했었는데, 이러한 행동이 어떻게 보면 브랜치 작업이라고 볼 수 있습니다. 하지만, 이렇게 매번 하다 보면, 프로젝트를 유지 관리하기가 매우 힘들어집니다. 나중에 코드를 .. 2022. 12. 26.
[Git_25] diff 명령어로 비교 확인하기 diff 명령어 이전 포스팅에서 git diff HEAD와 git diff에 대해 잠시 언급을 했습니다. diff 명령어는 커밋이나 브랜치 사이에 다른 점 또는 수정 이력을 비교해 볼 때 사용할 수 있습니다. 먼저 $ git diff 에 대해 알아보겠습니다. git diff는 워킹 디렉토리와 스테이지 간 차이를 확인하는 것이며 다음과 같이 사용합니다. # 워킹 디렉토리와 스테이지 비교 $ git diff 그림으로 나타내면 다음과 같다고 할 수 있습니다. 가령, filea.html 파일을 수정하고 스테이지에 올린 상태라면, 이 상태는 워킹 디렉토리와 스테이지에 있는 filea.html의 내용은 같아집니다. 이때, 다음과 같이 git diff를 해 보면 아무런 내용이 없습니다. 차이가 없기 때문입니다. 스테.. 2022. 12. 24.
[Git_24] 커밋 수정하기 --amend 옵션 사용하기 커밋(commit)과 관련해서 한 가지 더 알아보고자 합니다. 리셋(reset)과 리버트(revert)는 커밋 이력에 영향을 주면서 되돌렸습니다. 하지만 개발을 하다 보면 커밋을 너무 자주 하게 되면 불필요한 커밋 이력만 늘어나게 됩니다. 예를 들어, 개발을 진행하면서 파일 3개를 수정했고 완료 후 커밋을 진행했는데 파일 1개를 빼먹고 2개만 커밋했다면 어떻게 할 수 있을까요? 나머지 파일 1개를 추가로 커밋을 진행해도 됩니다. 하지만, 이럴 경우 불필요한 커밋 이력이 추가됩니다. 아니면, reset(리셋)으로 되돌린 다음 다시 커밋하는 방법도 있습니다. --amend 옵션으로 직전에 커밋한 내용 수정하기 이 외에 간단히 직전에 커밋한 정보에 파일 하나만 더 추가한 커밋으로 수정할 수 있습니다. 이렇게 .. 2022. 12. 23.