Git은 오픈소스 분산 버전 컨트롤 시스템입니다. Git은 로컬 브랜칭, 스테이징, 워크플로우 등을 사용하여 여러분이 프로젝트 파일들을 쉽게 관리할 수 있도록 도와줍니다.

오늘날 많은 개발자가 Git을 사용하며, 아래와 같은 기본적인 Git 사용법에 익숙합니다.

• 저장소(repository)를 초기화하기
• 브랜치들을 생성하기
• 변경을 stage/unstage하기
• 수정사항을 커밋하기
• 원격 저장소에 커밋을 푸시하기

그러나 많은 개발자들이 머지, 머지 충돌 해결과 같은 개념들에 대해 혼란스러워 합니다. 이 게시글에서는 실천을 통해서 머지 충돌을 어떻게 해결하는지 배울 것입니다. 즉, 여러분은 이 글을 통해 읽고, 이해하고, 직접 시도해보는 것을 진행할 것입니다.

만약 비디오 영상을 통해서도 배우고 싶다면, 아래 영상을 참고하면 됩니다. 여러분께서 Git이 처음이고 기본 컨셉들을 모두 배우고 싶다면, 영상 Demystifying Git for Beginners | Learn Git | Using the Git Bash CLI
이 도움이 될 것입니다.

개발자들은 "머지 충돌"에 대해 어떻게 이야기할까?

최근 저는 트위터, 링크드인, 유튜브에서 개발자들을 대상으로 깃 머지 충돌을 편하게 해결할 수 있냐는 질문으로 투표를 진행했습니다. 결과가 어땠을까요?

70-80%의 개발자들이 깃 머지 충돌을 해결하는데 어려움을 느낀다고 답했습니다. 이를 통해 머지 충돌을 해결하는 것이 중요한 주제라는 것을 알 수 있습니다.

깃 머지와 머지 충돌이 무엇인가?

Git은 여러분의 모든 파일들의 버전 히스토리를 가지고 있는 버전 컨트롤 시스템입니다. 덕분에 여러분에 원하는 버전으로 언제든지 되돌아갈 수 있습니다.

만약 여러분이 abc.txt라는 파일을 만들고 Git 저장소로 푸시(push)했다고 가정해보죠. 이 때, 이 파일은 현재 버전에 해당합니다. 만약 여러분의 동료가 같은 파일을 수정하고 저장소에 푸시했다면, 그 파일은 새 버전을 가지게 됩니다.

Git merge는 현재 파일들의 내용을 이전 버전들과 동기화하는 기능입니다. 이 기능은 필수적인 기능인데, 누가 어떤 시점에서도 최신 파일 위에 작업을 시작할 수 있게 해주기 때문입니다. 이번 버전에 수정사항을 오버라이딩(overriding)하지 않고도 말이죠.

Git merge은 동일한 파일에 새로운 변경 사항을 반영하기 전에 다른 개발자들이 수정한 내용들을 통합하는데 도움을 줍니다.

우리가 깃 머지에 대해 알아야 할 것은 2가지 입니다:

1. 변경사항 : 두 버전의 파일 사이에 어떤 유형의 작업이 수행되었나? 새로운 내용이 추가되었는지, 제거되었는지, 또는 기존 내용을 업데이트했는지.
2. 가능성 : 수정이 파일 내 다른 영역에 발생했는지 아니면 같은 영역의 파일에 발생했는지 2가지의 가능성이 있습니다. 여기서 같은 영역이라는 의미는 개발자들이 파일 내 가까운 지역의 내용들을 각자 수정했다는 의미입니다. (예를 들어, 같은 문단이거나 같은 라인)

다행히, Git은 auto-merge 전략으로 대부분의 문제들을 해결합니다. 그러나 파일 내 같은 영역에서 수정 작업들이 발생한 경우, auto-merge가 수행되지 않습니다. 대신, Resolve the Merge Conflicts 메시지를 보여줍니다.

공포의 Git 머지 충돌

알렉스와 티나, 두 명의 개발자들의 이야기를 예시로 이해하는 시간을 가져보겠습니다.

어느날,

• 알렉스가 원격 저장소로에서 그의 로컬 저장소로 수정사항을 pull 했다
• 그가 abc.txt라는 파일을 수정하고, 스테이징하고, 커밋한 뒤 마침내 원격 저장소에 이를 push했다
• 그 동안, 알렉스가 abc.txt 파일을 수정한지 알아채지 못한 티나가 파일의 같은 영역에 일부 코드를 수정하고 원격 저장소로 push를 시도했다
• 버전 관리 시스템인 Git으로부터 티나는 현재 원격 저장소에 있는 파일보다 오래된 버전의 파일을 수정했다는 경고 문구를 확인한다(알렉스가 이미 원격 저장소의 것을 수정했기 때문)
• 이제, 티나는 우선 원격 저장소로부터 수정사항을 pull 받고, 파일을 업데이트한 다음 다시 푸시를 해야 한다
• 티나가 작업을 수행했으나, auto-merge 실패라는 문구가 떴다. 그래서 그녀는 merge conflict를 해결해야만 하는 상황이다

이 이야기가 왠지 익숙하시다구요? 여러분에게도 비슷한 사건이 발생한적이 있나요? 여러분도 과거에 티나의 상황을 겪었을 가능성이 있을 겁니다. 만약 아니라면, 곧 경험하겠죠. 자, 이제 티나가 이 문제를 어떻게 생산적으로 해결했는지 알아보겠습니다.

Git에서 머지 충돌을 해결하는 방법

머지 충돌 해결하는 것은 들리는 것만큼 어려운 것이 아닙니다. 마음을 차분히 가지고 수정사항을 확실히 파악한다면 대부분의 문제를 어렵지 않게 해결할 수 있습니다.

사고 과정

일단 티나가 수정사항을 pull하게 되면, 티나의 로컬 파일에는 그녀의 수정사항과 Alex의 수정사항이 함께 존재하게 됩니다. 여기서 티나의 선택지는 4개가 있습니다:

• 알렉스의 수정사항을 유지하고 그녀의 것을 제거하기
• 알렉스의 수정사항을 지우고 그녀의 것을 유지하기
• 알렉스의 수정사항과 그녀의 수정사항 둘 다 유지하기
• 알렉스와 그녀의 수정사항 모두 지우기

이중 그녀는 어떤 방법을 선택해야 할까요? 프로젝트의 요구사항과 상황에 따라 완전히 다릅니다. 티나는 새로 들어온(incoming) 수정사항을 확인하고 그 상황에 적절한 작업을 수행할 것입니다.

새로 들어온(incoming) 수정사항이 무엇일까요? 티나는 이를 어떻게 확인할까요? 티나는 수정사항을 어떻게 만들까요? 여러가지 질문이 있습니다. 아래에서 몇 가지 실제 사례를 들면서 답을 찾아보겠습니다.

Git 머지 충돌을 해결하기 위한 단계들

머지 충돌에 관한 실제 사례들을 몇 가지 들어보고 이를 어떻게 해결할 지 배워봅시다. 혹시 이 개념들을 영상으로 배우고 싶다면 영상의 머지 충돌에 관한 부분을 확인해주세요.

사례 1: 파일의 같은 영역에 수정사항이 있을 경우

같은 영역에서 여러 수정사항이 있어 Git이 auto-merge를 수행하지 못할 경우, 특수 문자들로 충돌 지역을 표시합니다. 해당 특수문자들은 아래와 같습니다.

• <<<<<<<
• =======
• >>>>>>>

<<<<<<<와 ======= 사이에는 여러분의 로컬 환경의 수정사항들을 가르킵니다. 이 수정사항들은 아직 원격 저장소에 반영되지 않은 상태입니다. ======= 와 >>>>>>> 사이에는 원격 저장소 또는 다른 브랜치의 수정사항들을 가르킵니다. 이제 여러분은 2개의 섹션들을 확인하여 결정을 내려야 합니다.

아래 이미지는 충돌이 발생하여  auto-merge를 수행할 수 없는 파일의 내용들을 보여줍니다. 충돌 지점은 로컬에서 - Sleep이라는 코드를 추가하여 수정한 부분에 있습니다. 그동안 누군가가 같은 영역에 ‘- Gym’이라는 코드 한 줄을 추가한 수정내용을 push한 상황이네요.

따라서 - Sleep 은 로컬 환경의 수정사항으로, - Gym은 원격 저장소나 다른 브랜치에서 incoming되는 수정사항으로 인식됩니다.

같은 영역 내 수정으로 인해 발생한 머지 충돌

당신은 상황과 프로젝트의 수요에 기반하여 충돌을 해결할 것입니다. 만약 - Sleep 만 살리고 싶다면, 그것만 살리고 나머지 충돌 부분은 제거할 것입니다. 이 경우, 파일 내용은 아래와 같이 될 것입니다:

- Eat
- Read
- Sleep

반대로 - Gym만 살리고 - Sleep을 지울 수도 있습니다:

- Eat
- Read
- Gym

만약 두 줄 모두 살려야 한다면, 충돌 지점을 알려주는 기호들만 삭제하면 됩니다.

- Eat
- Read
- Sleep
- Gym

만약 어떠한 수정 내용도 반영하고 싶지 않다면, 모두 지우세요.

- Eat
- Read

현재 상황에서 어떤 수정사항을 선택할지 결정하는 것은 온전히 여러분의 몫입니다. 수정을 하고나서 충돌 지점을 알려주는 기호(<<<<<<<,  =======, >>>>>>>)들이 남아있지 않도록 확인해야 합니다. 수정이 끝나면, 아래처럼 진행해주세요.

수정사항을 스테이징(Stage) 하기:

git add <files>

메시지와 함께 수정 사항들을 커밋하기:

git commit -m "Message"

마지막으로, 원격 저장소로 수정사항을 푸시합니다:

git push

이번 시나리오에서 머지 충돌을 해결하는 방법은 이것이 전부입니다.

사례 2: 원격 저장소/다른 브랜치에서 파일이 삭제된 경우

다른 브랜치에서 한 개발자가 파일을 수정하는 동안, 또 다른 개발자가 자신의 브랜치에서 동일한 파일을 삭제한 상황입니다. 이 경우, 여러분은 파일을 유지하고 싶은지 아니면 지우는 것이 옳은지 판단해야 합니다.

삭제된 파일을 여러분의 브랜치에 다시 추가하기 위해, 이렇게 하세요:

git add <file-name>

파일을 지워주세요.

git rm <file-name>

그리고 다음 메시지와 함께 수정사항을 커밋해주세요.

git commit -m "Message"

마지막으로, 커밋을 푸시하세요.

git push

마치며

여러분이 위 두 사례에 대해 배우고 실습한다면 대부분의 상황들을 대처하고 머지 충돌을 해결할 수 있습니다. 그렇기 때문에 저는 여러분이 이것들을 여러번 연습하길 추천합니다.

여러분이 만약 새 시나리오를 경험하거나 머지 충돌을 해결하는데 어려움을 느낀다면, 이 비디오에 댓글을 달아주셔도 좋아요. 답변을 드릴 수 있도록 최선을 다 해볼게요!

정리하기 전에, 몇 가지 팁을 드려요:

• 이 게시글에 나온 모든 예시들은 여러분이 GitBash를 사용하거나 또는 다른 Git CLI로 머지 충돌을 해결한다는 점을 가정합니다. 물론 다른 GUI 도구를 사용할  수  있습니다
• 항상 새 코드를 작성하기 전에 원격 저장소 또는 관련 브랜치에서 pull을 받으세요. 여러분의 브랜치를 항상 최신 상태로 유지해줄 것이고 충돌 가능성도 줄여줍니다
• 항상 push하기 전에 pull을 해서 Git이 거절하는 것을 방지하세요
• 머지 충돌을 해결하는 동안 무엇을 살리고 무엇을 삭제할지 스스로 판단하기가 어렵다면 동료 개발자들에게 이야기하세요.

