개발자라면 반드시 사용하게 되는 것 중 하나가 바로 깃과 깃허브이다.
특히 원활한 협업을 위해서는 깃허브 사용법 숙지가 필수적이다.
이번 깃 스터디를 통해 프로젝트에 참여에 큰 무리가 없도록 공부를 진행했다.
깃 vs 깃허브
처음 깃에 대해 접하면 이 둘의 차이점을 인지하지 못한다.
개발을 공부하던 초창기에는 이 둘이 다르다는 것 조차 몰랐다.
깃은 '소프트웨어' 이다.
- 로컬(컴퓨터,랩탑) 저장장치에 설치됨.
- 깃 리포지토리 내부에 저장된 여러 버전의 파일들을 관리하고 수정하는 도구.
- 커맨드 라인 (터미널 바탕)의 서비스임.
깃허브는 '서비스' 이다.
- 웹을 바탕으로 한다.
- 깃 리포지토리의 카피본을 업로드 할 수 있는 공간이다.
- 그래픽 인터페이스를 제공함.
Git 을 뭐라고 정의할 수 있을까?
git은 '분산형 버전 관리 시스템의 일종'이라고 할 수 있다.
여기서 말하는 버전 관리란 백업, 롤백, 저장, 복사 등등의 행위의 통칭이다.
그렇다면 우리가 버전관리를 통해서 얻을 수 있는 이점은 어떤 것이 있을까?
- 특정 시점에서 파일이 충돌이 났을때 롤백 가능
- 시간 순으로 정렬된 버전을 서로 비교 가능
- 파일이 분실됐을 때 복구 가능
Git을 써야하는 이유?
깃을 통해 프로젝트를 관리하면 보다 체계적인 개발을 할 수 있다.
또한 여러 인원이 동시에 작업 가능하므로 병렬적인 개발이 가능하다.
다른사람의 작업 진행도를 실시간으로 확인할 수 있어 유연한 개발을 할 수 있게 된다.
이제 깃에 대해 하나씩 알아가보도록 하자.
리포지토리가 뭘까?
" 물건을 보관하거나 찾을 수 있는 장소 "
깃 리포지토리는 코드의 버전을 저장하고 접근할 수 있도록 하는 프로젝트 파일 저장소이다.
로컬 리포지토리 vs 원격 리포지토리?
원격과 로컬 리포지토리에 대한 이해가 없으면 당황하는 경우가 생긴다. (내가 그랬다.)
깃의 사용법이나 튜토리얼을 찾아보면
다음과 같은 명령어를 종종 볼 수 있다.
git init
위 커맨드는 새로운 깃 리포지토리를 생성하는 명령어이다.
그리고 여기서 생성되는 깃 리포지토리가 바로 '로컬 리포지토리' 이다.
따라서, 로컬 리포지토리는 '개인의 컴퓨터'에 저장된다.
우리는 로컬 리포지토리에서 작업한 내용을 원격 리포지토리에 저장한다고 생각하면 된다.
브랜치
깃 브랜치가 '브랜치' 라는 명칭을 가진 이유는 다음과 같다.
브랜치는 '나뭇가지' 혹은 '강줄기' 라는 뜻을 가지고 있는데,
나뭇가지 혹은 강줄기에 비유하면 찰떡이기 때문.
깃 브랜치는 하나의 분기점이다.
각 브랜치는 변경사항이 저장된 시점의 코드 형태를 가리킨다.
기능추가나 버그 픽스 등으로 코드가 변경되었다면,
변경점을 새로운 브랜치에 저장함으로써 캡슐화(encapsulation) 할 수 있다.
위의 다이어그램은 2개의 독립된 리포지토리를 시각화했다.
그 중 한 개는 작은 변경점이고, 나머지 한 개는 긴 작업시간이 요구되는 큰 변경점이다.
이 둘을 각각 다른 브랜치에서 개발함으로써, 다른 두 가지 작업을 동시에 진행할 수 있다.
또한 메인 브랜치와 분리시켰으므로, 메인 브랜치의 작업물을 보호할 수 있다.
브랜치 생성 및 이동
브랜치의 개념에 대해 학습했으니 이번엔 실제로 사용해 볼 차례이다.
우선 현재 생성된 브랜치를 확인해보려면 아래의 명령어를 입력하면 된다.
목록을 확인했다면 q를 입력해서 원래 화면으로 돌아올 수 있다.
git branch
프로젝트 내에서 브랜치를 추가하는 방법은 다음과 같다.
git branch 브랜치이름
다만, 브랜치를 생성했다고 해서 바로 해당 브랜치로 이동되지 않는다.
체크아웃 명령어를 통하여 원하는 브랜치로 이동할 수 있다.
git checkout 브랜치이름
디렉토리 트리
깃의 상태를 나타내는 트리 구조를 디렉토리 트리라고 한다.
아래의 다섯가지 상태를 명확히 이해하고 있어야 깃 사용중 혼선을 겪지 않는다.
디렉토리 트리는 총 5단계로 구성되어 있다.
(1) 프로젝트가 깃에 등록되지 않은 단계
(2) 깃에 의해 프로젝트가 등록된 단계
(3) 스테이징 영역에 파일이 등록된 단계
(4) 로컬 리포지토리에 커밋이 완료된 단계
(5) 원격 리포지토리에 푸시가 완료된 단계
1. 프로젝트를 Git에 등록하기
프로젝트가 깃과 아무런 관련이 없는 상태.
다음 커맨드를 입력하면 git에 프로젝트가 '인식' 한다.
git init
2. 원격 리포지토리 주소 지정하기
다음 명령어를 통해 원격 리포지토리 주소를 지정할 수 있다.
git remote add
위의 명령어는 두 가지 인자를 필요로 한다.
(1) 원격 리포지토리의 이름
(2) 원격 리포지토리의 URL
git remote add origin https://gdsc.com/OWENR/REPOSITORY.git
3. 원하는 파일을 스테이징 하기.
git init 명령어를 통해 프로젝트가 인식되었다.
이제 해야할 일은 커밋 하고싶은 파일을 스테이징 하는 것이다.
스테이징 개념을 이해하려면 파일의 상태 3단계에 대해 먼저 이해해야 한다.
파일의 상태로는 총 3가지가 존재한다.
- modified : 파일이 변경된 상태. (로컬 리포지토리의 상태와 비교)
- staged : 커밋을 위해 스테이지에 업로드한 상태
- committed : 로컬 리포지토리에 정상적으로 저장이 완료된 상태
다음 명령어를 통해 원하는 파일을 스테이징 할 수 있다.
git add <추가하고 싶은 파일>
4. 스테이징이 완료된 파일을 커밋하기.
git add를 통해 파일이 정상적으로 스테이징 되었다면, 다음으로 할 일은 커밋이다.
커밋이란, 변경점을 로컬 리포지토리에 저장하는 명령어이다.
다음과 같이 커밋 명령어를 통해서 로컬 레포지토리에 변경사항을 반영 및 저장할 수 있다.
git commit -m "변경사항에 대해 기술"
5. 커밋이 완료된 파일들을 푸시하기.
git push는 로컬 리포지토리에 저장된 파일들을 원격 리포지토리에 반영하는 명령어이다.
주로 현재 브랜치(로컬 리포지토리)의 변경점을 메인 리포지토리에 병합할때 사용된다.
git push
Pull Request
위의 5단계를 거쳐서 푸시를 완료했다.
하지만 대부분의 프로젝트는 (특히 협업에서는) 푸시된 사항이 바로 메인 브랜치에 반영되지 않는다.
브랜치를 병합하는 과정에서 생길 수 있는 충돌을 미연에 방지하기 위함이다.
병합을 요청하는 프로세스를 Pull Request라고 한다.
흔히 줄여서 'PR'이라고 부르기도 한다.
Merge
Pull Request를 통해 정상적으로 요청이 완료되고, 병합할 준비가 완료됐다.
여기서 병합하는 행위를 '머지'라고 한다.
아래의 그림은 Merge 전후의 브랜치 모습을 나타내고 있다.
Merge를 통해서 두 개의 브랜치가 하나로 통합된 모습을 확인할 수 있다.
마무리
이번 깃허브 스터디를 통해 깃의 전반적인 사용법에 대해 알게되었다.
깃에 대한 이해가 없는 상태로 무턱대고 사용부터 했던터라 어렴풋이 알지만
딱 이렇다 하고 설명하지 못 하는 부분들이 많았다.
그래도 이번 스터디 덕분에 깃의 개념을 명확하게 알게 되었고,
실제로 깃허브를 잘 이용하고 있다.
이번 스터디의 목적이 깃허브를 원활히 사용하기 위함이었으므로,
성과를 충분히 달성한 것 같다!
출처 :
- https://www.w3docs.com/learn-git/git-repository.html
Git Repository | W3Docs Git Online Tutorial
See the definition of Git repository, learn how to initialize & clone it with git init & git clone commands, save changes to the repository & push them.
www.w3docs.com
- https://www.c-sharpcorner.com/article/git-and-github-version-control-local-and-remote-repository/
Git And Github Version Control (Local And Remote Repository)
In this article, you will learn about Git and version control in GitHub (Local And Remote Repository).
www.c-sharpcorner.com
How to Add a Salesforce DX Project to Source Control -step by step guide
There are many version control systems and hosting services to choose from that help developers track changes to and collaborate on their code. We use Git, a popular version control system, and Git…
sfdctechie.wordpress.com
- https://www.atlassian.com/git/tutorials/using-branches
Git Branch | Atlassian Git Tutorial
This document is an in-depth review of the git branch command and a discussion of the overall Git branching model.
www.atlassian.com
- https://toolsqa.com/git/git-life-cycle/
What is Git Life Cycle and What are different stages in Git Life Cycle
What is Git Life Cycle and What are different stages in Git Life Cycle? What is meant by Git Life Cycle? What are the different stages in Git Life Cycle. Different life cycle of Git. Git WorkfLow with example. What is Staging Area? What is Remote Repositor
toolsqa.com
- https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F
Git - What is Git?
Most operations in Git need only local files and resources to operate — generally no information is needed from another computer on your network. If you’re used to a CVCS where most operations have that network latency overhead, this aspect of Git
git-scm.com
- https://docs.github.com/en/get-started/getting-started-with-git/managing-remote-repositories
Managing remote repositories - GitHub Docs
Learn to work with your local repositories on your computer and remote repositories hosted on GitHub.
docs.github.com
'Study > Git 스터디' 카테고리의 다른 글
| GitHub에 작업한 파일 업로드 하는 법 (0) | 2024.01.31 |
|---|---|
| Git 기초 정리 (1) | 2024.01.26 |
| Git 전략과 그에따른 고찰 (1) | 2024.01.24 |
| Git 스터디(1 Team)_Git 이론 - 2 (0) | 2024.01.07 |
