이것은 .에 대한 소개입니다 git. 저는 이것을 처음에는 비코더를 위해 디자인했고, git의 기본을 더 배우고 싶어하는 모든 사람에게 유용하게 만들려고 노력했습니다. 우리는 모든 것을 로컬에서 할 것이므로, 따라오셔도 좋습니다.
이 소개를 통해 git을 어떻게 사용하는지, 그리고 GitHub 등에 어떻게 적용되는지 알 수 있기를 바랍니다.
대부분 명령줄을 사용하겠지만, 터미널을 사용하는 방법을 모르더라도 걱정하지 마세요. 명령을 기억하는 것이 아니라 git을 이해하는 것이 중요합니다. GitHub Desktop 과 같은 사용자 인터페이스를 통해 git을 사용하거나 코드 편집기용 플러그인을 사용할 수도 있습니다. 요즘은 VSCode에서 Xcode, PyCharm, Sublime까지 모든 것이 git 통합을 지원합니다.
Git 기본
git을 “SCM” 또는 소스 코드 관리 도구라고 설명하는 것을 볼 수 있습니다. git은 본질적으로 파일의 변경 사항을 추적하는 도구입니다. 대부분 이러한 파일은 텍스트이고, 이 텍스트는 “소스 코드”로 존재하는 경우가 많습니다. git은 이미지 및 실행 파일과 같은 바이너리 파일(텍스트 파일이 아님)을 포함하여 모든 파일 유형을 처리할 수도 있지만, 지금까지 가장 인기 있는 용도는 코드 관리입니다.
git은 텍스트 파일만 사용할 수 있기 때문에 예시로 영어를 사용하겠습니다. git은 특정 프로그래밍 언어에 관심이 없다는 것을 알 수 있을 겁니다. git이 신경 쓰는 건 텍스트와 변경 사항뿐입니다!
git 저장소 만들기
설치 해야 합니다 git. macOS를 사용하는 경우, 아마도 git이 이미 있을 것입니다. 하지만 아마도 오래된 버전일 것입니다. Linux 배포판에도 git이 포함되어 있을 수 있습니다.
설치 가 되었는지 알아보려면 git터미널에서 다음 명령을 사용하세요.
| 1 | $ git --version |
다음과 같은 답변이 나올 것입니다: git version 2.39.3 (Apple Git-146).
오류가 표시되면 git이 설치되지 않은 것입니다. 최신 버전을 확인하거나, 설치하거나, 업데이트하려면 git 공식 웹사이트 로 이동하세요 .
또한, 명령줄에서 git을 설치하거나 업데이트하는 데 사용할 수 있는 몇 가지 명령은 다음과 같습니다.
| 123 | $ brew install git # macOS$ sudo apt-get install git # Ubuntu$ winget install --id Git.Git -e --source winget # Windows |
Git 저장소 만들기
이미 설치 되었으므로 git이제 git 저장소를 만들 수 있습니다. 첫 번째 단계는 컴퓨터 어딘가에 디렉토리를 만들어 git을 가지고 놀 수 있도록 하는 것입니다. 원하는 대로 새 디렉토리를 만들 수 있습니다. 명령줄을 사용하여 다음 mkdir명령으로 만들 수 있습니다.
| 1 | $ mkdir git-training |
이제 해당 디렉토리로 들어가서 새로운 저장소를 만듭니다.
| 12 | $ cd git-training$ git init |
명령줄 인터페이스에서 git의 init명령을 사용하여 현재 디렉토리에 새 저장소를 만듭니다. 이 init명령은 디렉토리를 만듭니다 .git. 기본적으로 숨겨져 있으므로 파일 탐색기나 명령을 사용하더라도 표시되지 않을 가능성이 큽니다 ls. 하지만 다음과 같이 볼 수 있습니다.
| 1 | $ ls -a |
디렉토리 가 있는 것을 보실 수 있습니다 .git.
| 1 | . .. .git |
저장소는 그저 폴더가 있는 디렉토리일 뿐입니다 .git. 다양한 버전에 대한 모든 정보와 git이 작업하는 데 필요한 모든 것이 그 .git폴더 안에 저장됩니다.
해당 폴더를 삭제하면 git 저장소도 삭제됩니다. 예를 들어, 이제 다음을 수행할 수 있습니다.
| 1 | $ git status |
그러면 다음과 같은 내용이 표시됩니다.
| 12345 | On branch mainNo commits yetnothing to commit (create/copy files and use "git add" to track) |
이제 폴더를 삭제하면 .git:
| 1 | $ rm -rf .git |
다시 시도해 보세요:
| 1 | $ git status |
우리는 얻는다:
| 1 | fatal: not a git repository (or any of the parent directories): .git |
git 명령을 실행하면 git은 .git현재 디렉토리에서 디렉토리를 찾습니다. 디렉토리를 찾을 수 없으면 부모 디렉토리를 재귀적으로 시도하여 디렉토리를 찾을 때까지 시도합니다. .git디렉토리를 찾을 수 없으면 그렇게 불평합니다.
다음을 사용하여 저장소를 다시 만들 수 있습니다.
| 1 | $ git init |
파일 추적
기본적으로 git은 사용자가 지정하지 않는 한 아무것도 추적하지 않습니다. git에 파일을 추적하라고 지정하려면 add저장소에 파일을 추가해야 합니다. 그러면 git이 파일을 추적 하게 됩니다 . 추적된 파일이 변경되면 git이 알아차리고
변경 사항을 보고, 변경 사항을 추가하고 , 커밋 (저장)할 수 있습니다.
haiku.txt테스트할 새 파일을 만드는 것으로 시작해 보겠습니다. 다음 내용으로 이라는 새 파일을 만듭니다 .
| 1 | An old silent pond |
status변경된 내용을 보려면 다음 명령을 실행하세요 .
| 1 | $ git status |
우리는 이것을 봅니다:
| 123456789 | On branch mainNo commits yetUntracked files: (use "git add <file>..." to include in what will be committed) haiku.txtnothing added to commit but untracked files present (use "git add" to track) |
이 메시지는 꽤 도움이 됩니다. 우리는 아직 아무것도 추적하지 않지만, git은 추적되지 않은 파일이 있다는 것을 알아차리고 .을 사용하여 추가하라고 제안합니다 git add. 우리는 그렇게 할 것입니다:
| 1 | $ git add haiku.txt |
대부분의 경우 커밋에 변경한 모든 내용을 추가하고 싶을 것이고, 여러 파일을 변경한 경우 모든 파일 이름을 하나씩 입력하는 것은 성가실 수 있습니다. 그런 다음 다음을 수행하면 됩니다.
| 1 | $ git add . |
현재 디렉토리(하위 디렉토리 포함)에 있는 모든 파일을 추가합니다. git status지금 실행하면 다른 출력이 나옵니다.
| 1234567 | On branch mainNo commits yetChanges to be committed: (use "git rm --cached <file>..." to unstage) new file: haiku.txt |
“커밋할 변경 사항” 아래에서 haiku.txt새 파일로 인식되는 것을 볼 수 있습니다. 이제 다음 commit명령으로 이러한 변경 사항을 커밋할 수 있습니다.
| 1 | $ git commit -m "Initial commit" |
이제 를 실행하면 다음 git status과 같습니다.
| 12 | On branch mainnothing to commit, working tree clean |
즉, 마지막 커밋 이후로 새로운 변경 사항이 없으므로 모든 것이 괜찮아 보입니다!
git 사용자 구성
모든 커밋에는 작성자가 있으므로 지금 작성자 정보를 구성하지 않으면 git이 커밋을 만들 수 없고 대신 실패합니다.
다음과 같은 오류가 표시됩니다.
| 12345678910 | fatal: could not read username from git configfatal: could not read email address from git configYour name and email address are not set up.You can set them using: git config --global user.name "Your Name" git config --global user.email "your_email@example.com"Please set up the user by running the above commands.Aborting commit due to missing author information. |
해당 지침에 따라 사용자 이름과 이메일을 구성한 다음 commit다시 시도해 보세요.
추적된 파일에 변경 사항 적용
이제 추적된 파일이 있으니 변경해 보겠습니다. 텍스트를 다음과 같이 변경해 보겠습니다.
| 12 | An old silent pondA frog jumps into the pond - |
haiku.txt해당 변경 사항을 파일 에 저장하면 git status다음과 같은 내용이 표시됩니다.
| 12345 | On branch mainChanges not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: haiku.txt |
우리가 수정한 것을 알아차렸지만 “변경 사항이 커밋을 위해 준비되지 않았습니다”라고 합니다. 우리는 git에 그 변경 사항을 준비 영역haiku.txt 에 추가하고 싶다고 말해야 합니다 .
git에서 작업 디렉토리는 컴퓨터에 있는 실제 폴더이며, 이 경우에는 .git디렉토리가 들어 있는 폴더입니다 git-training.
반면, 스테이징 영역은 작업 디렉토리의 어떤 특정 변경 사항 중에서 다음 커밋에 포함할지 선택하는 임시 영역입니다.
작업 디렉토리에 있는 모든 변경 사항을 단일 커밋에 포함 하지 않는 것이 일반적입니다 . 변경 file1.txt하고 file2.txt변경 사항을 하나 대신 두 개의 별도 커밋으로 추적하고 싶을 수도 있습니다.
다음 명령을 사용하면 diff마지막 커밋 이후 변경된 내용을 확인할 수도 있습니다.
| 1234567 | diff --git a/haiku.txt b/haiku.txtindex 73efcca..ad5f3cd 100644--- a/haiku.txt+++ b/haiku.txt@@ -1 +1,2 @@ An old silent pond+A frog jumps into the pond - |
출력은 약간 간결하지만 -줄 앞에 는 해당 줄이 삭제되었음을 의미하고 는 +해당 줄이 추가되었음을 의미합니다. 이 경우, 파일 끝에 줄을 추가했습니다. 모드에 있을 때 를 눌러 터미널로 돌아갈 diff수 있습니다 .q
git status및 명령을 자주 실행하는 것이 좋습니다 git diff. 이를 통해 저장소를 살펴볼 수 있으며 안전하고 파괴적이지 않은 작업입니다.
스테이징 영역에 파일에 적용한 변경 사항을 포함하려면 다음 명령을 사용하여 다음 커밋에 반영할 수 있습니다 add.
| 1 | $ git add . |
이제 다음 명령을 실행하면 status:
| 1 | $ git status |
우리는 얻는다:
| 1234 | On branch mainChanges to be committed: (use "git restore --staged <file>..." to unstage) modified: haiku.txt |
변경 사항을 언스테이징 (스테이징 영역에서 제거) 하고 싶다면 , 를 할 수 있습니다 git restore --staged haiku.txt. 하지만 이 경우에는 하지 않을 겁니다 🙂
다음 명령 으로 변경 사항을 커밋합니다 commit.
| 1 | $ git commit -m "Added second line" |
옵션을 주목하세요 -m. 커밋에 사용할 메시지입니다. 짧은 메시지여야 하며, 변경 사항을 설명하는 한 줄이어야 합니다.
원하면 여러 줄을 사용할 수 있지만, 이 -m옵션은 짧은 메시지를 위한 것입니다. -m옵션을 통과하지 않으면 git은 대신 기본 텍스트 편집기(대부분의 경우 vim 또는 nano)를 열고 커밋 메시지와 함께 파일을 저장할 때까지 기다립니다. 이렇게 하면 한 줄이 아니라 여러 줄을 쓸 수 있습니다.
역사 조사
지금까지 두 개의 커밋이 있었고, 다음 명령을 사용하여 버전 기록을 살펴볼 수 있습니다 log.
| 1 | $ git log |
제 생각에는 다음과 같습니다.
| 1234567891011 | commit 8dfa4b45a0b1413578287543d16e8c937ed93af9 (HEAD -> main)Author: Federico Ramirez <federico_r@beezwax.net>Date: Wed Apr 24 14:14:36 2024 -0700 Added second linecommit b07ea31670a86b892e895e1ec44d5c1a627523d7Author: Federico Ramirez <federico_r@beezwax.net>Date: Wed Apr 24 14:02:19 2024 -0700 Initial commit |
모든 커밋 목록이 표시되며, 가장 최신 커밋이 맨 위에 표시됩니다.
각 커밋에는 해시가 있습니다 . 해시는 특정 커밋을 나타내는 고유한 문자열이며 다음과 같습니다 8dfa4b45a0b1413578287543d16e8c937ed93af9.
해시는 매우 중요하며 필요할 때마다 특정 커밋을 참조하는 데 사용할 수 있습니다. 이 log명령은 작성자, 날짜 및 커밋 메시지도 제공합니다.
이 명령을 사용하면 커밋에 대한 자세한 내용을 볼 수 있습니다 show. 컴퓨터에서 단계를 반복하는 경우 저와 다른 커밋 해시가 있습니다. show명령을 사용하여 최신 커밋에 대한 자세한 정보를 확인해 보세요. 제 경우에는 다음 명령을 실행해야 합니다.
| 1 | $ git show 8dfa4b45a0b1413578287543d16e8c937ed93af9 |
내가 보는 것은 다음과 같습니다.
| 12345678910111213 | commit 8dfa4b45a0b1413578287543d16e8c937ed93af9 (HEAD -> main)Author: Federico Ramirez <federico_r@beezwax.net>Date: Wed Apr 24 14:14:36 2024 -0700 Added second linediff --git a/haiku.txt b/haiku.txtindex 73efcca..ad5f3cd 100644--- a/haiku.txt+++ b/haiku.txt@@ -1 +1,2 @@ An old silent pond+A frog jumps into the pond - |
그래서 우리는 명령에서 얻은 정보 log와 diff해당 커밋에 대한 정보를 동일하게 얻습니다.
역사 탐색
추적된 파일을 검사하는 것 외에도, 우리는 실제로 그것들을 역사의 어느 지점에서나 정확히 보이도록 만들 수 있습니다. 무언가가 망가졌을 때를 대비해 효과적으로 이전 버전을 복원합니다.
탐색이 어떻게 작동하는지 이해하기 위해 먼저 git의 HEAD 개념에 대해 조금 이야기해 보겠습니다 . 이는 지나치게 단순화한 것이지만, HEAD를 현재 보고 있는 브랜치나 커밋을 보관하는 참조로 생각할 수 있습니다. “여기에 있습니다” 화살표와 같습니다.
logGit은 명령을 사용할 때 HEAD를 사용하여 시작할 커밋이나 새 커밋의 부모가 무엇인지 등을 파악합니다 commit.
이를 설명하기 위해 지금까지의 커밋 기록을 살펴보겠습니다.
대부분의 경우 HEAD는 현재 브랜치의 최신 커밋을 가리킵니다. 커밋 해시를 과로 단순화하여 A더 B명확하게 만들었습니다.
히스토리에서 탐색하려면 HEAD를 탐색하려는 커밋(또는 브랜치)으로 이동해야 합니다. 이 경우 HEAD를 .으로 이동하려고 합니다 A. 다음 명령으로 수행할 수 있습니다 checkout.
| 1 | $ git checkout b07ea31670a86b892e895e1ec44d5c1a627523d7 |
b07ea31670a86b892e895e1ec44d5c1a627523d7를 나타낸다고 가정할 수 있습니다 A.
다음과 같은 출력이 표시됩니다.
| 123456789101112131415 | Note: switching to 'b07ea31670a86b892e895e1ec44d5c1a627523d7'.You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by switching back to a branch.If you want to create a new branch to retain commits you create, you may do so (now or later) by using -c with the switch command. Example: git switch -c <new-branch-name>Or undo this operation with: git switch -Turn off this advice by setting config variable advice.detachedHead to falseHEAD is now at b07ea31 Initial commit |
지금은 분리된 HEAD 에 대해 걱정하지 마세요 . 브랜치에 대해 이야기할 때 다시 이야기하겠습니다. 지금은 괜찮다는 것만 알아두세요. 아무것도 망가지지 않았고, 이게 제대로 작동하는 방식입니다. Git은 UX로 유명하지 않습니다!
를 사용하여 기록을 탐색할 때 checkoutgit은 현재 디렉토리의 추적된 파일을 해당 커밋의 파일 버전과 동기화합니다.
haiku.txt이것이 정말 작동하는지 확인하기 위해 파일을 살펴보겠습니다 .
| 1 | An old silent pond |
실제로 두 번째 줄을 제거했기 때문에 이전 버전과 같습니다. 이것은 매우 유용한데, 문제가 생기면 작동하는 버전을 찾을 때까지 항상 기록으로 돌아갈 수 있기 때문입니다!
그래서 저는 커밋을 “체크포인트”라고 생각하는 것을 좋아합니다. 항상 작업 상태로, 비교적 작게 두는 것이 좋습니다.
최신 커밋으로 돌아가려면 다음을 실행해 보겠습니다.
| 1 | $ git checkout main |
그리고 우리는 브랜치의 최신 커밋으로 돌아왔는데 main, 이는 git이 우리를 위해 만든 기본 브랜치입니다.
분기
브랜치는 새로운 커밋을 만들고, 작업을 하고, 변경 사항을 기본 브랜치에 다시 병합하는 데 사용할 수 있는 샌드박스라고 생각할 수 있습니다. 이것은 특히 다음과 같은 경우에 유용합니다.
main개발하는 동안 가지가 부러지는 위험을 감수하지 마십시오.
여러 사람이 동시에 파일을 작업할 때에도 작업을 중단하지 않고 다른 사람들과 협업할 수 있습니다.
새로운 브랜치를 만들고 이름을 .으로 지정해 보겠습니다 my-new-branch. 관례에 따라 브랜치 이름은 케밥 케이스 형식을 사용합니다 .
| 1 | $ git checkout -b my-new-branch |
-b옵션을 전달하면 checkout새 브랜치의 이름을 지정할 수 있으며 현재 HEAD를 기반으로 해당 브랜치를 생성하고, HEAD가 이 새 브랜치를 가리키도록 하여 해당 브랜치로 전환합니다.
지금 그렇게 하면 git status다음과 같은 결과를 얻게 됩니다.
| 12 | On branch my-new-branchnothing to commit, working tree clean |
우리는 여전히 최신 커밋을 보고 있지만, 에 있는 대신 main, 이제 에 있습니다 my-new-branch. 여기가 우리의 샌드박스이고, 여기서 우리는 새로운 커밋을 만들고, 필요한 모든 변경을 할 수 있으며, 심지어 이 브랜치를 버릴 수도 있고, 에 아무 일도 일어나지 않을 것입니다 main.
새로운 줄을 추가해 보겠습니다 haiku.txt.
| 123 | An old silent pondA frog jumps into the pond -The sound of water. |
커밋을 만드는 과정은 지금까지 해온 것과 같습니다.
| 1 | $ git add . |
커밋을 실행하기 전에 항상 상태를 확인하는 것이 좋습니다.
| 1 | $ git status |
우리는 얻는다:
| 1234 | On branch my-new-branchChanges to be committed: (use "git restore --staged <file>..." to unstage) modified: haiku.txt |
좋아 보이네요. 하지만 이 커밋에 무엇이 추가될지 보고 싶다면요? 이 diff명령은 작업 디렉토리와 이전 커밋 사이의 변경 사항만 알려주지만, 스테이징 영역에 변경 사항을 추가하면 더 이상 diff에 표시되지 않습니다.
| 1 | $ git diff |
비어 있습니다. 이를 위해 다음 --cached플래그를 사용할 수 있습니다.
| 1 | $ git diff --cached |
이제 우리는 그것을 봅니다:
| 12345678 | diff --git a/haiku.txt b/haiku.txtindex ad5f3cd..f1ea5b9 100644--- a/haiku.txt+++ b/haiku.txt@@ -1,2 +1,3 @@ An old silent pond A frog jumps into the pond -+The sound of water. |
좋습니다! 이제 다음을 커밋할 수 있습니다.
| 1 | $ git commit -m "Add third line" |
지금 실행하면 git status모든 것이 정상이라고 보고됩니다.
| 12 | On branch my-new-branchnothing to commit, working tree clean |
지금까지 우리의 역사는 다음과 같습니다.
병합
작업을 마친 후에는 해당 변경 사항을 다시 브랜치에 병합하고 싶습니다 main.
병합할 때 git은 현재 브랜치의 최신 커밋( my-new-branch)과 병합하려는 브랜치의 최신 커밋( main)을 가져와 새 커밋을 만들고 변경 사항을 자동으로 조정합니다.
우리는 명령어로 병합할 수 있습니다 merge. 그 명령어는 당신이 명령한 모든 브랜치를 당신의 현재 브랜치로 병합할 것입니다 .
my-new-branch따라서, 우리가 에 병합하고 싶다면 main다음과 같이 해야 합니다 main:
| 12 | $ git checkout main # make sure we are in the main branch$ git merge my-new-branch # merge `my-new-branch` in |
두 개의 커밋을 병합할 때 git은 일반적으로 새 커밋을 생성하여 커밋 기록이 다음과 같이 표시됩니다.
그럴 경우, 기본 텍스트 편집기를 열고 커밋 메시지를 기다립니다. 대부분의 경우 기본 메시지는 괜찮고, 파일을 저장하고 편집기를 종료하면 됩니다.
기본 편집기를 변경하려면 다음 명령을 사용하면 됩니다.
| 1 | $ git config --global core.editor "your_editor" |
VSCode를 사용하신다면, "code"거기에서 사용 가능합니다.
하지만 이 경우 git notice가 B의 부모이기 때문에 CHEAD를 그에 맞게 이동하고 새 커밋을 생성하지 않아도 될 만큼 똑똑합니다.
그걸 git-land에서는 “패스트 포워드” 전략이라고 부르죠.
병합 충돌 수정
때로는 두 개의 브랜치에서 같은 파일의 같은 줄을 변경할 때, git에서는 병합할 때 어느 것을 사용해야 할지 알 수 없는 경우가 있습니다.
어떤 라인을 선택해야 하는지 알려줘야 하며, 모든 충돌을 해결할 때까지 병합을 거부합니다.
충돌을 만들어서 어떻게 보이는지, 어떻게 처리할지 살펴보겠습니다. 두 개의 브랜치, 와 를 만들 것입니다. alice이는 bob두 사람이 동시에 같은 파일을 변경하는 것을 나타냅니다.
| 1 | $ git checkout -b alice |
-b새로운 브랜치를 만들고 모든 브랜치로 한꺼번에 이동하는 옵션을 사용한다는 점을 기억하세요 .
앨리스의 변경 사항부터 시작해 봅시다. 그녀는 의 첫 번째 줄을 업데이트 haiku.txt하여 .An old silent pondA new silent pond
| 123 | A new silent pondA frog jumps into the pond -The sound of water. |
파일을 저장한 후 실행하면 git diff무엇이 변경되었는지 확인할 수 있습니다.
| 123456789 | diff --git a/haiku.txt b/haiku.txtindex f1ea5b9..e611674 100644--- a/haiku.txt+++ b/haiku.txt@@ -1,3 +1,3 @@-An old silent pond+A new silent pond A frog jumps into the pond - The sound of water. |
보시다시피, 우리가 줄의 일부만 변경했어도 줄이 다르면 git은 줄 전체를 변경한 것으로 간주합니다. 그래서 줄 전체를 제거하고 그 자리에 새 줄을 추가했다고 생각합니다.
이제 새 커밋을 만들어서 변경 사항을 저장해 보겠습니다.
| 12 | $ git add .$ git commit -m "Alice's changes" |
이제 Bob에 대한 변경을 해봅시다. 이때 새 브랜치를 만들면 새 브랜치는 브랜치 에서 생성되는데alice , 이는 우리가 원하는 것이 아닙니다.
따라서 Bob의 브랜치를 만들려면 메인으로 돌아가야 합니다. checkout거기에서:
| 12 | $ git checkout main$ git checkout -b bob |
이제 Bob이 첫 번째 줄도 변경한다고 가정해 보겠습니다.
| 123 | An old loud pondA frog jumps into the pond -The sound of water. |
그리고 그는 또한 자신의 변경 사항을 커밋합니다.
| 12 | $ git add .$ git commit -m "Bob's changes" |
이제 우리의 git 기록은 다음과 같습니다.
현재 지점장은 Bob의 지점에 있으며, 다음을 사용하여 확인할 수 있습니다 status.
| 12 | On branch bobnothing to commit, working tree clean |
이제 갈등이 발생하는 방식은 다음과 같습니다.
- Alice는 먼저 자신의 변경 사항을 병합합니다.
- 와 충돌이 없기 때문에
main그냥merge작동합니다. - 이제 Bob은 자신의 작업을 메인에 병합하려고 합니다.
- Alice의 변경 사항이 main에 있고 둘 다 같은 줄을 변경했기 때문에
병합 충돌이 발생합니다 .
이것이 실제로 어떻게 작동하는지 살펴보겠습니다. 먼저 Alice의 브랜치를 다음과 병합합니다 main.
| 12 | $ git checkout main$ git merge alice |
우리는 얻는다:
| 1234 | Updating b50f6c0..92873f6Fast-forward haiku.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) |
작동했습니다! 이제 Bob의 변경 사항을 가져오겠습니다.
| 1 | $ git merge bob |
아, 우리는 다음을 얻습니다:
| 123 | Auto-merging haiku.txtCONFLICT (content): Merge conflict in haiku.txtAutomatic merge failed; fix conflicts and then commit the result. |
충돌이 있는 각 파일에 대해 병합 명령의 출력에서 한 줄을 받게 됩니다 CONFLICT. 이 경우에는 .뿐입니다 haiku.txt. 파일을 열면 다음과 같이 보입니다.
| 1234567 | <<<<<<< HEADAn new silent pond=======An old loud pond>>>>>>> bobA frog jumps into the pond -The sound of water. |
저 이상한 건 뭐야? 글쎄, 이건 git이 당신에게 아래까지 모든 게 당신의 현재 HEAD(이 경우)라고 알려주는 방식이야 <<<<<<< HEAD. =======그 main아래, 그리고 위까지가 다른>>>>>>> bob 브랜치 의 변경 사항 ( )이야.bob
이는 Alice와 Bob이 모두 첫 번째 줄을 변경했기 때문에 말이 됩니다. Alice의 변경 사항은 “A new silent pond”이고 Bob의 변경 사항은 “An old loud pond”입니다.
우리는 둘 중 하나의 버전을 선택함으로써 충돌을 해결할 수 있습니다. 우리는 또한 두 버전을 모두 버리고 새로운 버전을 만들 수 있는데, 우리가 할 일은 다음과 같습니다.
| 123 | An old boring pondA frog jumps into the pond -The sound of water. |
git이 우리를 위해 추가한 이상한 마커를 모두 제거했음을 알아두세요. 이제 병합 프로세스를 계속하기 위해 해당 변경 사항을 추가할 수 있습니다.
| 12 | $ git add .$ git merge --continue |
git이 지금은 fast-forward 전략을 사용할 수 없기 때문에, 이 새로운 병합 커밋에 메시지를 제공해야 합니다. 기본 메시지는 괜찮으므로, git이 보여주는 파일을 저장하면 됩니다.
지금 실행하면 git log새로운 병합 커밋이 표시됩니다.
| 123456 | commit d1d2e2e9364427dd99a2758113364f5482893129 (HEAD -> main)Merge: 92873f6 ee57f11Author: Federico Ramirez <federico_r@beezwax.net>Date: Thu Apr 25 12:15:01 2024 -0700 Merge branch 'bob' |
그리고 이것이 우리의 새로운 역사입니다.
병합 중단
어떤 이유로든 병합을 중단하려는 경우 다음 방법을 사용하면 항상 안전하게 중단할 수 있습니다.
| 1 | $ git merge --abort |
결론
정말 많은 내용이었습니다! 우리는 git의 표면만 훑어보았습니다. 하지만, 여전히 우리는 git의 정교한 사용 사례, 예를 들어 브랜치와 병합이 무엇인지, 병합 충돌이 발생하는 이유와 해결 방법, 프로젝트 기록을 탐색하는 방법 등을 다루었습니다.
후속 게시물에 대한 제 계획은 모든 것을 로컬에서 하는 대신 GitHub을 원격 저장소로 사용하는 방법을 다루는 것입니다. git의 가장 큰 장점 중 하나는 로컬에서 실행되고 코드를 작성하는 데 원격 서버가 필요하지 않다는 것입니다! 모든 사람이 저장소의 완벽하게 작동하는 사본을 가지고 있으므로 사용 사례가 간단하다면 원격 없이 git을 사용할 수 있습니다.
하지만 대부분의 실제 프로젝트에서는 다른 사람과 협업하고 싶을 것이고, GitHub은 바로 그런 일을 해줍니다. Git을 사용하여 다른 사람들과 협업하기가 쉬워지고, 문제를 추적하고 관리하고, 변경되기 전에 병합을 검토하고, 커밋과 브랜치 간의 차이점을 확인하고, 심지어 코드에 대한 변경 사항이 원격으로 푸시될 때마다 테스트 모음을 실행하는 것과 같은 코드에서 작업을 실행하는 것과 같은 많은 추가 도구를 제공합니다.