모두 감사합니다. Git 머지 충돌과 관련하여 여러분께 유익한 게시글이 되었길 바래요.

우리 소통해요.

• 매일 웹 개발과 프로그래밍 팁을 얻고싶으시다면  트위터 계정을 팔로우 해주세요
• 제 오픈소스 프로젝트는 GitHub에서 확인할 수 있어요
• 제 유튜브 채널을 구독하시면 JavaScript, ReactJS, Node.js, Git 등 웹 개발 관련 실용적인 정보를 얻을 수 있어요

다음 게시글에서 봬요. 그때까지, 잘 지내시고 항상 행복하세요!

Git 태그에 대한 설명: Git에서 태그를 나열, 생성, 제거 및 표시 방법

태그 지정(Tagging)을 통해 개발자는 프로젝트 개발 과정에서 중요한 체크포인트를 표시할 수 있습니다. 예를 들어, 소프트웨어 릴리즈 버전에 태그(Tag)를 지정할 수 있습니다. (예: V1.3.2) 기본적으로 커밋에 특별한 이름(태그)을 부여할 수 있습니다.

생성된 모든 태그를 알파벳 순으로 보려면:

git tag

태그에 대한 자세한 정보를 얻으려면:

git show v1.4

태그에는 두 가지 유형이 있습니다:

주석이 달린 태그

git tag -a v1.2 -m "my version 1.4"

경량 태그

 git tag v1.2

두 유형은 저장되는 방식이 다르며 현재 커밋에 태그를 생성합니다.

이전 커밋에 태그를 지정하려는 경우, 태그할 커밋 아이디를 지정합니다.

 git tag -a v1.2 9fceb02

커밋을 체크아웃과 원격 저장소에 푸시하는 동안, 커밋 아이디 대신 태그 이름을 사용할 수 있습니다.

추가 정보:

• Git 문서: Git 문서 페이지 (영문)
• Git 태그 챕터: Git 태그 페이지 (영문)

git tag 명령을 사용해 프로젝트에서 사용할 수 있는 모든 태그를 나열할 수 있습니다. (알파벳 순으로 표시됨)

$ git tag
v1.0
v2.0
v3.0

이러한 태그 나열 방법은 작은 프로젝트에 유용하지만, 대규모 프로젝트에는 수백 개의 태그가 있을 수 있으므로, 기록에서 중요한 지점을 검색할 때 태그를 필터링해야 할 수 있습니다. git tag 명령어에 -l을  추가해 특정 문자가 포함된 태그를 찾을 수 있습니다.

$ git tag -l "v2.0*"
v2.0.1
v2.0.2
v2.0.3
v2.0.4

태그 생성하기

주석이 달린 태그와 경량 태그의 두 가지 유형을 만들 수 있습니다. 첫 번째 방법은 GIT 데이터베이스에서 객체를 놓고 경쟁하는 것입니다. 체크섬이 지정되고, 메시지(예: 커밋)가 필요하며, 이름, 이메일 및 날짜와 같은 기타 중요한 데이터를 저장합니다. 반면에 경량 태그는 메시지가 필요하거나 다른 데이터를 저장하지 않고, 프로젝트의 특정 지점에 대한 포인터 역할만 합니다.

주석 달린 태그 생성하기

주석 달린 태그를 생성하기 위해, git tag 명령어에 -a tagname -m "tag message"를 추가합니다.

$ git tag -a v4.0 -m "release version 4.0"
$ git tag
v1.0
v2.0
v3.0
v4.0

보시다시피, -a는 주석이 달린 태그를 생성하고 있음을 지정하고, 그 뒤에 태그 이름이 오고, 마지막으로 -m 뒤에는 GIT 데이터베이스에 저장할 태그 메시지가 뒤따릅니다.

경량 태그 생성하기

경량 태그는 커밋 체크섬만 포함됩니다. (다른 정보는 저장되지 않음). 하나를 생성하려면, 다른 옵션 없이 git tag 명령어를 실행하기만 하면 됩니다(이름 끝에 있는 -lw 문자는 경량 태그를 나타나는 데 사용되지만, 원하는 대로 표시할 수 있습니다.):

$ git tag v4.1-lw
$ git tag
v1.0
v2.0
v3.0
v4.0
v4.1-lw

이번에는 메시지나 기타 관련 데이터를 지정하지 않았으므로 태그에는 오직 참고된 커밋의 체크섬만 포함됩니다.

태그 데이터 보기

git show 명령을 실행하면 태그에 저장된 데이터를 볼 수 있습니다. 주석이 달린 태그의 경우, 태그 데이터와 커밋 데이터가 표시됩니다.

$ git show v4.0
tag v4.0
Tagger: John Cash <john@cash.com>
Date:   Mon Sat 28 15:00:25 2017 -0700

release version 4.0

commit da43a5fss745av88d47839247990022a98419093
Author: John Cash <john@cash.com>
Date:   Fri Feb 20 20:30:05 2015 -0700

  finished details

경량 태그를 보고 있을 때, 참조된 커밋 데이터만 표시됩니다.

$ git show v1.4-lw
commit da43a5f7389adcb9201ab0a289c389ed022a910b
Author: John Cash <john@cash.com>
Date:   Fri Feb 20 20:30:05 2015 -0700

  finished details

이전 커밋에 태그 지정하기

깃 태그 커밋을 이용해 과거 커밋에 태그를 지정할 수도 있습니다. 커맨드 라인에 커밋의 체크섬(혹은 최소한 그 일부)을 지정해야 합니다.

먼저 필요한 커밋의 체크섬을 찾기 위해 깃 로그를 실행합니다:

$ git log --pretty=oneline
ac2998acf289102dba00823821bee04276aad9ca added products section
d09034bdea0097726fd8383c0393faa0072829a7 refactorization
a029ac120245ab012bed1ca771349eb9cca01c0b modified styles
da43a5f7389adcb9201ab0a289c389ed022a910b finished details
0adb03ca013901c1e02174924486a08cea9293a2 small fix in search textarea styles

필요한 체크섬이 있으면, 태그 생성 행 끝에 추가합니다:

$ git tag -a v3.5 a029ac

git tag를 실행해 태그가 올바르게 추가됐는지 확인할 수 있습니다:

$ git tag
v1.0
v2.0
v3.0
v3.5
v4.0
v4.1-lw

태그 푸시하기

깃 푸쉬 명령을 실행할 때 깃은 기본적으로 태그를 푸시하지 않습니다. 따라서 서버에 태그를 성공적으로 푸시하려면 git push origin 명령을 실행해야 합니다.

$ git push origin v4.0
Counting objects: 14, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (16/16), done.
Writing objects: 100% (18/18), 3.15 KiB | 0 bytes/s, done.
Total 18 (delta 4), reused 0 (delta 0)
To git@github.com:jcash/gitmanual.git
 * [new tag]         v4.0 -> v4.0

git push origin 명령어에 --tags 옵션을 사용해 여러 태그를 한 번에 추가할 수도 있습니다:

$ git push origin --tags
Counting objects: 1, done.
Writing objects: 100% (1/1), 160 bytes | 0 bytes/s, done.
Total 1 (delta 0), reused 0 (delta 0)
To git@github.com:jcash/gitmanual.git
 * [new tag]         v4.0 -> v4.0
 * [new tag]         v4.1-lw -> v4.1-lw

태그 채킹하기

평소처럼 git checkout을 사용해 태그를 체크아웃할 수 있습니다.
그러나 이 경우 HEAD 상태가 분리될 수 있습니다.

$ git checkout v0.0.3
Note: checking out 'v0.0.3'.

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 performing another checkout.

태그 삭제하기

특정 태그를 삭제하고 싶은 상황이 있을 수 있습니다. 이때 다음과 같은 유용한 명령어를 사용합니다:

$ git tag --delete v0.0.2
$ git tag
v0.0.1
v0.0.3
v0.0.4

추가 정보

• Git 프로 - 기본 태깅: Git 문서 태깅 페이지(영문)
• Git 프로 - 문서: Git 문서 페이지(영문)
• Git 사용법: Githowto 문서 페이지(영문)
• Git 팁: 태그: Alblue 블로그(영문)
• 태그 생성하기: drupal 문서 페이지(영문)

출처

깃 문서: 태그(영문)

쓸모 있는 개정 이력을 생성하기 위해 조직과 팀은 가장 먼저, 사용할 커밋 메세지 규칙에 동의해야 합니다. 이것은 개인 프로젝트도 마찬가지죠.

최근에 저는 Hashnode에 **"직장에서 어떤 커밋 메세지 규칙을 사용하고 있는지"**라는 질문을 해봤는데, 몇몇 커뮤니티 유저들로부터 그들이 직장에서 또는 개인 프로젝트를 위해 사용하는 규칙에 관한 훌륭한 답변을 받았습니다.

이 글을 통해 저는 좋은 커밋 메세지 작성하는 법과 우리가 왜 이 작성법을 따라야 하는지에 대해 설명하겠습니다.

이 글은 다른 글들과 함께 제 블로그에도 게시되었습니다.

깃으로 버전 컨트롤하기

버전 컨트롤 소프트웨어는 현대 사회 소프트웨어 개발자 실무에 중요한 부분입니다.

여태껏 깃은 세계에서 가장 광범위하게 사용되는 버전 컨트롤 시스템입니다. 깃은 리눅스 운영 시스템 커널의 유명 개발자인 리누스 토르발스가 2005년 최초로 개발한 오픈 소스 프로젝트이며, 배포된 이후 활발히 유지돼 왔습니다.

깃이 처음이신가요? 공식 가이드 문서 시작하기 또는 지난 대화에서 제가 드린 슬라이드를 확인해보세요.

커밋 메세지란?

커밋 명령어는 깃 안에 staging(번역자 주: 커밋으로 저장소에 기록할 수정사항을 대기상태로 만들기)을 한 이후 로컬 리포지토리(repository)에 발생한 변화를 저장하는 데 사용됩니다. 그러나 깃에서 변경점들을 저장하기 이전에 깃에게 사용자가 만든 수 많은 수정사항 중 어떤 변경점을 저장하고 싶은 것인지 말해야 합니다. 변경점들을 구분하기 위해 굉장히 좋은 방법은 바로 커밋 메세지를 추가하는 것입니다.

커밋 옵션들

• -m
  해당 옵션은 커밋 메세지를 설정합니다.

git add static/admin/config.yml
git commit -m "Setup multiple roles for netlify-cms git gateway"

• -a 또는 -all
  해당 옵션은 (새로운 걸 포함한) 모든 tracked, modified, 또는 deleted 상태의 파일들을 자동으로 커밋합니다.

git commit -a -m "Add a new role for netlify-cms git gateway"

• --amend
  해당 옵션은 현재 staged된 변경 사항 또는 새 커밋 메세지로 마지막 커밋을 다시 작성하며 아직 원격 저장소에 푸시되지 않은 커밋에서만 실행해야 합니다.

git add .
git commit --amend -m "Update roles for netlify-cms git gateway"

좋은 커밋 메세지를 써야 하는 이유

어쩌면 당신은 "이건 그냥 개인 프로젝트일 뿐"이라 말할지도 몰라요. 그렇죠, 지금은 혼자 일하니까요. 하지만 어떤 팀과 함께 일할 때나 오픈 소스에 기여할 때는 어떻게 될까요?

