- 해당 예시에서는 아래와 같이 다양한 브랜치들이 있습니다. 이러한 브랜치들 간의 ‘전환’을 하는 작업을 수행합니다.
- 위에 ‘develop-multiflex’라는 브랜치에서 ‘데일리 코딩테스트’라는 브랜치로 이동하였습니다. - 이 과정을 통해 ‘develop-multiflex’의 소스코드가 ‘데일리 코딩테스트’ 소스코드로 변경되었습니다.
2) 브랜치 생성, 수정, 삭제
1. 브랜치 생성
💡 브랜치 생성
- 메인 코드와는 별개로 별도의 개발을 하기 위해 새로운 개발 라인을 만드는 작업을 의미합니다.
- 이를 통해 개발자들은 새로운 기능을 추가하거나 버그를 수정하는 작업을 메인 코드의 영향을 주지 않고 진행할 수 있습니다. - 또한 필요에 따라 브랜치를 생성하고 수정되며 변경사항이 준비되면 메인 코드와 병합할 수 있습니다.
# 브랜치 이름을 기반으로 새로운 브랜치를 생성합니다.
$ git branch <branch-name>
💡 아래와 같이 새로운 브랜치가 생성되었습니다.
2. 브랜치 이름 수정
💡 브랜치 이름 수정 - 이미 생성된 브랜치의 이름을 변경하는 작업을 의미합니다.
- 브랜치 이름을 수정하는 주요 목적은 브랜치를 더 명확하게 식별하거나 일관성을 유지하기 위해 사용됩니다.
# 이름을 변경하려는 브랜치로 체크아웃을 합니다
$ git checkout <branch/commit>
# 브랜치 이름을 변경합니다.
$ git branch -m <new-branch-name>
# 변경된 브랜치의 이름을 원격 저장소에 푸시합니다.
$ git push -u origin <new-branch-name>
💡 아래와 같이 브랜치 이름을 변경하였습니다.
[ 더 알아보기 ] 💡 아래와 같이 ‘브랜치 명’ is not a valid branch name이 나오는 이유는?
- 브랜치 명은 기본적으로 ‘공백을 허용하지 않습니다’. 그렇기에 하이픈 (-)이나 밑줄 (_)과 같은 다른 문자로 대체되어야 합니다. - 아래와 같은 경우도 ‘더 새로운 브랜치’가 아니라 ‘더-새로운-브랜치’가 됩니다.
💡 아래와 같이 변경한 이름이 적용되었습니다.
3. 브랜치 삭제
💡 브랜치 삭제
- 더 이상 필요로 하지 않는 브랜치를 제거하는 작업을 의미합니다.
- 해당 작업을 위해서 삭제하려는 브랜치가 아닌 다른 브랜치에서 해당 작업을 수행해야 합니다. 이유는 내 위치가 되는 브랜치를 삭제한다면 내가 있을 Git의 위치를 알 수 없기 때문입니다.
# 삭제하려는 브랜치가 아닌 다른 브랜치로 이동하여야 합니다.
$ git checkout <branch/commit>
# 브랜치가 머지되어 있는 상태인 경우
git branch -d <branch-name>
# 브랜치가 머지되어 있지 않은 상태인 경우
git branch -D <branch-name>
- 아래와 같이 ‘강제 삭제’와 ‘원격 브랜치 삭제’가 있습니다. - 현재 삭제하려는 브랜치가 원격 브랜치로 커밋과 푸시를 진행하지 않은 상태이기에 ‘원격 브랜치 삭제’ 버튼이 활성화되지 않았습니다.
💡 삭제를 진행 완료하면 기존의 ‘더 새로운 브랜치’라는 브랜치가 삭제되었습니다.
3) 스테이징(Staging)
💡 스테이징(Staging)
- 특정 파일이나 변경된 모든 파일을 Staging 영역으로 이동시킬 수 있습니다.
# 변경된 파일의 일부에 대해 스테이징 영역에 추가합니다.
$ git add <file>
# 변경된 파일의 모두를 스테이징 영역에 추가합니다
$ git add .
[ 더 알아보기 ] 💡 스테이징 영역(Staging Area) - 파일 변경 내용을 커밋하기 전에 준비하는 작업 공간을 의미합니다.
- 스테이징 영역은 변경 내용을 세분화하여 커밋할 수 있도록 도와줍니다. 다양한 변경 내용이 있는 경우, 파일 단위로 스테이징 영역에 추가하여 필요한 변경 사항만 선택적으로 커밋할 수 있습니다 - .git add 명령어를 사용하여 파일을 스테이징 영역에 추가합니다. 이를 통해 특정 파일이나 변경된 모든 파일을 스테이징 영역으로 이동시킬 수 있습니다. - git commit 명령어를 사용하여 스테이징에 추가된 파일을 커밋할 수 있습니다. 이를 통해 변경 내용을 Git의 버전 기록에 영구적으로 저장합니다.
💡 Staging 사용예시
- 아래에 예시는 ‘데일리 코딩테스트’라는 브랜치에서 “소스코드 일부를 수정하였습니다”라는 콘솔을 작성하였습니다. - 이 변경 사항에 대해 내 브랜치에 올리고 싶은 목적을 가지고 있습니다. 그렇다면 우선 ‘스테이징 영역’에 추가를 합니다.
💡 GUI에서는 체크박스를 선택하면 스테이지 영역에 추가됩니다.
💡 이렇게 아래와 같이 스테이지 영역에는 올라가 있지만 커밋은 되어 있지 않은 상태입니다.
4) 커밋(Commit)
💡 커밋(Commit)
- 변경 내용을 변경 메시지와 함께 Git의 버전 기록에 영구적으로 저장하는 작업을 의미합니다.
- 커밋을 통해 코드의 버전을 관리하고 변경 내용을 추적하며 프로젝트의 히스토리를 기록할 수 있습니다.
# 스테이징 영역에 올라가 있는 변경사항을 커밋하여 소스에 반영합니다.
$ git commit -m "<message>"
💡 Commit 사용예시
- 아래의 예시에서는 이전에 브랜치의 스테이징 영역에 있는 소스코드 변경 사항을 커밋합니다. - 해당 커밋을 수행하면 ‘로컬 저장소’에 저장이 됩니다. (추후 push 과정을 통해 다른 사람들과 공유할 수 있는 ‘원격 저장소’에 저장이 됩니다)
- 위에 커밋 버튼을 누르면 푸시가 대기 중입니다. - 우선적으로 로컬 저장소에 저장된 상태입니다.
5) 푸시(Push)
💡 푸시(Push) - 로컬 저장소에 올려져 있는 변경사항을 ‘원격 저장소’에 업로드하는 작업을 의미합니다. - 이러한 작업을 통해 다른 개발자와 코드를 공유하거나 협업 프로젝트에서 변경 사항을 업데이트할 수 있습니다.
# 로컬 저장소에 올려져 있는 변경사항을 '원격 저장소'에 올리는 작업을 수행합니다.
$ git push
💡 Push 사용예시
- 해당 작업을 통해서 ‘로컬 저장소’에 있는 변경 사항을 ‘데일리 코딩테스트’라는 브랜치의 원격 저장소에 반영합니다.
💡 위에 작업을 통해 브랜치에 소스코드가 반영되었습니다.
6) 풀(Pull)
💡 풀(Pull) - 원격 저장소로부터 최신 변경 사항을 가져와서 로컬 저장소에 업데이트하는 작업을 의미합니다.
- 해당 작업을 통해 로컬 저장소와 원격 저장소 간의 동기화를 수행할 수 있습니다. - 해당 작업은 git fetch와 git merge 명령어를 조합한 것입니다. 이는 git fetch 명령어를 사용하여 원격 저장소의 최신 커밋을 가져오고, 가져온 커밋을 현재 브랜치에 병합하기 위해 git merge 명령어가 실행됩니다.
# 현재 브랜치에 최신 변경사항을 가져와서 로컬 저장소에 업데이트 합니다.
$ git pull
💡 Pull 사용예시
- 해당 작업의 상태는 ‘데일리 코딩테스트’라는 브랜치의 원격 저장소와 로컬 저장소 간의 소스가 맞지 않은 상태입니다. - ‘로컬 저장소’는 아래에 있는 상태고 ‘원격 저장소’에서 누군가 소스코드를 커밋하여서 이 브랜치 안에서 소스코드를 받아야 하는 상황입니다.
💡 아래의 작업을 통해 ‘데일리 코딩테스트’라는 브랜치의 원격 저장소에 있는 소스 변경사항을 받아오는 풀 작업을 수행합니다.
💡 아래와 같이 원격 저장소로부터 로컬 저장소로 합쳐진 상태가 되었습니다.
7) 머지(Merge)
💡 머지(Merge) - 여러 브랜치 간의 작업 내용을 하나로 합치는 작업을 의미합니다.
- 각각의 브랜치는 독립적인 작업 영역을 가지고 있으며, 개발자는 여러 개의 브랜치를 생성하여 동시에 다양한 작업을 수행할 수 있습니다. - 그렇지만 결국 하나의 소스코드로 통합이 되어야 하기에 해당 병합 작업을 수행합니다.
# 현재 체크아웃 받은 내 브랜치를 기준으로 다른 브랜치의 변경사항을 합칩니다.
$ git merge <branch>
💡 Merge 사용예시 - 해당 작업은 내가 위치한 ‘데일리 코딩테스트’라는 브랜치를 기준으로 ‘develop-multiflex’라는 브랜치를 병합하는 작업입니다.
- 아래의 작업을 통해서 ‘develop-multiflex’ 소스코드가 내 기준 ‘데일리 코딩테스트’ 브랜치로 병합이 되었습니다. - 단 현재 작업은 로컬 저장소에만 저장된 상태이므로 ‘Push’ 작업을 통해 원격 저장소까지 소스코드를 합쳐 올립니다.
💡 아래와 같이 ‘데일리 코딩테스트’라는 브랜치를 기준에 ‘develop-multiflex’라는 소스코드가 합쳐진 상태가 되었습니다.
8) 초기화(Reset)
💡 초기화(Reset) - 커밋과 관련된 작업을 조작하는 작업을 의미합니다.
- 해당 리셋 작업에는 ‘커밋 취소’, ‘커밋 제거’, ‘Staging 취소’ 작업이 있습니다. - 커밋을 취소하거나 제거할 경우, 해당 커밋과 그 이후의 변경 내용이 완전히 삭제되며, 이는 되돌릴 수 없는 작업입니다. 따라서, 신중하게 사용해야 합니다.
작업
명령어
설명
커밋 취소
git reset <commit>
이전 커밋으로 돌아갈 수 있으며, 커밋을 취소하고 해당 커밋 이후의 변경 내용을 되돌립니다.
커밋 제거
git reset --hard <commit>
특정 커밋 이후의 모든 커밋을 제거할 수 있으며, 커밋을 완전히 제거하고 해당 커밋 이후의 변경 내용을 모두 삭제합니다.
Staging 취소
git reset
Staging 영역에 있는 파일들을 언스테이징할 수 있으며, 변경된 파일들을 이전 상태로 되돌립니다.
💡 Reset 사용예시
- 해당 작업은 ‘데일리 코딩테스트’라는 브랜치에서 소스코드 작업을 하여 커밋 사항이 생겼습니다. - 이때에 올린 소스코드를 적용하지 않고 초기화하는 방법에 대해 알아봅니다.
💡 만약 스테이지에 올라가지 않은 상태에서 초기화는 아래와 같이 초기화를 눌러서 ‘커밋 초기화’를 수행합니다.
💡 만약에 해당 소스코드가 스테이지까지 올라가 있는 상태도 동일하게 초기화 버튼을 눌러서 초기화를 진행합니다.
💡 소스코드 변경사항이 저장되지 않고 이전 소스로 초기화됨을 확인할 수 있습니다.
9) 태그(Tag)
💡 태그(tag) - 특정 커밋을 식별하고 관리하는 기능을 제공하는 작업을 의미합니다.
- 주로 소프트웨어 버전 릴리즈를 표시하거나 중요한 커밋을 마크하는 데 사용이 됩니다.
# 태그를 구성하려는 브랜치나 커밋으로 이동합니다.
$ git checkout <branch/commit>
# 체크아웃한 브랜치/커밋을 기준으로 태그를 생성합니다.
$ git tag <tag-name>
# 태그를 원격 저장소에 푸쉬합니다.
$ git push origin <tag-name>
💡 Tag 사용예시 - 해당 작업은 ‘데일리 코딩테스트’라는 브랜치에서 태그를 생성하는 사용예시에 대해 알아봅니다.
💡 아래와 같이 태그 이름을 작성하고 ‘태그 푸시’를 통해서 원격 저장소에 바로 올라가게끔 적용하였습니다.
💡 아래와 같이 태그가 생김을 확인하였습니다.
💡 [참고] 추가적으로 태그를 통해 Release를 구성하여 버전관리를 하는 방법에 대해 궁금하시면 아래의 글을 참고하시면 도움이 됩니다.
