오늘부터 2일동안 협업 툴 특강을 듣게 되었다. 깃, 소스트리, 깃허브 사용 방법과 배경에 대해서 배우게 되었는데
왜 리누스 토르발즈씨가 깃을 개발했는지 알 것 같기도 하다.
블로그에도 깃과 같은 게 있으면 얼마나 좋을까 생각한 하루였는데
정말 열심히 작성한 글을 발행하려고 했더니 모든 글이 사라지고 Ctrl Z를 눌러도 돌아오지 않았다...
심지어 임시저장된 걸 불러오면 되려나 하고 눌렀는데 지금 빈 화면이 임시저장 됐다..
이제는 처음부터 블로그에 글 쓰지 않고 텍스트 편집기로 초안 작성을 할려고 한다....
목차
역사와 개요
1. 윈도우에서 Git 사용을 위한 WSL 설정
2. Git 버전 관리의 기본 구조
3. 리눅스 기본 명령어 사용해서 커밋하기
3-1. CLI에서 커밋 해시와 태그 실습하기
4. revert, reset | 버전 되돌리기
5. stash로 작업 내용 임시 저장하기
6. branch
7. merge
역사와 개요
Git은 리누스 토르발즈가 만든 버전 관리 도구이다. 프로그램을 개발하다 보면 수정 내역을 확인하기 어렵고, 이전 작업으로 되돌아가거나 여러 사람과 협업하는 것도 쉽지 않다. 또 파일을 날짜별로 따로 저장하다 보면 비슷한 파일이 계속 쌓여 관리가 복잡해진다. Git은 이런 문제를 해결하기 위해 만들어졌다.
프로그램 개발은 여러 번의 수정과 저장을 반복하며 버전을 쌓아가는 과정이다. Git이 있으면 변경 내역을 기록할 수 있고, 필요하면 이전 상태로 되돌릴 수 있으며, 여러 명의 코드를 나누고 다시 합쳐서 관리할 수도 있다.
이번에 배우는 내용은 Git, SourceTree, GitHub이다. Git은 버전을 관리하는 도구이고, SourceTree는 Git을 화면으로 편하게 사용할 수 있게 해주는 도구이다. GitHub는 Git으로 관리한 프로젝트를 인터넷상에서 저장하고 공유할 수 있게 해주는 원격 저장소 호스팅 서비스이다. 많은 오픈소스와 상용 프로그램이 GitHub로 관리되며, GitHub 자체도 Git으로 관리된다.
정리하면, Git은 버전을 관리하는 도구, SourceTree는 Git을 편하게 쓰는 도구, GitHub는 원격 저장소 호스팅 서비스이다.
GIT
1. 윈도우에서 Git 사용을 위한 WSL 설정
나는 맥 유저라서 따로 리눅스 환경 세팅을 해줄 필요가 없지만, 집에서 작업할 때는 윈도우를 쓰기 때문에 윈도우에서 git을 쓰기 위한 설정도 해주었다.
우선 git을 설치해준다.
0) 전제 조건: BIOS에서 CPU 가상화가 켜져 있어야 한다. WSL 2를 사용하려면 Windows의 Virtual Machine Platform 기능도 필요하다.
1) [Windows 기능 켜기/끄기] 에서
Linux용 Windows 하위 시스템(WSL) 을 체크한다.
필요하면 Virtual Machine Platform 도 함께 활성화한다.
2) 재부팅한다.
3) PowerShell(관리자 권한)에서 wsl --update 를 실행한다.
필요하면 WSL을 다시 시작하거나 재부팅한다.
4) PowerShell에서 wsl --install -d Ubuntu 를 실행하면 Ubuntu 배포판이 설치된다.
5) 설치가 진행된 뒤 Ubuntu가 실행되면,
Unix username 과 password 를 설정한다.
비밀번호는 입력할 때 화면에 표시되지 않는 것이 정상이다.
6) 설정이 끝나면 $표시로 프롬프트가 뜨고, 윈도우에서 리눅스 명령어를 사용할 수 있다.
WSL 명령어 요약
wsl --install : WSL 설치
wsl --install -d 배포판 : 리눅스 설치(배포판 : Ubuntu, Rocky, Centos,....)
wsl --list --online : 설치 가능한 리눅스 배포판 목록
2. Git 버전 관리의 기본 구조
깃 버전 관리란?
Git은 파일과 프로젝트의 변경 내역을 관리하는 도구이다.
프로그램을 개발하다 보면 코드를 계속 수정하게 되는데, 이때 어떤 부분이 바뀌었는지 기록하고 필요하면 이전 상태로 되돌릴 수 있어야 한다. Git은 이런 과정을 체계적으로 관리해주는 버전 관리 도구이다.
Git의 버전 관리를 이해하려면 먼저 세 가지 공간을 알아야 한다.
바로 작업 디렉터리, 스테이지, 저장소이다. Git은 이 세 공간을 관리하면서 하나의 버전을 만들어간다.
1) 작업 디렉터리(Working Directory)
작업 디렉터리는 내가 실제로 코드를 작성하고 수정하는 공간이다.
쉽게 말하면 프로그램 소스코드가 들어 있는 폴더라고 생각하면 된다. 우리가 자바 파일을 만들고, HTML 파일을 수정하고, 텍스트 파일을 작성하는 모든 작업이 이 공간에서 이루어진다.
즉, 작업 디렉터리는 버전 관리의 대상이 되는 파일들이 실제로 존재하는 공간이다.
보통 .git 폴더가 있는 디렉터리를 기준으로 그 안의 파일들이 Git의 관리 대상이 된다.
2) 스테이지(Stage)
스테이지는 다음 버전이 될 후보를 올려두는 공간이다.
다른 말로는 인덱스(Index) 라고도 부른다.
작업 디렉터리에서 파일을 수정했다고 해서 바로 버전이 만들어지는 것은 아니다.
먼저 “이번 버전에 이 파일을 포함하겠다”라고 선택해서 올려두는 과정이 필요하다. 그 공간이 바로 스테이지이다.
즉, 스테이지는 수정한 파일들 중에서 어떤 파일을 다음 버전에 포함할지 정리해두는 중간 공간이라고 볼 수 있다.
3) 저장소(Repository)
저장소는 버전이 실제로 만들어지고 관리되는 공간이다.
스테이지에 올라온 내용을 최종적으로 저장소에 기록하면 하나의 버전이 만들어진다.
이 과정을 통해 Git은 “언제 어떤 파일이 어떤 상태였는지”를 기억하게 된다.
그래서 나중에 이전 버전으로 돌아가거나, 어떤 내용이 수정되었는지 확인할 수 있다.
즉, 저장소는 완성된 버전들이 차곡차곡 쌓여 있는 공간이다.
4) add와 commit
Git에서는 작업 디렉터리의 내용을 스테이지에 올리는 것을 add라고 한다.
그리고 스테이지의 내용을 저장소에 올려 하나의 버전으로 만드는 것을 commit이라고 한다.
정리하면 다음과 같다.
- add : 작업 디렉터리 → 스테이지
- commit : 스테이지 → 저장소
즉, 파일을 수정한 뒤 바로 버전이 저장되는 것이 아니라,
먼저 add로 후보에 올리고, 그다음 commit으로 최종 저장하는 구조이다.
5) 하나의 버전이 만들어지는 과정
Git에서 하나의 버전은 보통 다음 순서로 만들어진다.
- 작업 디렉터리 내에서 변경 사항 생성 → 일반적인 코딩 작업
- 스테이지로 add → 이번 버전에 포함할 파일을 올림
- 저장소로 commit → 하나의 버전으로 기록
즉, Git은 작업한 내용을 바로 저장소에 넣는 것이 아니라,
한 번 스테이지라는 중간 단계를 거쳐서 버전을 만들게 된다.
6) 왜 스테이지가 필요할까?
“수정했으면 바로 저장하면 되지 왜 스테이지가 또 필요하지?”라는 생각이 들 수 있다.
하지만 스테이지가 있기 때문에 원하는 파일만 골라서 버전에 포함할 수 있다.
예를 들어 파일을 세 개 수정했는데, 그중 한 개만 먼저 버전으로 만들고 싶을 수 있다.
이럴 때 스테이지에 필요한 파일만 올리고 commit하면 된다.
즉, 스테이지는 버전을 더 정확하고 깔끔하게 관리할 수 있게 해주는 중간 단계이다.
정리
Git의 버전 관리는 작업 디렉터리, 스테이지, 저장소라는 세 공간을 이해하는 것에서 시작한다.
작업 디렉터리는 실제로 파일을 수정하는 공간이고, 스테이지는 다음 버전이 될 후보를 올려두는 공간이며, 저장소는 최종 버전이 기록되고 관리되는 공간이다.
그리고 이 과정에서
작업 디렉터리의 내용을 스테이지에 올리는 것은 add,
스테이지의 내용을 저장소에 기록하는 것은 commit이다.
즉, Git은
작업 → add → commit
이라는 흐름으로 하나의 버전을 만들어간다.
3. 리눅스 기본 명령어 활용해서 커밋하기
이번에는 리눅스 기본 명령어를 활용해 터미널에서 직접 Git 커밋을 진행해보았다. 터미널에서 명령어를 입력해 작업하는 방식을 CLI(Command Line Interface)라고 한다. CLI 방식은 버튼을 클릭하는 GUI 방식보다 처음에는 어렵게 느껴질 수 있지만, Git의 동작 과정을 직접 확인할 수 있어 기본 개념을 이해하는 데 도움이 된다.
이번 실습에서는 mkdir, cd, touch, vi 명령어로 파일을 준비하고, git init, git add, git commit 명령어를 사용해 커밋을 진행했다. 이후에는 태그를 추가하며 버전을 구분하는 방법도 함께 확인했다. 다음 단계에서는 GUI 도구인 SourceTree를 사용해 같은 과정을 더 직관적으로 실행해볼 예정이다.
1) 리눅스 기본 명령어
| pwd | 현재 위치 확인 |
| cd 폴더명 cd .. cd ~ |
폴더 이동 상위 폴더 이동 홈으로 이동 |
| mkdir 폴더명 mkdir -p 경로 |
폴더 생성 경로째 폴더 생성 |
| touch 파일명 | 파일 생성 |
| rmdir 폴더명 | 빈 폴더 삭제 |
| ls ls -l ls -la |
목록 보기 자세히 보기 숨김 파일 포함 보기 |
| clear | 화면 정리 |
| touch 파일명 | 파일 생성 |
| cp 원본대상 cp -r 원본대상 |
파일 복사 폴더 복사 |
| rm 파일명 rm -f 파일명 rm -r 폴더명 rm -rf 폴더명 |
파일 삭제 파일 강제 삭제 폴더 삭제 폴더 강제 삭제 |
| mv 원본대상 | 이동 / 이름 변경 |
| cat 파일명 | 파일 내용 보기 |
| less 파일명 | 파일 내용 나눠 보기 |
| vi 파일명 | 파일 편집 |
2) 커밋하기
| git init | 저장소 생성 |
| git status | 현재 상태 확인 |
| git add 파일명 git add . |
파일 스테이징 전체 파일 스테이징 |
| git commit -m "메시지" git commit -m "제목" -m "본문" git commit |
커밋 저장 제목 + 본문 커밋 저장 에디터가 열리고 커밋 저장 |
| git log git log --oneline |
커밋 기록 확인 커밋 기록 한 줄로 확인 |
터미널을 실행한 후 mkdir 명령어로 폴더를 생성한다.
그다음 cd 명령어로 해당 디렉터리로 이동한다.
리눅스나 맥 터미널에서는 touch 명령어로 파일을 만들 수 있다. 윈도우에서는 텍스트 편집기에서 파일을 만든 뒤 해당 폴더에 저장하는 방법도 많이 사용한다. 맥에서도 윈도우와 마찬가지로 텍스트 편집기 프로그램으로 작성 후 gitPrac 디렉터리에 저장해두어도 된다.
이후 vi a.txt를 입력해 텍스트 파일을 열고 내용을 작성한다.
vi a.txt 이후 빈 화면이 출력되는데 i를 눌러서 insert 모드로 들어가면 입력할 수 있다.
작성했으면 윈도우에선 ESC / 맥에서는 Ctrl + c로 insert 모드에서 벗어난 뒤,
:wq(저장 후 종료)( :q는 변경사항 없을 시 저장 x 종료 | :q! 변경사항 있어도 저장 없이 강제종료)로 저장 후 종료해준다.
이번에는 터미널에서 Git 저장소를 직접 만들고 첫 커밋까지 진행해보았다. 먼저 git init 명령어로 현재 폴더를 Git 저장소로 초기화했다. 그러면 해당 폴더 안에 .git이라는 숨김 폴더가 생성되고, 이때부터 Git으로 파일 버전을 관리할 수 있게 된다.
그다음 git status 명령어로 현재 상태를 확인했다. 아직 커밋된 파일이 없기 때문에 a.txt 파일이 추적되지 않은 파일이라고 표시되었다. 이후 git add . 명령어를 사용해 현재 폴더의 변경 파일을 스테이징 영역에 올렸다. 이 과정은 커밋하기 전에 “이 파일을 저장 대상으로 포함하겠다”라고 Git에 알려주는 단계라고 볼 수 있다.
커밋을 할 때는 git commit -m "first commit" 형식으로 입력해야 한다. 실수해서 -를 빼고 입력해서 오류가 발생했다.
정상적으로 커밋이 완료되면 Git은 하나의 저장 기록을 만든다. 이후 git log 명령어를 입력하면 지금까지 만든 커밋 기록을 확인할 수 있다. 이렇게 해서 파일 생성, 스테이징, 커밋, 기록 확인까지 Git의 가장 기본적인 흐름을 직접 실습해볼 수 있었다.
git log 창에서는 :q로 바로 나올 수 있다. 엔터 안 치고 q까지만 입력해도 나와진다.
이제 파일 내용을 A에서 AA, AAA로 두 번 더 커밋을 한다.
파일 내용을 수정한 뒤에는 그 변경 사항을 다시 Git에 반영해야 한다. 이때 사용하는 명령어가 git add이다. git add .은 현재 폴더의 변경된 파일을 한꺼번에 스테이징하는 명령어이고, git add a.txt는 a.txt 파일만 스테이징하는 명령어이다. 이번처럼 하나의 파일만 수정한 경우에는 git add a.txt를 사용해도 되고, 전체 변경 사항을 한 번에 올리고 싶다면 git add .을 사용해도 된다. 즉, 파일의 내용이 바뀌었기 때문에 다시 스테이징하는 것이다.
간략하게 보고싶으면 git log --oneline, 자세히 보려면 git log 로 확인하면 된다.
3-1. CLI에서 커밋 해시와 태그 실습하기
아래와 같이 파일을 두 개 더 추가해주고 변경사항도 만들어주었다.
커밋이 a.txt에는 a라고 표시가 되어있지 않다. a.txt 커밋은 forth까지 있지만,
- a third commit의 해시 (bd0ec7d)
- b third commit의 해시 (a8ca16e)
이 두 개의 해시에 태그를 달아보자
| git tag a-fianl bd0ec7d git tag b-final a8ca16e git tag |
위 명령어로 태그 달기, 태그 확인까지 할 수 있다.
다시 git log --oneline 명령어로 확인해보면 태그가 추가된 것을 볼 수 있다.
git tag 명령어는 현재 저장된 태그 목록만 확인할 때 사용한다.
태그 정보를 더 자세히 보고 싶다면 git show 태그이름 명령어로 확인할 수 있다.
태그를 삭제할 때는 git tag -d 태그이름 명령어를 사용한다.
또한, 태그가 두 개 이상 있을 때 tag diff (old 커밋해시) (new 커밋해시)로 버전을 비교할 수도 있다.
정리
| 명령어 | 기능 |
| git log --oneline | 커밋 해시 확인 |
| git tag | 태그 목록 확인 |
| git tag 태그명 커밋해시 | 특정 커밋에 태그 추가 |
| git show 태그명 | 태그가 가리키는 커밋 확인 |
| git tag -d 태그명 | 태그 삭제 |
| tag diff (old 커밋해시) (new 커밋해시) | 버전 비교 |
4. revert, reset | 버전 되돌리기
Git에서 이미 만든 버전을 되돌리는 방법에는 크게 revert와 reset 두 가지가 있다.
revert는 이전 버전으로 되돌리는 내용을 반영한 새로운 커밋을 만드는 방식이다. 즉, 기존 커밋 기록은 그대로 남기면서, 되돌린 결과를 새 버전으로 추가하는 것이다. 그래서 지금까지의 이력을 유지한 채 안전하게 되돌리고 싶을 때 많이 사용한다.
반면 reset은 특정 시점으로 버전 자체를 되돌리는 방식이다. 되돌리는 범위에 따라 soft, mixed, hard 세 가지로 나뉜다. reset은 커밋 기록이나 스테이징 상태, 작업 디렉터리까지 직접 되돌릴 수 있기 때문에 강력하지만, 사용 시 주의가 필요하다.
soft reset은 커밋만 취소하는 방식이다. 즉, 저장소의 커밋 기록만 되돌리고, 변경된 파일 내용과 스테이징 상태는 그대로 남는다.
mixed reset은 스테이징까지 취소하는 방식이다. 커밋도 취소되고, 스테이징 영역에서도 내려가지만, 작업 디렉터리의 파일 내용은 유지된다.
hard reset은 작업 디렉터리까지 모두 되돌리는 방식이다. 즉, 커밋, 스테이징, 파일 내용까지 모두 이전 상태로 돌아간다.
정리하면 revert는 기존 기록을 남긴 채 되돌린 새 버전을 만드는 방법이고, reset은 특정 시점으로 직접 돌아가는 방법이다. 또한 reset은 되돌리는 범위에 따라 soft, mixed, hard로 구분된다.
1) revert
c.txt에 새로운 내용을 입력한 뒤 커밋을 생성하면, HEAD는 가장 최근에 만든 C 커밋을 가리키게 된다.
그 후 git revert 커밋해시를 입력하면 해당 커밋을 되돌릴 수 있다. 만약 가장 최근 커밋을 되돌리는 경우라면 git revert HEAD라고 입력해도 된다.
그러면 아래와 같이 새로운 커밋이 생성된다.
즉, revert는 기존 커밋을 삭제하는 것이 아니라, 해당 커밋의 내용을 취소한 새로운 커밋을 추가하는 방식이다. 따라서 되돌린 이후 파일 내용은 이전 상태로 돌아가지만, Git 기록에는 새로운 커밋이 남게 된다.
2) reset
reset은 현재 위치에서 “어디로 되돌아갈지”를 지정하는 명령어이다. 따라서 HEAD를 입력하면 현재 커밋을 그대로 가리키기 때문에 되돌아가지 않는다. 최근 커밋 하나를 되돌리고 싶다면 현재보다 이전 커밋을 의미하는 HEAD~1을 사용해야 한다.
git reset HEAD~1은 기본적으로 mixed reset 방식으로 동작한다. 즉, 최근 커밋은 취소되지만 파일의 수정 내용은 작업 디렉터리에 남고, 스테이징 상태만 해제된다.
git reset HEAD~1 명령어를 입력하게 되면, 아까와 달리 revert 했던 commit은 사라진 걸 알 수 있다.
가장 최근 커밋을 기준으로 되돌릴 때는 상황에 맞게 아래와 같이 입력하면 된다.
git reset --soft HEAD~1
git reset --mixed HEAD~1
git reset --hard HEAD~1
최근 커밋은 HEAD~1처럼 상대적인 위치로 되돌릴 수 있고, 더 이전 커밋은 커밋 해시를 직접 지정해 되돌릴 수 있다.
정리
| revert | reset | ||
| git revert HEAD git revert 커밋해시 |
가장 최근 커밋 되돌리기 특정 커밋 되돌리기 |
git reset -(soft/mixed/hard) HEAD~1 | 최근 커밋 (soft,mixed,hard) 되돌리기 |
| git revert –continue git revert –abort |
충돌 해결 후 revert 계속 진행 진행 중인 revert 취소 |
git reset -(soft/mixed/hard) 커밋해시 | 특정 커밋 (soft,mixed,hard) 되돌리기 |
5.stash로 작업 내용 임시 저장하기
| 명령어 | 기능 |
| git stash | 현재 변경 사항 임시 저장 |
| git stash list | stash 목록 확인 |
| git stash pop | 가장 최근 stash 적용 후 목록에서 제거 |
| git stash apply | stash 적용만 하고 목록은 유지 |
| git stash drop stash@{0} | 특정 stash 삭제 |
| git stash clear | stash 전체 삭제 |
stash는 현재 작업 중인 변경 사항을 잠시 보관하는 기능이다. 아직 커밋하기에는 애매하지만, 다른 작업을 먼저 해야 할 때 유용하게 사용할 수 있다. 예를 들어 브랜치를 이동하거나, pull, merge, revert 같은 작업을 하기 전에 현재 변경 내용을 잠깐 치워둘 때 많이 사용한다.
git stash를 실행하면 작업 디렉터리에 있던 변경 사항이 사라지고, stash라는 임시 저장 공간에 보관된다. 그래서 git status를 확인하면 작업 디렉터리가 깨끗한 상태로 보이게 된다. 이후 git stash pop을 실행하면 임시 저장했던 변경 사항이 다시 작업 디렉터리에 복원되고, stash 목록에서는 제거된다. 반면 git stash apply는 임시 저장한 변경 사항을 다시 작업 디렉터리에 적용하지만, stash 목록에서는 삭제하지 않는다. 즉, 작업 내용은 다시 가져오되 임시 저장 목록에는 그대로 남겨두는 방식이다.
commit이 정식 저장이라면 stash는 작업하던 내용을 잠시 치워두는 임시 저장이라고 이해하면 된다.
6. branch
1) 브랜치 개념
브랜치는 버전을 여러 개의 흐름으로 나누어 관리하는 방법이다. 말 그대로 나뭇가지처럼 하나의 흐름에서 여러 갈래로 버전이 분기된다고 이해하면 된다. 즉, 브랜치는 버전의 분기라고 볼 수 있다.
브랜치가 없으면 여러 사람이 함께 작업할 때 불편하다. 한 사람이 작업 중인 코드를 다른 사람이 건드리기 어렵고, 결국 소스코드를 복사해서 따로 작업해야 하는 상황이 생길 수 있다. 이렇게 되면 나중에 다시 합칠 때 어떤 부분이 달라졌는지 직접 확인해야 하고, 자신과 관련 없는 코드까지 살펴봐야 해서 비효율적이다. 브랜치를 사용하면 각자 독립된 흐름에서 작업한 뒤, 필요한 경우 나중에 합칠 수 있다.
정리하면 브랜치를 활용한 작업 흐름은 다음과 같다.
- 브랜치를 나눈다.
- 각자의 브랜치에서 작업한다.
- 필요하면 브랜치를 다시 합친다.
최초의 브랜치는 예전에는 master라는 이름을 많이 사용했지만, 현재는 main을 기본 브랜치 이름으로 사용하는 경우가 많다. GitHub도 기본 브랜치 이름으로 main을 사용하며, 일부 Git 버전이나 맥 환경에서도 처음 생성되는 브랜치 이름이 main으로 설정되기도 한다.
master 브랜치에는 커밋이 네 개, foo 브랜치에는 커밋이 다섯 개, bar 브랜치에는 여섯 개 쌓여있다.
2) HEAD와 checkout
브랜치는 버전을 여러 갈래로 나누어 관리하는 작업 흐름이다. 그림에서는 master가 기본 흐름이고, 중간에 foo와 bar가 갈라져 나와 각각 별도로 커밋을 쌓고 있다. 예를 들어 foo 브랜치는 master 3번 커밋에서 갈라졌기 때문에, 그전까지의 내용은 master와 같고 그 이후부터는 foo만의 커밋이 쌓인다. 즉, 브랜치는 특정 시점의 버전에서 나뉘어 독립적으로 작업하는 방법이라고 이해하면 된다.
HEAD는 현재 내가 작업 중인 브랜치의 최신 커밋을 가리킨다. 예를 들어 foo 브랜치에 있으면 HEAD는 foo의 가장 마지막 커밋을 가리키고, master 브랜치에 있으면 HEAD는 master의 가장 마지막 커밋을 가리킨다.
checkout은 다른 브랜치나 커밋으로 이동하는 명령어이다. 즉, HEAD가 가리키는 위치를 바꾼다고 볼 수 있다. 예를 들어 foo 브랜치에서 master 브랜치로 checkout하면 HEAD도 master의 최신 커밋으로 이동한다. 이때 현재 브랜치에만 있던 파일은 보이지 않을 수 있다. 예를 들어 foo에서만 만든 foo_a.txt 파일은 master로 이동하면 사라진 것처럼 보이는데, 실제로 삭제된 것이 아니라 현재 보고 있는 브랜치에 없는 상태이기 때문이다.
HEAD : 현재 작업 중인 커밋
checkout : HEAD를 변경하는 작업
3) CLI에서 브랜치를 생성하고 삭제해보기.
명령어 정리
| git branch | 브랜치 목록 확인 |
| git branch 브랜치명 | 브랜치명으로 브랜치 생성 |
| git checkout 브랜치명 | 브랜치 이동 |
| git checkout -b 브랜치명 | 브랜치 생성 후 바로 이동 |
| git switch 브랜치명 | 브랜치 이동 |
| git switch -c 브랜치명 | 브랜치 생성 후 바로 이동 |
| git branch -d 브랜치명 | 병합된 브랜치 삭제 |
| git branch -D 브랜치명 | 브랜치 강제 삭제 |
현재 a.txt, b.txt, c.txt와 first-repo 디렉터리가 있는 상태에서 브랜치를 생성해보았다.
먼저 git branch foo 명령어로 새로운 브랜치를 만들고, git branch로 브랜치 목록을 확인하면 사진과 같이 표시된다. 현재 작업 중인 브랜치 앞에는 *가 붙는데, 이를 통해 지금은 main 브랜치에 위치해 있다는 것을 알 수 있다.
이후 git checkout foo 또는 git switch foo 명령어로 foo 브랜치로 이동한 뒤 다시 확인해보면, * 표시가 foo 앞으로 옮겨간 것을 볼 수 있다. 즉, 현재 작업 위치가 foo 브랜치로 바뀐 것이다.
과정을 한 번에 처리하고 싶다면 git checkout -b foo 또는 git switch -c foo 명령어를 사용할 수 있다. 이 명령어들은 브랜치 생성과 이동을 동시에 수행한다.
이제 foo 브랜치에서 a_foo.txt 파일을 만들고 커밋해보면, 디렉터리에서도 a_foo.txt 파일이 생성된 것을 확인할 수 있다.
그런데 중요한 점은 foo 브랜치에서 다시 master(main) 브랜치로 이동하면 a_foo.txt 파일이 디렉터리에서 사라진 것처럼 보인다.
이는 파일이 실제로 삭제된 것이 아니라, 현재 이동한 브랜치에는 해당 파일이 존재하지 않기 때문이다.
즉, a_foo.txt는 foo 브랜치에서만 만들어진 파일이기 때문에 main 브랜치에서는 보이지 않는 것이다.
브랜치를 삭제할 때는 git branch -d foo 명령어를 사용한다. 다만 아직 병합되지 않은 브랜치는 일반 삭제가 되지 않기 때문에, 이 경우에는 git branch -D foo 명령어로 강제 삭제해야 한다.
7. merge
1) merge 개념
merge는 서로 나누어 작업하던 브랜치를 다시 하나로 합치는 기능이다. 예를 들어 master 브랜치에서 작업하다가 foo 브랜치를 따로 만들어 기능을 개발했다면, 나중에 foo에서 작업한 내용을 다시 master에 반영할 수 있다. 즉, 브랜치는 버전을 나누어 관리하는 기능이고, merge는 그렇게 나누어진 흐름을 다시 합치는 기능이라고 볼 수 있다.
빨리감기 병합(Fast-forward merge)
master가 그대로 있는 상태에서 foo만 앞으로 몇 개의 커밋이 더 진행된 경우에 발생한다. 이때는 새로운 병합 커밋을 만들지 않고, master가 단순히 foo가 있는 위치까지 앞으로 이동한다. 말 그대로 브랜치 포인터만 앞으로 “빨리감기” 되는 것이다.
일반 병합(3-way merge)
master와 foo가 서로 갈라진 뒤 각각 따로 커밋이 쌓였을 때 발생한다. 예를 들어 그림처럼 master는 master 4번 커밋으로 진행되고, foo는 foo 4번, foo 5번 커밋으로 따로 진행되었다면, 두 브랜치는 서로 다른 흐름을 가지게 된다. 이 경우에는 단순히 한쪽을 앞으로 이동시키는 것으로 끝낼 수 없기 때문에, 두 브랜치의 내용을 합친 새로운 병합 커밋이 생성된다.
2) CLI에서 병합하기
- 빨리감기 병합
| git checkout -b foo touch a_foo.txt git add . git commit -m "add a_foo.txt in foo" git checkout main git merge foo |
main에서 foo 브랜치를 만들고, 이후 foo에서만 커밋을 추가했다고 하자. 이 상태에서 다시 main으로 돌아와 git merge foo를 실행하면, main은 별도의 병합 커밋 없이 foo의 최신 커밋 위치로 이동한다. 이것이 빨리감기 병합이다.
- 일반 병합
이번에는 main과 foo가 각각 따로 작업을 진행한 경우를 생각해보자.
- main에서 a.txt를 수정하고 커밋
- foo에서 a_foo.txt를 수정하고 커밋
- 다시 main에서 a_main.txt 생성 및 수정 후 커밋
이 상태에서 main에서 git merge foo를 실행하면, Git은 두 흐름을 합친 새로운 병합 커밋을 만든다. 이것이 일반 병합이다.
예시 흐름은 다음과 같다.
| git checkout -b foo touch a_foo.txt git add . git commit -m "foo commit" git checkout main touch a_main.txt git add . git commit -m "main commit" git merge foo |
이 경우 main과 foo 모두 따로 커밋이 있었기 때문에, 단순 이동이 아니라 병합 커밋이 생성된다.
충돌이 발생했을 때
만약 main과 foo에서 같은 파일의 같은 부분을 다르게 수정했다면 병합 중 충돌이 발생할 수 있다.
이때는 어떤 브랜치의 내용을 반영할지 직접 선별 후, 다시 git add를 하고 커밋하면 된다.
'멀티캠퍼스' 카테고리의 다른 글
| [2026.04.18]TIL - 15일차 Java (제어문) (1) | 2026.04.20 |
|---|---|
| [2026.04.16]TIL - 14일차 source tree와 github (0) | 2026.04.20 |
| [2026.04.14]TIL - 12일차 Java 변수와 메모리 구조, 메소드, 연산자 정리 (0) | 2026.04.14 |
| [2026.04.13]TIL - 11일차 Java 설치 & 변수와 입력, 상수 정리 (4) | 2026.04.13 |
| [2026.04.10] TIL - 10일차 jQuery (remove/empty/removeAttr, 동기·비동기, Promise, Ajax) (1) | 2026.04.12 |