잘 작성된 깃 커밋 메세지는 해당 프로젝트에서 작업하는 다른 개발자들에게 새로운 내용이나 수정사항에 대한 배경을 소통하는 최고의 방법이며 실제로 미래의 당신 스스로에게도 남겨두는 방법입니다.

오래된 프로젝트 중 하나에 git log를 실행해보고 프로젝트 초기부터 사용한 "이상한" 커밋 메세지를 발견한 적 있나요? 과거에 어떠한 작업을 왜 했는지 이해하기 어려울 수도 있고, 이 글을 좀 더 일찍 읽었길 바랄 것입니다 $:)$.

커밋 메세지는 어떤 변화가 왜 만들어졌는지 적절히 소통할 수 있고, 커밋 메세지의 중요성을 깨닫게 되면 개발 및 협업 작업을 더 효율적이게 할 수 있습니다.

깃으로 커밋 메세지 작성하는 법

이전에 저는 제 개인 프로젝트에서 git commit -m "Fix X to allow Y to use Z"으로 어떤 제목만 적고 추가 설명은 없는 방식만 사용하였습니다. 이 방식은 git commit -m "Fix typo in README.md"와 같은 작고 명확한 수정사항들을 커밋할 때 적합합니다. 하지만 좀 더 큰 규모의 작업 같은 경우에는 부연설명을 추가할 필요가 있을 것입니다.

에디터를 활용한 방법

아무런 메세지나 옵션 없이 git commit을 실행하면 커밋 메세지를 작성할 수 있는 기본 텍스트 에디터가 열릴 것입니다.

기본 에디터를 설정하려면 다음과 같은 명령어를 실행합니다.

git config --global core.editor nano

명령어를 실행하면 깃에 기본 에디터를 nano로 설정하는 것입니다. "nano"를 "emacs", "vim", 또는 무엇이든 선호하는 에디터로 변경하세요.

열린 에디터 안의 첫번째 줄은 제목(및 짧은 설명)이 되고, 빈 줄 하나를 띄운 후 그 외 모든 것들이 본문 및 부연 설명으로 저장됩니다.

<Summarize change(s) in around 50 characters or less>

<More detailed explanatory description of the change wrapped into about 72
characters>

커맨드라인(Command Line)을 활용한 방법

git commit -m "Subject" -m "Description..."

첫번째 -m 옵션은 제목 및 짧은 설명을 가르키고 다음 -m 옵션은 본문 및 부연 설명을 가르킵니다.

좋은 커밋 메세지 작성하는 법

다양한 팀과 개발자들이 좋은 커밋 메세지를 작성하기 위해 따르는 몇 가지 규칙이 있습니다. 저는 커밋 메세지를 작성하기 위한 몇 가지 일반적인 규칙과 팁에 대해서만 간략히 설명할테니 여러분이 따르고 싶은 관습을 스스로 결정하시면 됩니다. 그리고 만약 어떤 회사에서 일하거나 오픈 소스에 기여한다면 그 기관이나 프로젝트의 커밋 메세지 작성 방식을 따라 적용해야 합니다 $:)$.

일관성을 위해 직장 업무 볼 때는 하나의 커밋 메세지 작성법을, 개인 프로젝트일 때는 다른 방식을 사용할 수 있으며, 또한 방식 자체가 때에 따라 바뀔 수도 있습니다.

이곳에서 몇 가지 굉장한 커밋 메세지 작성법을 꼭 확인해보세요. 누군가 결정을 내리는데 도움이 될지도 모르니 본인만의 작성 규칙에 대해 적어놓아도 좋습니다.

여기에는 팀 포프(Tim Pope)가 작성한 매우 좋은 커밋 메세지 양식이 있습니다.

(영어의 경우 대문자로) 50자 이내 짧은 요약

만약에 필요하다면 보다 자세한 설명을 여기에 쓴다. 내용은 72자 내외에서 마무리하는 것을 권장한다. 어떤 맥락에서는 첫번째 줄은 이메일의 제목처럼 취급되고 나머지가 본문으로 간주된다. 빈 칸 한 줄은 본문과 요약문 및 제목을 구분하기 위한 것으로 본문 전체를 생략하지 않은 이상 필수로 있어야 한다; rebase같은 도구들은 이 본문과 요약문 사이에 빈 칸 한 줄이 없으면 혼란스러워하는 경우도 있다.

커밋 메세지는 명령형으로 적자: 예를 들어 "Fix bug"로 적어야지 "Fixed bug"나 "Fixes bug"가 아니다. 이러한 관습은 git merge나 git revert와 같은 명령어에 의해 생성된 커밋 메세지와 일치하게 된다.

추가 문장들은 빈 칸 한 줄 뒤에 따라온다.

- 글머리 기호가 있어도 괜찮다

- 글머리는 통상적으로 하이픈(-)이나 별(*) 기호 뒤에 한 칸 띄우는 것으로 사용되고 문단과 문단 사이에는 빈 칸 한 줄을 띄우는 것으로 사용되지만 그 외 다양한 법이 존재한다

- 들여쓰기를 사용하자

이슈 트래커를 사용한다면 가장 마지막에 레퍼런스 번호를 이런 식으로 적자.

Resolves: #123

정말 보기 좋지 않나요? 여기 여러분의 메세지도 좋게 만들 수 있는 방법입니다.

1. 커밋의 종류를 명시하라.

• feat: 어떤 특정 어플리케이션에 더할 새로운 feature
• fix: 어떤 오류 해결(fix)
• style: 스타일과 연관된 feature나 업데이트들
• refactor: 코드 베이스의 특정 부분을 재정렬(refactoring)
• test: 테스트와 관련된 모든 것
• docs: 문서화에 관한 모든 것
• chore: 정규 코드 유지보수.

또한 커밋 종류를 표현하기 위해 이모티콘을 사용할 수도 있습니다.

2. 제목을 본문으로부터 빈 칸 한 줄 띄워 구분하라
3. 커밋 메세지는 어떠한 공백오류(whitespace errors)를 포함하지 않아야 한다
4. 불필요한 구두점을 삭제하라
5. 제목 행을 마침표(.)로 끝맺지 마라
6. (영어일 경우) 제목 행과 매 문단의 시작을 대문자로 하라
7. 제목 행에는 명령어를 사용하라
8. 본문 영역은 적용한 변경 사항과 그것을 만든 이유에 대해 설명하기 위해 활용하라
9. 검토자들이 본래 문제가 무엇이었는지 이해하고 있을 것이라 가정하지 말고 그것을 더해 적어라
10. 본인의 코드가 설명 없이도 괜찮다고 생각하지 마라
11. 소속되어 있는 팀의 정해진 커밋 규칙을 따르라

마치며

커밋 메세지에서 가장 중요한 것은 반드시 명확하고 의미가 있어야 한다는 것입니다. 장기적으로 좋은 커밋 메세지를 작성하는 것은 커밋 메세지 작성자가 얼마나 좋은 협력자인지를 보여줍니다. 좋은 커밋 메세지를 작성하여 얻는 이점들은 팀 내에서만 국한되는 것이 아니라 개발자 본인, 또한 미래의 컨트리뷰터(contributors)에게까지 영향을 끼칩니다.

깃에 대해 더 배우고 전문적인 "버전 관리자"가 되고 싶나요? 여기 참고자료들을 확인해보세요:

• https://try.github.io/
• https://git-scm.com/book/en/v2
• https://www.git-tower.com/learn/
• https://learngitbranching.js.org/
• https://github.com/commitizen/cz-cli

영어 원문: An introduction to Git merge and rebase: what they are, and how to use them 글쓴이: [Vali Shah]

개발자로서 많은 사람이 머지(merge)와 리베이스(rebase) 중에 하나를 선택해야 하는 경우가 발생합니다. 인터넷에서 얻는 모든 참고 자료와 함께 모든 사람은 "심각한 문제가 발생할 수 있으니, 리베이스는 절대 사용하지 마세요."라고 생각합니다. 그럼, 리베이스와 머지가 무엇인지, 사용해야 하는 이유(사용해서는 안 되는 이유) 및 사용 방법에 관해 설명하겠습니다.

깃 머지와 깃 리베이스는 동일한 용도로 사용됩니다. 둘 다 여러 브렌치에서의 변경 사항을 하나로 통합하도록 설계됐습니다. 비록 최종 목표는 같지만, 이 두 방법은 다른 방식으로 목표를 달성하며, 더 나은 소프트웨어 개발자가 되기 위해서 차이점을 아는 것이 좋습니다.

이 질문은 깃 커뮤니티에서 말이 많습니다. 어떤 사람들은 항상 리베이스를 사용해야 한다고 생각하고, 다른 사람들은 항상 머지해야 한다고 믿습니다. 각각의 측면은 설득력 있는 이점을 가지고 있습니다.

깃 머지

버전 제어 시스템을 사용하는 개발자는 일반적으로 깃 머지를 사용하는 게 관행입니다. 테스트, 버그 수정 혹은 기타 이유로 브렌치가 생성됐는지 여부와 관계없이, 머지를 실행하면 변경 사항이 다른 위치에 커밋됩니다. 더 구체적으로 말하면, 머지는 소스 브렌치의 내용을 가져와 타겟 브렌치와 병합시킵니다. 이 작업을 통해, 타겟 브렌치만 변경되며 소스 브렌치 기록은 동일하게 유지됩니다.

마스터 브렌치에서 피처로 머지

장점

• 간단하고 친숙하다
• 전체 기록과 연대순으로 보존한다
• 해당 브렌치의 내용을 유지한다

단점

• 많은 머지 커밋으로 커밋 기록이 오염될 수 있다.
• git bisect를 사용한 디버깅이 더 어려워질 수 있다.

사용 방법

checkout과 merge 명령어를 사용해 마스터 브렌치를 피처 브렌치로 머지해 보겠습니다.

$ git checkout feature
$ git merge master

(or)

$ git merge master feature

이렇게 하면 두 브렌치의 기록을 두고 있는 피처 브렌치에 새로운 "머지 커밋"이 생성됩니다.

깃 리베이스

리베이스는 한 브렌치에서 다른 브렌치로 변경 사항을 통합하는 또 다른 방법입니다. 리베이스는 모든 변경 사항을 하나의 패치로 압축합니다. 그런 다음 타겟 브렌치에 이 패치를 통합합니다.

머지와 달리 리베이스는 완료된 작업을 한 브렌치에서 다른 브렌치로 전송하기 때문에 기존의 기록을 제거합니다. 이 과정에서 원치 않는 기록이 제거됩니다.

리베이스는 변경 사항이 계층 구조의 맨 위에서 아래로 전달되는 방식이며, 머지는 변경 사항이 다시 위로 흐르는 방법입니다.

마스터 브렌치에서 피처로 리베이스

장점

• 복잡해졌을 수도 있는 기록을 간소화한다
• 단일 커밋을 조작하기 쉽다(예: 되돌리기)
• 여러 브렌치가 있는 분주한 리퍼지토리에 머지 커밋 "노이즈"를 방지한다
• 중간 커밋을 단일 커밋으로 만들어 정리하고, 이는 DevOps 팀에 도움이 된다

단점

• 소수의 커밋으로 기능을 축소하면 내용이 숨겨질 수 있다
• 공용 리퍼지토리를 리베이스하는 것은 팀으로 작업할 때 위험할 수 있다
• 리베이스로 피처 브렌치를 항상 업데이트해야 하므로 더 많은 작업을 해야 한다
• 리모트 브렌치로 리베이스하려면 강제 푸쉬가 필요하다. 사람들이 직면하는 가장 큰 문제는 강제 푸시를 하지만 git push 기본값을 설정하지 않는 것이다. 이에 따라 로컬과 리모트 모두에서 동일한 이름을 가진 모든 브렌치가 업데이트되고, 이 문제는 처리하기가 매우 어렵다.

부정확하게 리베이스하다가 의도치 않게 기록을 재작성하면, 심각한 문제로 이어질 수 있으니, 리베이스 작업을 시도하기 전에 반드시 다시 한 번 확인하세요!

사용 방법

다음 명령을 사용해 피처 브렌치를 마스터 브렌치로 리베이스합니다.

$ git checkout feature
$ git rebase master

이렇게 하면 전제 피처 브렌치가 마스터 브렌치 위로 이동합니다. 원래(피처) 브렌치의 각 커밋에 대해 완전히 새로운 커밋을 만들어 프로젝트 기록을 다시 작성해 이를 수행합니다.

인터렉티브한 리베이스

Interactive 리베이스는 커밋이 새로운 브렌치로 이동할 때 커밋을 변경할 수 있습니다. 이는 브렌치의 커밋 기록을 완벽하게 제어할 수 있기 때문에 자동화된 리베이스보다 강력합니다. 일반적으로 피처 브렌치를 마스터에 머지하기 전에 지저분한 기록을 정리하는 데 사용됩니다.

$ git checkout feature
$ git rebase -i master

이 명령은 에디터를 열어 이동하려는 모든 커밋을 나열합니다. 아래 코드블록 같이 말이죠.

pick 22d6d7c Commit message#1
pick 44e8a9b Commit message#2
pick 79f1d2h Commit message#3

나열된 커밋의 내용과 순서는 리베이스가 수행된 후에 브렌치 이력이 어떻게 보일지 보여줍니다. 커밋들을 재정렬해 원하는 대로 기록을 표시할 수 있습니다. 예를 들어, pick 대신 fixup, squash, edit과 같은 명령어를 사용할 수 있습니다.

둘 중에 무엇을 선택해야 할까

그래서 뭐가 제일 좋을까요? 전문가들이 무엇을 추천할까요?

모든 팀이 다르기 때문에, 하나가 더 좋다고 일반화하고 결정하는 것은 어렵습니다. 하지만 일단 결정을 해야 뭐라도 시작하겠죠?

각 팀은 깃 리베이스와 머지를 사용할 상황을 정할 때 질문 몇 가지를 고려해야 합니다. 결과적으로 하나의 워크플로우 전략이 다른 하나보다 나은 것이 아니기 때문입니다. 그것은 당신의 팀에 따라 다릅니다.

조직 전체의 리베이스 및 깃 역량 수준을 고려해 봅시다. 머지의 추적 가능성 및 기록과 비교해 리베이스의 단순성을 어느 정도 중요시 하는지 결정합니다.

마지막으로, 머지와 리베이스에 대한 결정은 명확한 브렌치 전략의 맥락에서 고려되어야 합니다. (브렌치 전략에 대한 자세한 내용은 이 문서를 참조하세요). 성공적인 브렌치 전략은 팀 조직을 중심으로 설계됩니다.

제가 추천하는 방법은?

팀이 성장함에 따라, 항상 머지를 사용한다면 이후 개발 변경 사항을 추적하거나 관리하기가 어려워집니다. 깨끗하고 이해하기 쉬운 커밋 기록하기 위해서는, 리베이스를 사용하는 것이 효과적이고 합리적입니다.

다음 상황과 지침을 고려하면, 리베이스를 최대한 활용할 수 있습니다.

• 로컬에서 개발 중인 경우: 다른 사람과 작업을 공유하지 않은 시점에는 기록을 깔끔하게 유지하려면 머지보다 리베이스를 선호해야 합니다. 리퍼지토리의 개인 포크가 있고 다른 개발자와 공유되지 않는 경우, 당신의 브렌치를 푸쉬한 후에도 안전하게 리베이스 할 수 있습니다.
• 코드리뷰할 준비가 된 경우: pull request(PR)을 생성했거나 다른 사람들이 당신의 작업을 검토하기 위해 해당 작업을 본인의 로컬 저장소로 포크할 가능성이 있다면, 그 시점에서는 작업을 리베이스를 해서는 안 됩니다. '재작업' 커밋을 만들고 피쳐 브렌치를 업데이트해야 합니다. 이렇게 하면 PR의 추적 가능성에 도움이 되며 우발적인 기록 손상을 방지합니다.

-검토가 완료됐으며 타겟 브레치에 통합될 준비가 된 경우: 축하합니다! 당신의 피처 브렌치를 삭제하려고 합니다. 이 시점부터 다른 개발자가 변경 사항을 패치-머지하지 않을 것이라는 점을 감안할 때, 이는 당신의 기록을 정리할 기회입니다. 이 시점에서 기록을 재작성하고 원래 커밋과 성가신 'pr 재작업'과 '머지' 커밋을 작은 집중 커밋 집합으로 만들 수 있습니다. 이러한 커밋에 대한 명시적인 머지를 만드는 것은 선택 사항이지만 그럴만한 가치가 있습니다. 이는 피쳐가 마스터로 전환된 시점을 기록합니다.

마치며

이 글이 깃 머지와 깃 리베이스에 대한 이해도를 높였기를 바랍니다. 머지 혹은 리베이스 방식을 사용할지는 항상 논쟁의 여지가 있습니다. 그러나 이 글이 여러분의 의구심을 해소하고 팀에 맞는 접근 방식을 채택하는 데 도움이 되기를 바랍니다.

깃 워크플로우와 깃에 대한 글을 기대하고 있습니다. 다음에 제가 쓰길 원하는 주제가 있으면 댓글 달아주세요. 감사합니다!

소프트웨어 개발자를 위한 코딩 스쿨

브랜치는 이미 프로덕션에 있는 코드를 함부로 변경하지 않으면서 작업할 수 있도록 해주는 깃의 필수적인 부분입니다.

다른 브랜치에서 작업을 마친 후 main 브랜치에 병합(merge, 이하 머지)하여 방금 통합한 기능이나 버그 수정을 반영하고자 할 것입니다.

만약 작업을 더 해야 했다는 사실을 머지 완료 후 알아차렸다면, 혹은 실수로 머지를 했다면 어떻게 해야할까요?

깃에서는 거의 모든 것을 되돌릴 수 있습니다. 이 글에서는 마지막으로 커밋한 상태로 되돌릴 수 있도록 머지를 실행 취소하는 방법을 보여드리겠습니다.

깃에서 머지 커밋을 실행 취소하는 방법

깃의 reset command to undo a merge.

우선, 커밋 hash (혹은 id)를 확인해야 이전의 커밋으로 돌아갈 수 있습니다.

hash를 확인하기 위해서는 git log 혹은 git reflog를 실행하세요. 더 읽기 쉬운 git reflog가 더 나은 옵션이 될 수 있습니다.

되돌리려는 커밋의 hash를 얻었다면, git reset --hard commit-before-the-merge를 실행하세요:

명령을 실행하면 코드 에디터에서 몇 가지 항목이 제거되는 것을 보게 될 것입니다.

마지막 커밋의 hash가 명확하지 않다면, git reset --hard HEAD~1을 실행하여 머지 이전 커밋으로 돌아갈 수 있습니다:

유의해야 할 점은 --hard 플래그를 사용하여 머지 실행 취소할 경우, 커밋되지 않은 모든 변경 내용이 되돌려진다는 것입니다.

깃에서 머지를 되돌리는 더 좋은 방법

깃에서는 커밋되지 않은 변경 사항을 되돌리는 위의 방법을 보완하여 더 안전한 --merge 플래그를 제공합니다.

--merge 를 사용하여 머지를 실행 취소하려면 git reflog 를 실행하여 커밋의 hash를 확인한 다음 git reset --merge previous-commit을 실행하세요:

--merge 플래그와 더불어 HEAD 키워드를 사용한 git reset --merge HEAD~1 명령어도 쓸 수 있습니다:

참고: --merge 플래그를 쓸 때 해당 명령에 대한 응답을 받지 못하더라도 걱정하지마세요. 작동은 제대로 합니다.

마치며

지금까지 깃을 더 효율적으로 사용할 수 있도록 실수로 혹은 원치 않은 머지를 실행 취소하는 방법을 배웠습니다.

--hard 플래그는 커밋되지 않은 변경 사항을 제거하고, --merge 플래그는 커밋되지 않은 변경 사항을 유지한다는 것이 머지 되돌리기의 요점입니다.

읽어주셔서 감사합니다!

저는 최근에 한 동료의 멘토가 되었습니다. 그리고 제 멘티가 깃(Git)에 대해 몇 가지 상황을 물어보았습니다. 이 글은 제 동료를 위한 것입니다! 추신: 우리가 시작할 때 이 글을 썼어야 하는건데 이제 지금이라도 도움되길 바랍니다!

그리고 기억하세요: 어떤 것을 배우기 위한 가장 좋은 방법은 스스로 해 보는 것입니다. 그리고 내 멘토는 언제나 내게 말하곤 합니다: Udaraj!

기초(Basics)

그래서 왜 깃(Git)이 그렇게 중요할까요?

먼저, 깃의 위키피디아 페이지 첫번째 줄을 인용해서 시작해 봅시다:

"_*깃([긷])*은 컴퓨터 파일의 변화를 추적하고 여러 사람들 사이에서 그 파일을 조정하는 버전 관리 시스템입니다._"

이것은 다시 말해서 깃의 가장 기본적이고 중요한 기능이 여러 팀에게 동시에 같은 프로젝트로 코드를 더하게 (그리고 통합)하게 허용한다는 걸 의미합니다. 이러한 능력을 프로젝트에 더함으로써 팀을 더 효율적이게 하고 더 큰 규모의 프로젝트나 더 복잡한 문제들에 일할 수 있는 능력을 제공합니다.

깃이 정말 잘하는 또 다른 많은 것들이 있습니다: 변경점을 원복, 새로운 기능을 더하기 위한 새 브랜치(branches) 생성, 병합 시 발생하는 충돌(conflict) 해결 등을 허용합니다.

깃이 동작하는 법

깃은 저장소(repositories) 안에 프로젝트를 저장합니다. **커밋(Commits)**이 프로젝트로 만들어지면 깃에게 여러분이 생성한 새로운 코드나 변경한 코드에 대해 만족하는지 말해줄 것입니다.

새로운 코드/변경점들은 브랜치에 커밋됩니다. 대부분의 일은 다른 브랜치에 커밋되고 그 다음 마스터 브랜치로 병합됩니다. 이에 대한 모든 것은 프로젝트로 같은 디렉토리(directory) 안이지만 .git이라고 불리는 하위 폴더 안에 저장됩니다.

동료와 코드를 공유하기 위해서는 여러분이 저장소로 변경점을 **푸쉬(push)**합니다. 동료로부터 새로운 코드를 얻어오려면 저장소로부터 변경점을 **풀(pull)**합니다.

그러면 GitHub, GitLab, Bitbucket은 무엇일까요?

질문해줘서 고마워요! 이러한 종류의 어플리케이션들은 저장소 관리(repository management) 서비스라고 불립니다. 현대 소프트웨어 개발에 중요한 역할을 수행합니다.

깃과 깃허브가 많은 회사들에서 지향하는 버전 관리 솔루션입니다만, 깃허브는 GitLab이나 Bitbucket과 같은 강력
한 경쟁자들을 가집니다. 하지만 만약 깃허브를 사용하는 방법을 알고 있다면 GitLab이나 Bitbucket으로 일하는데 아무 문제가 없을 것입니다.

그래서 요점은: 깃은 도구이고 깃허브는 깃을 사용하는 프로젝트를 위한 서비스입니다.

흥미로운 프로젝트를 탐색하고 다른 개발자들과 연결하려면 어디로 가야할까요?

깃허브, GitLab, Bitbucket은 공용 저장소 검색 기능과 다른 사용자들을 쉽게 팔로우 가능하게 하는 기능을 가지고 있습니다.

이제 어째서 왜 깃과 깃허브(또는 GitLab/Bitbucket)이 중요한지 보이시나요? 명령어에 대해 이야기 하기 전에 이야기 드릴 남은 한가지는 깃을 사용할 때 항상 따라야 하는 몇 가지 간단한 규칙입니다:

• 규칙 1: 모든 새로운 프로젝트마다 깃 저장소를 생성하라
• 규칙 2: 모든 새로운 기능마다 새로운 브랜치을 생성하라

명령어

깃을 시작하기 위해서는 컴퓨터에 반드시 깃을 가지고 있어야 합니다. 설치하지 않았다면 여기로 가서 지시사항들을 따라하면 됩니다.

새로운 깃 저장소 초기 설정: Git init

모든 코드 내용은 저장소 안에 추적됩니다. 깃 저장소를 초기 설정하려면 해당 프로젝트 폴더 안에 이 명령어를 사용하세요. 이것이 .git 폴더를 만들어 줄 것입니다.

git init

Git add

이 명령어는 하나 또는 모든 변경 파일들을 본 무대 영역으로 더합니다.

어떤 하나의 특정 파일을 올리기 위해서는:

git add filename.py

신규 또는 수정되거나 삭제된 파일들을 올리기 위해서는:

git add -A

신규 또는 수정 파일들을 올리기 위해서는:

git add .

수정 또는 삭제된 파일들을 올리기 위해서는:

git add -u

Git commit

이 명령어는 버전 이력을 파일 안에 기록합니다. -m이 뜻하는 것은 어떤 커밋 메세지가 뒤따른다는 의미입니다. 이 메세지는 커스텀이며 반드시 이것을 동료에게 알리는 용도로 또는 미래의 스스로에게 무엇이 해당 커밋 안에 더해졌는지 알리기 위해 사용해야 합니다.

git commit -m "your text"

Git status

이 명령어는 파일들을 초록색과 빨간색으로 리스트해 줄 것입니다. 초록색 파일들은 무대로 올려졌지만 아직 커밋되지 않은 것들입니다. 빨간색으로 표시된 파일들은 무대로 아직 올려지지 않은 것들입니다.

git status

브랜치에 작업하는 것

Git branch branch_name

이것은 새 브랜치를 생성합니다:

git branch branch_name

Git checkout branch_name

어떤 브랜치에서 다른 브랜치로 변경하려면:

git checkout branch_name

Git checkout -b branch_name

새로운 브랜치를 생성하고 그것으로 자동 전환하려면:

git checkout -b branch_name

이것은 간략하게:

git branch branch_name
git checkout branch_name

입니다.

Git branch

모든 브랜치를 리스트하고 현재 어떤 브랜치에 있는지 확인하려면:

git branch

Git log

이 명령어는 현재 브랜치에서 모든 버전 이력을 리스트해줄 것입니다:

git log

Push와 Pull

Git push

이 명령어는 커밋된 변경점들을 원격 저장소에 보냅니다:

git push

Git pull

원격 저장소에서 개인 컴퓨터로 변경점들을 가져오려면:

git pull

더 많은 명령어들과 해당 목록에 대한 상세 설명들을 알고 싶다면 공식 깃 문서를 확인하길 추천합니다.

유용한 정보 (Tip & Tricks)

커밋되지 않은 모든 변경점을 보낼 때

문자 그대로 이 명령어는 커밋되지 않은 모든 변경점을 보냅니다:

git reset --hard

개인 컴퓨터에서는 삭제하지 않고 깃에서만 파일을 삭제

종종 "git add" 명령어를 사용하면서 추가하지 않고 싶어했던 파일을 더해버릴 수도 있습니다.

"git add"를 사용하는 동안 주의하지 않는다면 커밋하기 원하지 않았던 파일을 더하게 될지도 모릅니다. 파일의 기록 버전(staged version)을 반드시 삭제해야 하고, 그리고나서 파일에 .gitignore를 추가하여 같은 실수를 두번 하는 일을 방지할 수 있습니다:

git reset file_name
echo filename >> .gitignore

커밋 메세지 수정

커밋 메세지를 수정하는 건 굉장히 쉽습니다:

git commit --amend -m "New message"

지금까지 읽어주셔서 감사합니다! 저의 freeCodeCamp 프로필에서 더 많은 글을 확인하세요: https://www.freecodecamp.org/news/author/goran/ 그리고 제 깃허브 페이지에 만들어둔 재미있는 것들을 확인해 보세요: https://github.com/GoranAviani

이 글에서는 아무 변경 사항도 만들지 않는 커밋을 Git에 푸시하는 방법에 대해 이야기 할 것입니다.

Git을 이용하면 아주 쉽게 비어있는 커밋을 푸시할 수 있습니다. --allow-empty 플래그를 추가한다는 점을 제외하면 일반 커밋을 푸시하는 것과 같습니다.

git commit --allow-empty -m "Empty-Commit"

이제 이것을 메인 디렉터리에 푸시해야 합니다. 다음 명령을 통해 푸시할 수 있습니다.

git push origin main

위 명령을 실행한 후, 변경 사항이 없는 커밋이 브랜치에 푸시된 것을 확인할 수 있습니다.

왜 비어있는 커밋을 푸시해야 하나요?

프로젝트를 변경하지 않고 빌드를 시작해야 할 수도 있습니다. 또는 빌드를 수동으로 시작할 수 없을 수도 있습니다. 이때 빌드를 시작하는 유일한 방법은 Git을 사용하는 것입니다. 빈 커밋을 푸시해 프로젝트를 수정하지 않고 빌드를 시작할 수 있습니다.

끝입니다! 정말 쉽지 않나요? 🥳

저는 정기적으로 뉴스레터도 씁니다. 여기서 바로 구독할 수 있습니다. 👇👇

git checkout 명령어는 브랜치 간 전환 또는 현재 작업 중인 파일들을 복원할 때 사용됩니다. 이 명령에는 여러 가지 옵션이 있지만 이 글에서 다루지 않을 것이며, git 문서에서 모든 옵션을 확인할 수 있습니다.

특정 커밋으로 체크아웃하는 방법

특정 커밋으로 이동하려면 다음 명령어를 실행하세요.

git checkout specific-commit-id

특정 커밋 ID는 다음 명령을 실행하여 확인할 수 있습니다.

git log

기존 브랜치로 체크아웃하는 방법

기존 브랜치로 이동하려면 다음 명령을 실행하세요.

git checkout BRANCH-NAME

보통 Git을 사용할 때, 작업하고 있던 디렉토리에서 커밋되지 않은 변경 사항이 있는 경우 다른 브랜치로 이동할 수 없습니다. 이는 커밋되지 않은 파일들이 손실되기 때문입니다. 이 경우 변경 사항을 처리하기 위해서는 1. 삭제하거나, 2. 커밋하거나, 3. 스태시(Stash: 아직 커밋하지 않은 변경 사항들을 임시로 저장하는 Git의 기능 —옮긴이)해야 합니다.

새로운 브랜치로 체크아웃하는 방법

새로운 브랜치 생성과 동시에 해당 브랜치로 이동하는 명령어를 실행하려면 다음과 같이 입력합니다.

git checkout -b NEW-BRANCH-NAME

이 명령어를 실행하면 바로 새로운 브랜치로 전환됩니다.

새로운 브랜치로 체크아웃하거나 브랜치를 시작점으로 재설정하는 방법

다음 명령은 새 브랜치를 만드는 것과 유사하지만 -B (대문자 B에 주목) 플래그와 선택적인 START-POINT 매개변수를 사용합니다.

git checkout -B BRANCH-NAME START-POINT

만약 BRANCH-NAME이라는 브랜치가 존재하지 않으면, Git은 START-POINT에서 브랜치를 만들고 시작합니다. 만약 BRANCH-NAME이라는 브랜치가 이미 존재한다면, Git은 브랜치를 START-POINT로 재설정합니다. 이것은 -f (force의 약자. 강제로 실행하는 명령어 — 옮긴이) 옵션을 사용하여 git branch를 실행하는 것과 동일합니다.

체크아웃을 강제로 실행하기

작업 디렉토리의 인덱스가 HEAD와 다르면 (즉, 스테이징하지 않은 변경 사항이 있으면), git checkout 명령에 -f 또는 --force 옵션을 전달하여 Git이 브랜치를 전환하도록 강제할 수 있습니다. 기본적으로, 이는 로컬 변경 사항을 삭제하는 데 사용될 수 있습니다.

다음 명령을 실행하면 Git은 병합되지 않은 항목을 무시합니다.

git checkout -f BRANCH-NAME

# Alternative
git checkout --force BRANCH-NAME

작업 디렉토리에서 변경 내용 되돌리기

git checkout 명령을 사용하여 작업 디렉토리에서 파일을 변경한 내용을 되돌릴 수 있습니다. 이는 파일을 HEAD의 버전으로 되돌립니다.

git checkout -- FILE-NAME

Git에는 저장소에 커밋하지 않고 작업한 내용의 스냅샷을 임시 저장할 수 있는 stash라는 영역이 있습니다. Stash 영역은 Git 사용자가 흔히 알고 있는 워킹 트리(Working Tree/Working Directory), 스테이징 영역(staging area), 또는 저장소(repository)와는 별개입니다.

이 기능은 해당 브랜치에 커밋할 준비가 되지 않은 변경 사항을 작업한 상태에서 다른 브랜치로 전환해야 할 때 유용합니다. (Stash는 영어로 안전한 곳에 무언가를 넣어두거나 숨긴다는 의미입니다. --옮긴이).

작업한 내용을 stash(임시 저장) 하기

변경 사항을 stash 영역에 저장하려면 다음과 같은 명령어를 실행합니다.

git stash save "<사용자 옵션(optional message)>"

이 명령어를 실행하면 작업한 내용이 임시 저장되고, 워킹 트리가 최신 커밋이 적용된 시점으로 되돌아갑니다. Stash된 변경 사항은 해당 저장소의 모든 브랜치에서 접근할 수 있습니다.

여기서 중요한 점 한 가지는 저장할 변경 사항은 tracked file(즉, Git 저장소에서 변경 사항을 추적하고 있는 상태의 파일 --옮긴이)에 있어야 한다는 사실입니다. 새 파일을 만든 후 변경 사항을 stash하려고 하면 저장할 로컬 변경 사항이 없다는 의미의 (No local changes to save)에러가 발생할 수 있습니다.

(git stash --include-untracked라는 명령어를 실행하면 untracked file도 stash가 가능합니다. --옮긴이)

Stash한 변경 사항 확인하기

Stash 영역에 무엇이 있는지 확인하려면 다음 명령어를 실행합니다.

git stash list

명령어가 실행되면 임시 저장된 스냅샷의 목록을 stash@{0}: On <stash한 내용이 담긴 브랜치 이름: 사용자 선택 메시지>형식으로 반환합니다. stash@{0}부분은 해당 stash의 이름이고, 중괄호({ }) 안의 숫자는 해당 stash의 인덱스입니다. Stash 영역에 여러 개의 변경 사항을 저장한 경우 각 임시 저장의 인덱스가 다릅니다.

Stash 영역에 어떤 내용이 임시 저장되었는지 잊어버린 경우에는 git stash show <STASH 이름>로 요약을 확인할 수 있습니다. 일반적인 diff-style의 패치 레이아웃(라인별 변경 사항을 +와 -기호로 표시된)으로 변경 사항을 확인하고 싶다면, 명령어에 패치라는 의미의 -p 플래그를 포함하면 됩니다. 예시를 확인해보시죠.

git stash show -p stash@{0}

# 예시 결과물:
diff --git a/PathToFile/fileA b/PathToFile/fileA
index 2417dd9..b2c9092 100644
--- a/PathToFile/fileA
+++ b/PathToFile/fileA
@@ -1,4 +1,4 @@
-현재 브랜치에 보이는 내용 
+stash된 변경 사항이 반영된 내용

Stashed된 내용을 불러오기

Stashed된 내용을 불러오고 현재 체크아웃된 브랜치에 적용하려면 두 가지 방법이 있습니다.

1. git stash apply <STASH-이름>명령어는 변경 사항을 적용하고 해당 내용의 복사본을 stash 영역에 남깁니다.
2. git stash pop <STASH-이름>명령어는 변경 사항을 적용하고 적용된 파일을 stash 영역에서 삭제합니다.

변경 사항을 적용할 때 충돌이 발생할 수 있습니다. 이때 병합 충돌(merge conflict)과 유사한 방법으로 충돌을 해결할 수 있습니다(git merge에 관한 아티클을 확인해보세요).

Stash된 작업 내용 삭제하기

Stash된 내용을 브랜치에 적용하지 않은 상태에서 삭제하려면 다음 명령어를 실행합니다.

git stash drop <STASH-이름>

Stash 영역에 있는 모든 내용을 삭제하려면 다음과 같은 명령어를 실행합니다.

git stash clear

Git에서 코드 작업을 하고 있는데 계획대로 되지 않아서 가장 최근 커밋을 되돌려야 한다고 가정해봅시다. 어쩌면 좋을까요? 방법에 대해 알아봅시다!

마지막 커밋을 취소할 수 있는 두 가지 방법이 있습니다. 이 글에서는 이 두 가지를 모두 살펴보겠습니다.

revert 명령어

revert 명령어는 취소하고 싶은 특정 커밋의 내용을 되돌리는 새로운 커밋을 만듭니다. 이 명령어를 사용하여 다음과 같이 마지막 커밋을 되돌릴 수 있습니다:

git revert <되돌리고 싶은 커밋 이름>

git log를 사용하여 되돌릴 커밋의 이름을 찾을 수 있습니다. 여기에 설명된 첫 번째 커밋은 마지막으로 생성된 커밋입니다. 그런 다음, 찾아낸 영숫자 이름을 복사하여 revert 명령어에 사용할 수 있습니다.

reset 명령어

reset 명령어를 사용해 마지막 커밋을 실행 취소할 수도 있습니다. 그러나 주의해야할 점은 커밋 기록이 변경되기 때문에 거의 사용하지 않아야 합니다. 작업 지점인 HEAD를 지정된 커밋으로 이동하고, 그 이후의 모든 항목을 폐기합니다:

git reset --soft HEAD~1

--soft 옵션은 커밋되지 않은 변경사항이 손실되지 않음을 의미합니다.

가장 최근 커밋으로 되돌리고 unstaged 상태의 변경 사항을 모두 제거하려면 --hard 옵션을 사용할 수 있습니다:

git reset --hard HEAD~1

이렇게 하면 최신 커밋뿐만 아니라 커밋되지 않은 변경 사항도 취소됩니다.

Git에서 언제 reset 또는 revert를 사용해야 할까요?

되돌려야 하는 커밋이 로컬에만 존재하는 경우에만 reset 명령어를 사용해야 합니다. 이 명령어는 해당 커밋을 아예 삭제하고 커밋 기록을 변경하기 때문에 같이 협업하고 있는 다른 팀원의 작업에도 영향을 끼치기 때문입니다. (협업하는 프로젝트 브랜치에 reset 을 실행하면 다른 팀원이 새로운 커밋을 push할 때 브랜치에 충돌이 납니다 --옮긴이 주석.)

revert는 변경 내용을 취소하는 새 커밋을 생성하므로, 되돌리려는 커밋이 이미 원격 저장소로 푸쉬된 경우에는 커밋 기록을 덮어쓰지 않는 revert 명령어를 사용하는 것이 가장 좋습니다.

마치며

마지막 커밋을 취소하는 두 가지 방법과 언제 어떤 방법을 사용하는 것이 가장 좋은지를 배웠습니다.

이제 마지막 커밋이 버그를 유발하거나 커밋하지 말았어야 하는 내용이 있다는 것을 알게 되면 어떻게 고치는지 아시겠죠?

Git은 많은 이들의 사랑을 받고 있는 버전 관리 시스템이자 웹 개발자의 필수 도구입니다.

브랜치(branch)는 Git이 제공하는 강력하고 중요한 기능 중 하나입니다.

이번 기사에서는 Git의 로컬 및 원격 브랜치를 삭제하는 기본적인 방법을 다뤄보겠습니다.

브랜치란

브랜치는 커밋을 가리키는 포인터(pointer)입니다.

Git 브랜치는 특정 시점에서의 프로젝트 변경이력을 기록하는 스냅숏입니다. (스냅숏(snapshot)은 특정 시점에 프로젝트 파일의 상태를 마치 사진 찍듯이 저장해 기록하는 기술을 의미합니다. - 옮긴이)

규모가 큰 프로젝트의 소스 코드를 관리할 때, 기준이 되는 기본 저장소를 main 또는 master라고 부릅니다(최근 master란 단어가 노예제를 연상시킨다는 이유로 기본 저장소를 main으로 부르는 것을 권장하고 있습니다. - 옮긴이).

브랜치는 작업 중인 프로젝트의 독립적인 버전을 따로 만들 수 있는 기능을 제공합니다. 프로젝트를 진행하다 보면 코드 수정, 새 기능 추가, 디버깅을 위한 테스트 작성 등과 같은 작업이 필요합니다. 이와 같은 작업을 새로 생성한 브랜치에서 진행하면 메인 소스 코드를 안전하게 보호할 수 있습니다.

다시 말해, 브랜치를 활용하면 변경 사항을 적용할 준비가 완벽하게 되기 전까지 메인 소스 코드에 그 어떤 영향을 주지 않으면서도 다양한 작업을 진행할 수 있습니다.

브랜치를 이용한 작업을 하면 코드베이스를 깔끔하고 일목요연하게 유지할 수 있습니다.

브랜치를 삭제하는 이유

프로젝트에서 코드의 변경 사항을 저장하기 위해 브랜치를 만들었다고 가정해봅시다.

그렇지만 해당 브랜치의 변경 사항이나 새 기능을 프로젝트의 본 버전에 반영 완료한 후에는 해당 브랜치를 유지할 필요가 없어집니다. 따라서 프로젝트 저장소가 복잡해지지 않도록 작업이 완료된 브랜치는 삭제하는 것이 일반적입니다.

로컬 브랜치 삭제하기

로컬 브랜치는 작업자 본인의 컴퓨터에 있는 브랜치이기 때문에 원격 브랜치에 영향을 끼치지 않습니다.

로컬 브랜치를 삭제하는 명령어는 다음과 같습니다.

git branch -d <로컬 브랜치 이름> 

• git branch는 로컬 브랜치를 삭제하는 명령어입니다.
• -d는 --delete의 약자이며 위 명령어에 추가할 수 있는 선택적 플래그입니다. 무언가를 삭제하고 싶다는 의미를 담고 있는 플래그입니다.
• <로컬 브랜치 이름>은 삭제하고 싶은 로컬 브랜치를 가리킵니다.

예시를 통해 git branch 명령어 활용법을 더 자세히 살펴봅시다.

우선 로컬 브랜치 목록을 확인하기 위해 다음 명령어를 사용합니다.

git branch 

이 예시에는 main, test2라는 두 로컬 브랜치가 있습니다. (*)는 현재 test2 브랜치에서 작업 중이라는 것을 의미합니다.

이때 test2 브랜치를 삭제하고 싶어도 현재 작업 중인 브랜치는 삭제할 수 없습니다.

삭제를 시도하면 다음과 같은 에러가 발생합니다.

따라서 로컬 브랜치를 삭제하기 전에 git checkout 명령어를 사용해 삭제 대상이 아닌 다른 브랜치로 전환해야 합니다.

git checkout <브랜치 이름>

• <브랜치 이름>은 전환하고 싶은 브랜치입니다
• main 브랜치로 전환하려면 명령어가 다음과 같습니다.
• git checkout main

명령어를 실행하면 다음과 같은 메시지가 나타납니다.

이제 원하는 브랜치를 삭제할 수 있습니다.

브랜치에 병합되지 않은 변경 사항 및 푸시되지 않은 커밋이 있는 경우 -d 플래그를 사용해 로컬 브랜치를 삭제할 수 없습니다.

브랜치가 가지고 있는 커밋이 다른 브랜치 혹은 저장소에 기록되어 있지 않을 경우, 커밋 기록이 실수로 손실되는 것을 Git이 방지하기 때문입니다.

만일 이러한 상황에서 git branch -d 명령어를 실행하면 다음과 같은 에러가 발생합니다.

따라서 해당 브랜치를 삭제하려면 에러 메시지에 제시된 것처럼 -D 플래그를 사용해야 합니다.

git branch -D <로컬 브랜치 이름>

대문자 "D"가 있는 -D 플래그는 --delete --force(강제 삭제)의 줄임말이며, 병합 여부와 관계없이 로컬 브랜치를 강제로 삭제합니다.

브랜치 삭제 여부를 재확인하는 절차가 따로 없으므로 이 명령어는 주의해서 사용해야 합니다.

로컬 브랜치를 확실히 삭제하려는 경우에만 사용해야 한다는 점을 잊지 마세요.

다른 브랜치로 변경 이력을 병합하거나 코드 베이스의 원격 브랜치로 푸시하지 않은 상태에서 로컬 브랜치를 삭제하면 변경 사항이 손실될 위험이 있습니다.

원격 브랜치 삭제하기

원격 브랜치와 로컬 브랜치는 독립적인 별개의 개체입니다.

작업자의 컴퓨터에 저장되어 있는 로컬 브랜치와 달리, 원격 브랜치는 원격 서버에 저장되어 있으며 원격 서버를 통해 접근할 수 있습니다.

원격 브랜치를 삭제하는 명령어는 다음과 같습니다.

git push <원격 저장소 이름> -d <원격 브랜치 이름>

• 로컬 브랜치를 삭제하는 git branch 명령어를 사용하는 대신 git push 명령어를 이용해 원격 브랜치를 삭제해야 합니다.
• git push 명령어 다음에 원격 저장소의 이름을 전달해야 합니다. 대부분은 origin입니다.
• -d 플래그는 삭제라는 의미를 가진 --delete의 줄임말입니다.
• <원격 브랜치 이름>은 삭제하고 싶은 원격 브랜치입니다.

예시를 통해 원격 브랜치를 삭제하는 과정을 살펴봅시다.

원격 브랜치 목록을 확인하려면 다음과 같은 명령어를 사용해야 합니다.

git branch -a

-a 플래그(모두란 의미를 가진 --all의 줄임말)를 사용하면 로컬, 원격 브랜치를 모두 확인할 수 있습니다.

위의 예시에서는 main, test2라는 두 개의 로컬 브랜치와 origin/main, origin/test2라는 두 개의 원격 브랜치가 있다는 것을 확인할 수 있습니다.

--remotes의 줄임말인 -r 플래그를 사용하면 원격 저장소만 확인할 수 있습니다.

origin/test2 브랜치를 삭제하길 원한다면 다음과 같은 명령어를 사용해야 합니다.

git push origin -d test2

다음과 같은 메시지가 보일 거예요.

이렇게 origin 저장소에 있는 test2 브랜치가 삭제되었습니다!

git branch -r 명령어를 사용해 origin/test2 원격 저장소가 브랜치 목록에 더 이상 보이지 않다는 걸 확인할 수 있습니다.

마치며

이렇게 로컬, 원격 브랜치 삭제하는 방법을 배워보았습니다!

Git에 대해 더 알고 싶다면, freeCodeCamp의 유튜브 채널에서 다음과 같은 강의를 볼 수 있습니다.

• 초보자를 위한 GitꞏGitHub 단기 특강 강의 (영문)를 통해 기본적인 Git 사용법, 자주 사용하는 중요한 Git 명령어, 그리고 일반적인 Git 워크플로에 대한 개요를 배울 수 있습니다.
• Git 브랜치와 브랜치 작동법에 대해 좀 더 자세히 알아보고 싶다면 Git 브랜치 강의 (영문)를 시청해보세요.

이 기사를 읽어주셔서 감사하고 즐거운 학습 되시길 바랍니다!

Git은 프로젝트의 여러 버전을 관리하고 기록할 수 있는 버전 관리 시스템(version control system)입니다. 새로운 업데이트로 인해 앱에서 에러가 발생할 때 Git을 사용하면 앱을 이전 버전으로 되돌릴 수 있습니다.

Git을 통해 버전 관리 외에도 여러 환경에서 동시에 작업할 수 있습니다. 여기서 여러 환경이란 브랜치를 의미합니다.

브랜치의 필요성

Git에서 작업하면 main이라는 메인 브랜치가 있습니다. 이 특정 브랜치에는 앱이 제품으로 출시될 때 배포되는 소스 코드가 저장되어 있습니다.

앱을 업데이트하려는 경우 이 브랜치에 커밋 및 변경 사항을 추가할 수도 있습니다. 사소한 업데이트라면 크게 상관없을 수도 있지만, 규모가 큰 업데이트라면 이야기가 달라집니다. 바로 이때 브랜치 기능이 중요한 역할을 합니다.

터미널을 사용해 프로젝트 디렉터리에서 브랜치를 생성하려면 다음과 같은 명령어를 실행합니다.

# 새 브랜치 생성하기 
git branch 브랜치-이름
# 생성된 브랜치로 전환하기 
git checkout 브랜치-이름 

이제 새 브랜치에서 업데이트 작업을 진행할 수 있습니다. 그런 다음 작업을 마치면 main 브랜치와 병합할 수 있습니다.

브랜치의 또 다른 이점은 여러 개발자가 동일한 프로젝트에서 동시에 작업할 수 있다는 것입니다. 여러 개발자가 동일한 main 브랜치에서 작업한다면 문제점이 많습니다. 특히 각 개발자의 코드 간에 변경 사항이 너무 많아서 병합 충돌(merge conflict)이 자주 발생하게 됩니다.

Git을 사용하면 한 브랜치에서 작업을 진행하는 동안 다른 브랜치(즉, 다른 환경)에서 새 업데이트를 추가할 수 있습니다.

Git 원격 브랜치 체크아웃한다는 의미

Git으로 프로젝트를 시작하면 로컬 컴퓨터에 있는 로컬 main 브랜치와 GitHub와 같은 Git 지원 플랫폼에 있는 원격 main 브랜치라는 두 가지 환경을 줍니다.

로컬 main 브랜치에서 원격 main 브랜치로 변경 사항을 푸시할 수 있고, 원격 브랜치에서 변경 사항을 pull 명령어를 통해 로컬 브랜치로 가져올 수도 있습니다.

로컬 환경에서 브랜치를 생성하면 GitHub로 푸시되여 원격 브랜치가 될 때까지 로컬 환경에만 존재합니다. 다음 예시를 확인해봅시다.

예시:

# 새 브랜치 생성하기 
git branch 새-브랜치-이름
# 생성된 브랜치로 전환하기 
git checkout 새-브랜치-이름 
# 파일 추가하기 
touch new-file.js
# 수정사항 커밋하기 
git add .
git commit -m "새 파일 추가"
# 새 원격 브랜치로 푸시하기 
git push --set-upstream origin 새-브랜치-이름

위의 예시에서 origin 새-브랜치-이름은 원격 브랜치가 됩니다. 새 원격 브랜치로 푸시하기 전에 먼저 새 브랜치를 만들고 변경 사항을 커밋했다는 것을 눈치채셨나요?

하지만 이미 기존에 있는 원격 브랜치와 그 브랜치의 모든 변경이력을 로컬 환경으로 가져오려면 어떻게 할까요?

이때 원격 브랜치를 체크아웃하면 됩니다.

원격 브랜치 체크아웃하기

다른 개발자가 생성한 원격 브랜치의 내용을 로컬 환경에 가져오려면 다음과 같은 방법을 사용해야 합니다.

1. 모든 원격 브랜치 가져오기(fetch)

git fetch origin

이 명령어를 실행하면 원격 저장소의 모든 원격 브랜치를 로컬에 가져옵니다. 위 예시에서는 origin 원격 저장소의 데이터를 가져옵니다. upstream 원격 저장소의 브랜치를 가져오려면 git fetch upstream을 사용해야겠죠.

2. 체크아웃할 수 있는 브랜치 목록 보기

체크아웃할 수 있는 브랜치 목록을 보려면 다음과 같은 명령어를 실행합니다.

git branch -a

명령어를 실행하면 체크아웃할 수 있는 브랜치 목록이 출력됩니다. 원격 브랜치에는 remotes/origin 접두사가 붙은 것을 확인할 수 있습니다.

3. 원격 브랜치의 변경이력 가져와 병합하기(Pull)

원격 브랜치에는 직접 작업할 수 없습니다. 변경 사항을 추가하기 위해서는 원격 브랜치의 복사본이 필요합니다. 예를 들어 fix-failing-tests라는 원격 브랜치를 복사하고 싶다면 다음과 같은 명령어를 실행합니다.

git checkout -b fix-failing-tests origin/fix-failing-tests

이 명령어를 다음과 같은 세 동작이 실행됩니다.

• fix-failing-tests라는 새 브랜치를 생성하고,
• 새 브랜치로 체크아웃이 되며,
• origin/fix-falling-tests의 변경이력을 새 브랜치로 가져옵니다.

이제 원하는 원격 브랜치의 복사본이 있습니다. 해당 원격 브랜치에 커밋도 푸시할 수 있습니다. 바로 시도해 볼까요?

예시:

touch new-file.js
git add .
git commit -m "새 파일 추가"
git push

이렇게 하면 커밋된 변경 내용이 origin/fix-failing-tests로 푸시 됩니다. git push origin fix-failing-tests와 같이 커밋을 푸시할 원격 브랜치를 지정할 필요가 없이 git push 명령어만 실행했다는 것을 확인하셨나요? Git이 로컬 브랜치가 자동으로 원격 브랜치를 추적하도록 설정하기 때문입니다.

마치며

Git 브랜치를 통해 프로젝트 개발 작업을 진행하면서 수월하게 협업할 수 있습니다.

다시 말해, 브랜치를 활용하면 여러 개발자가 동시에 다양한 작업을 할 수 있습니다.

또한 원격 브랜치 체크아웃 기능을 사용하면 개발자가 로컬 환경에 원격 브랜치를 복사와 변경하기, 그리고 원격 브랜치로 푸시하기가 가능해지기 때문에 협업이 더욱 원활해집니다.

Git에서 자주 하는 일 중 하나는 브랜치 전환입니다.

브랜치 전환은 git checkout 명령어를 사용하면 됩니다.

새 브랜치 생성하기

새 브랜치를 만드려면 git checkout 명령어와 함께 -b 플래그와 새 브랜치 이름을 전달해야 합니다.

명령어가 실행되면 현재 작업 중인 브랜치에서 새 브랜치가 생성됩니다. 새 브랜치의 커밋 히스토리는 작업하고 있던 브랜치의 마지막 커밋에서 시작됩니다.

현재 작업 중인 브랜치가 main이라고 가정해봅시다.

(main)$ git checkout -b my-feature
Switched to a new branch 'my-feature'
(my-feature)$

main에서 my-feature라는 새 브랜치가 생성된 것을 확인할 수 있습니다.

Git에서 생성된 브랜치로 전환하기

다른 브랜치로 전환하려면 git checkout을 -b 플래그 없이 다시 사용합니다. 이동하고 싶은 브랜치의 이름을 명령어와 같이 전달합니다.

예시:

(my-feature)$ git checkout main
Switched to branch 'main'
(main)$

이전 브랜치로 돌아가려면 브랜치 이름 대신 -를 git checkout과 함께 사용하는 편리한 방법도 있습니다.

(my-feature)$ git checkout -
Switched to branch 'main'
(main)$ git checkout -
Switched to branch 'my-feature'
(my-feature)$

특정 커밋으로 이동하기

특정 커밋으로 이동하는 것도 git checkout로 가능합니다. 대신 브랜치 이름이 아닌 SHA(Secure Hash Algorithm, 안전한 해시 알고리즘)를 명령어와 함께 전달해야 합니다.

브랜치는 사실상 특정 커밋들을 기록하는 포인터 같은 개체이기 때문에 특정 커밋으로의 이동 또한 브랜치 전환과 크게 다르지 않습니다.

커밋 SHA 찾기

특정 커밋의 SHA를 찾는 한 가지 방법은 Git 로그를 조회하는 것입니다.

이때 git log 명령어를 사용합니다.

(my-feature)$ git log
commit 94ab1fe28727b7f8b683a0084e00a9ec808d6d39 (HEAD -> my-feature, main)
Author: John Mosesman <johnmosesman@gmail.com>
Date:   Mon Apr 12 10:31:11 2021 -0500

    This is the second commmit message.

commit 035a128d2e66eb9fe3032036b3415e60c728f692 (blah)
Author: John Mosesman <johnmosesman@gmail.com>
Date:   Mon Apr 12 10:31:05 2021 -0500

    This is the first commmit message.

각 커밋 기록의 첫 번째 줄에는 commit이라는 단어 뒤에 숫자와 문자가 조합된 긴 문자열이 있습니다: 94ab1fe28727...

이 문자열이 SHA입니다. SHA는 특정 커밋을 가리키는 고유 식별자입니다.

특정 커밋으로 이동하려면 커밋의 SHA를 git checkout 매개변수로 전달하면 됩니다.

예시:

(my-feature)$ git checkout 035a128d2e66eb9fe3032036b3415e60c728f692
Note: switching to '035a128d2e66eb9fe3032036b3415e60c728f692'.

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 false

HEAD is now at 035a128 a
((HEAD detached at 035a128))$

참고: 일반적으로 SHA 값의 앞 4-5자만으로도 저장소 안에서 특정 커밋을 충분히 식별할 수 있기 때문에 SHA의 앞 몇 글자로 줄여 써도 됩니다.

detached HEAD(떨어져나온 HEAD) 상태의 의미

특정 커밋을 체크아웃하면 "detached HEAD" 상태가 됩니다.

Git 설명서에 의하면:

[a detached HEAD state(떨어져나온 HEAD 상태)]는 `HEAD`가 특정 브랜치가 아닌 특정 커밋을 직접 참조하고 있는 상태를 말합니다.

HEAD는 Git 히스토리 안에서 사용자가 현재 어느 지점에 있는지 기록하는 Git의 내부 포인터 중 하나입니다. "Detached HEAD" 상태는 HEAD가 기존 브랜치에서 우회했다는 것을 의미합니다. 이 시점에서 새 변경 사항이 발생하면 Git 히스토리에서 새로운 경로가 생성됩니다.

Git은 사용자가 "detached HEAD" 상태에서 작업하고 싶다는 것을 확인하기 위해 실험적인 변경이 가능한 "여유 공간"을 제공합니다.

출력된 메세지에 의하면:

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.

한글 번역: 
현재 '떨어져나간 HEAD' 상태에 있습니다. 둘러보고 실험적 변경을 실행하고 커밋할 수 있습니다.
또한 브랜치 전환을 하면 다른 브랜치에 영향을 주지 않고 
'떨어져나간 HEAD' 상태 중 실행한 커밋을 취소할 수 있습니다.

이런 경우 두 가지 옵션이 있습니다.

• 실험한 다음 이전 브랜치로 돌아가 변경 사항을 취소하기
• 작업 후 이 지점부터 새 브랜치 생성하기

git switch 명령어를 통해 변경한 내용을 취소하고 이전 브랜치로 돌아갈 수 있습니다.

변경 이력을 유지한 상태로 작업을 계속하려면 git switch -c <새-브랜치-이름>를 사용해 현재 커밋 히스토리부터 시작하는 새 브랜치를 만들 수 있습니다.

요약

git checkout 명령어는 여러모로 유용한 명령어입니다.

이 명령어 하나로 브랜치 생성, 브랜치 전환, 특정 커밋 이동 등과 같은 작업이 가능합니다.

이 튜토리얼이 마음에 드셨다면, 제 트위터 계정과 사이트를 통해 이런 주제에 대한 글을 확인할 수 있습니다.

Git을 사용하며 개발 프로젝트를 진행하다 보면 로컬 브랜치의 이름을 변경해야 할 때가 있습니다.

이 기사에서는 Git에서 로컬 브랜치 이름을 변경하는 두 가지 방법을 소개합니다.

Git 브랜치 이름 변경하기: 첫 번째 방법

1. 프로젝트 루트 폴더로 이동하기

가장 먼저 터미널을 열고 프로젝트의 루트 폴더로 cd (change directory, 경로 변경)를 해야 합니다.

예를 들어, 홈 디렉터리에서 바탕 화면에 위치한 프로젝트로 이동할 경우 필요한 명령은 다음과 같습니다.

cd Desktop/project-name

아래는 Happy_Messages_Bot라는 이름의 프로젝트 폴더로 경로를 변경할 경우의 예시입니다.

2. 이름을 변경하려는 브랜치로 이동하기

git checkout 명령을 통해 다른 브랜치로 이동할 수 있습니다.

git checkout branch-name

아래와 같이 명령을 입력하면 test-branch라는 브랜치로 이동하게 됩니다.

3. -m 옵션으로 브랜치 이름 변경하기

브랜치 이름을 변경하는 명령은 다음과 같습니다:

git branch -m new-branch-name

두 번째 단계에서 이동해 온 test-branch 브랜치의 이름을 test-branch2로 변경해봅시다.

git branch -m test-branch2

git status 명령으로 브랜치의 변경된 이름을 확인해볼까요?

Git 브랜치 이름 변경하기: 두 번째 방법

한 번의 명령으로, 즉 git checkout을 사용하지 않고도 로컬 브랜치의 이름을 변경할 수 있습니다.

1. 현재 master/main 브랜치에 위치해 있는지 확인하기

먼저 git status 명령을 통해 master/main 브랜치에 위치해 있는지 확인합니다.

만일 다른 브랜치에 위치해 있다면 git checkout master 또는 git checkout main 명령을 통해 master/main 브랜치로 이동해줍니다.

2. -m 옵션으로 브랜치 이름 변경하기

다음과 같은 명령을 통해 현재 위치한 브랜치가 아닌 브랜치의 이름을 변경할 수 있습니다.

git branch -m old-branch new-branch

master/main 브랜치에서 test-branch 브랜치의 이름을 test-branch2로 변경해봅시다:

git branch -m test-branch test-branch2

git branch는 모든 브랜치를 나열해줍니다. 리스트 속에서 변경된 브랜치 이름을 확인할 수 있습니다.

이렇게 Git에서 로컬 브랜치 이름을 변경하는 방법 두 가지를 살펴봤습니다.

git push는 로컬 브랜치(local branch)를 원격 저장소(remote repository)로 푸시할 때 사용하는 기본 명령어입니다.

이 git push 명령어는 다양한 옵션과 매개변수를 가지고 있습니다. 이 기사에서는 그 중 자주 사용하는 옵션과 매개변수에 대해 설명합니다.

Git 로컬 브랜치를 원격 저장소로 푸시하기

기본 git push 명령어를 실행하면 Git는 푸시 동작을 행할 원격 저장소와 푸시할 로컬 브랜치의 두 매개변수를 기본값으로 설정합니다.

명령어의 기본 문법은 다음과 같습니다.

예시:

$ git push <remote> <branch>

사용자가 이 두 매개변수를 지정하지 않는다면 Git는 기본적으로 origin을 원격 저장소로, 현재 작업하고 있는 브랜치를 푸시할 브랜치로 지정합니다.

현재 작업 중인 브랜치가 main인 경우, git push 명령어는 두 개의 기본 매개변수를 제공하기 때문에 git push origin main과 동일하게 실행됩니다.

다음 예시에서는 origin은 GitHub 원격 저장소이고, 현재 작업 중인 브랜치는 main입니다.

(main)$ git remote -v 
origin  git@github.com:johnmosesman/burner-repo.git (fetch)
origin  git@github.com:johnmosesman/burner-repo.git (push)

(main)$ git push
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Delta compression using up to 16 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 274 bytes | 274.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To github.com:johnmosesman/burner-repo.git
   b7f661f..ab77dd6  main -> main

출력에서 로컬 main 브랜치가 원격 main 브랜치로 푸시된 것을 확인할 수 있습니다.

To github.com:johnmosesman/burner-repo.git
   b7f661f..ab77dd6  main -> main

Git 브랜치를 강제로 푸시(force push)하기

일반적으로 사용자는 원격 브랜치에 푸시하고 해당 커밋 기록에 변경 이력을 추가합니다.

하지만 간혹 브랜치 커밋 기록을 강제로 덮어써야 하는 경우가 있습니다.

강제 푸시를 실행하는 이유는 몇 가지가 있습니다.

첫 번째 이유는 오류를 수정하기 위해서입니다. 하지만 이 같은 이유라면 일반적으로 revert 멍령어를 사용해 변경 사항을 되돌리는 새 커밋을 생성하는 것이 더 나은 방법입니다.

두 번째 더 일반적인 시나리오는 커밋 기록을 변경하는 rebase와 같은 작업이 실행된 이후입니다:

내부적으로 Git은 새로운 커밋을 생성하고 지정된 브랜치에 변경 이력을 적용해 [rebase]를 실행합니다. 여기서 유념할 점은 동일한 브랜치인 것 같아 보이지만 rebase전과 후의 브랜치는 완전히 다른(새로운) 커밋으로 구성된다는 것입니다.

rebase는 완전히 새로운 커밋을 생성합니다.

즉, 로컬에서만 rebase가 실행된 브랜치를 푸시하려고 하면 원격 저장소에서 커밋 기록이 변경되었다는 것을 인식하고 로컬과 원격 저장소의 커밋 기록이 일치할 때까지 푸시하지 못하게 합니다.

(my-feature)$ git push
To github.com:johnmosesman/burner-repo.git
 ! [rejected]        my-feature -> my-feature (non-fast-forward)
error: failed to push some refs to 'git@github.com:johnmosesman/burner-repo.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

git pull를 실행해 변경이력을 병합할 수 있지만, 원격 저장소를 강제로 덮어쓰려면 푸시 명령어에 --force 플래그를 추가합니다.

(my-feature)$ git push --force origin my-feature
Enumerating objects: 1, done.
Counting objects: 100% (1/1), done.
Writing objects: 100% (1/1), 184 bytes | 184.00 KiB/s, done.
Total 1 (delta 0), reused 0 (delta 0)
To github.com:johnmosesman/burner-repo.git
 + edb64e2...52f54da my-feature -> my-feature (forced update)

(참고: --force대신 약자인 -f를 사용할 수 있습니다)

강제 푸시는 원격 저장소를 완전히 바꿔버리고 손상시킬 수 있는 작업이기 때문에 확실한 경우에만 사용하는 걸 권장합니다.

--force-with-lease 옵션 사용하기

때로는 자신 이외의 사람이 브랜치에 기여하지 않은 경우에만 강제 푸시를 실행하고 싶을 수도 있습니다.

다른 사람이 브랜치에 기여하고 원격 저장소로 푸시한 후 기존 작업자가 강제 푸시를 실행하면 다른 사람의 작업 내용을 덮어쓰게 됩니다.

이런 상황을 방지하려면 --force-with-lease 옵션을 사용합니다.

설명서에 따르면:

세부 정보를 지정하지 않은 채로 --force-with-lease를 실행하면 모든 원격 참조(remote Refs 레퍼런스)들은 보호됩니다. 여기서 말하는 원격 참조란 리모트 트래킹 브랜치(remote-tracking branch)의 소스와 동일하도록 맞춰서 업데이트 되는 참조를 뜻합니다.

즉, Git에게 이 브랜치가 마지막으로 봤을 때와 동일한 경우에만 강제로 업데이트하도록 지시하는 것입니다.

다른 사람과 같은 브랜치에서 협업하는 경우, 다른 사용자가 변경한 내용이 손실되지 않도록 --force를 사용하지 않거나 최소한 --force-with-lease를 사용하는 것이 좋습니다.

Git 로컬 브랜치를 다른 이름의 원격 브랜치로 푸시하기

일반적으로 로컬 브랜치를 같은 이름의 원격 브랜치에 푸시하지만, 그렇지 않은 경우도 있습니다.

다른 이름의 원격 브랜치로 푸시하려면 푸시할 로컬 브랜치와 원격 브랜치의 이름을 콜론(:)으로 구분하여 지정합니다.

예를 들어 로컬 브랜치 some-branch를 원격 브랜치 my-feature로 푸시하고 싶다면:

(some-branch)$ git push origin some-branch:my-feature
Total 0 (delta 0), reused 0 (delta 0)
To github.com:johnmosesman/burner-repo.git
 + 728f0df...8bf04ea some-branch -> my-feature

모든 로컬 브랜치를 원격 저장소로 푸시하기

모든 로컬 브랜치를 원격 저장소로 푸시할 필요는 없지만, 그럴 경우 --all 플래그를 명령어에 추가해야 합니다:

(main)$ git branch
* main
  my-feature

(main)$ git push --all
...
To github.com:johnmosesman/burner-repo.git
   b7f661f..6e36148  main -> main
 * [new branch]      my-feature -> my-feature

결론

git push 명령어는 자주 사용하는 명령어이며, 같이 사용할 수 있는 옵션이 매우 다양합니다. 유용한 옵션에 대해서 알고 싶으시다면 설명서 (영문)를 읽어보시기 바랍니다.

이 튜토리얼이 마음에 드셨다면, 제 트위터 계정과 사이트를 통해 이런 주제에 대한 글을 확인할 수 있습니다.