Git에 대하여, Github와의 관계
Git은 파일의 변경사항을 추적하고 프로젝트에 참여하는 사용자들이 공유하는 파일에 대한 작업을 조율하는데 사용되는 분산 버전관리 시스템이다.
일반적으로, Git을 초기화한 사용자는 자신의 로컬 컴퓨터에 저장소 (Local Repository)를 만들고, 그 저장소에서 작업한 소스코드를 원격저장소 (Remote Repository)와 연결하여, 다른 사용자들과 공유하면서 버전관리가 이루어진다.
Git은 분산 버전관리 시스템이기 때문에, 프로젝트를 공유하는 사람들은 파일 뿐만 아니라, 파일의 변경 기록까지 복제해오기 때문에 원격서버 (보통 Main github repository)에 문제가 생겨도, 정상적으로 작동하는 로컬 저장소를 활용해서 원격서버를 복원할 수 있어 유용하다.
그렇다면 Github은 무엇일까?
Github은 원격저장소 (Remote Repository)를 제공해주는 클라우드 서비스라고 이해할 수 있다. 로컬에서 Git을 통해 프로젝트의 버전관리를 시작해 Github에 공유할 수 있고, Github에 공유되고 있는 프로젝트를 Git을 통해 로컬으로 받아와 버전관리에 참여할 수 있다.
Git의 Workflow
앞서 설명했듯, Git은 로컬 컴퓨터에 저장소 (Local Repository)를 만들고, 그 저장소에서 작업한 소스코드를 원격저장소 (Remote Repository)와 연결하여, 다른 사용자들과 공유하면서 버전관리가 이루어진다.
Git에는 4가지의 영역이 있다.
1. Workspace (working directory)
- 현재 사용자가 작업중인 공간으로써, 실제 파일을 수정하거나 생성하는 공간
- 작업 폴더에서 .git 디렉토리를 제외한 나머지 부분
- Workspace는 tracked/untracked로 구분된다
1) untracked : 저장소 내에서 새로 만들어진 모든 파일들은 untracked 상태로 시작, untracked 상태인 파일들은 git이 코드 변경 이력을 추적하지 않는다. tracked 상태로 변경하려면, git add 커맨드를 통해 한 번 staging area로 넘겨야 한다.
2) tracked : git에 의해서 파일의 변경 이력이 추적되며, unmodifed/modifed로 나뉜다. 사용자가 workspace에서 tracked된 파일에 새로운 코드를 작성하는 등, 변경이 일어나면 파일의 상태를 modifed로 추적한다.
2. Staging Area
- Workspace에서 제출된 tracked 상태의 파일들을 관리 및 임시로 저장하는 공간
- git add 명령어를 통해 workspace의 untracked 파일 및 modifed 파일을 staging area로 제출
- git commit을 통해 로컬 저장소(local repository)로 이동하기를 기다리고 있는 공간
3. Local Repository
- Staging Area에 있는 파일들이 git commit 명령어를 통해 Staging Area에서 Local Repository로 저장되며, Staging Area는 비워진다
- Local Repository에 있는 파일들은 비로소, Remote repository로 이동 가능하며, 공유가 가능해진다
4. Remote Repository
- git push 명령어를 통해, Local Repository에서 옮겨지며, 일반적으로 Github Repository라고 생각할 수 있다
- git clone, git fetch, git pull 등의 명령어로 로컬 컴퓨터와 상호작용할 수 있다
Git의 Branch에 대하여
여러 개발자들이 각자가 맡은 작업을 독립적으로 수행할 수 있도록 도와주는 Git의 기능이다. 각각의 branch는 서로 영향을 받지 않기 때문에, master branch를 중심으로 다양한 과제들을 branch를 나눠 작업을 수행한 후, master branch에 merge하면서 버전관리를 진행한다.
이러한 방식으로 작업할 경우, '작업 단위', 즉 branch로 그 작업의 기록을 중간 중간에 남기게 되므로 동시에 여러 작업을 진행할 때의 작업 흐름을 한 눈에 파악하기 쉬우며, 문제가 발생했을 경우 원인이 되는 작업을 찾아내기 편해진다.
Git의 기본 명령어
1. git init : 일반 작업 디렉토리를 Git 저장소로 초기화하는 명령어 (npx create-react-app, npx create-next-app 등, 프레임워크 설치시 자동으로 git init이 수행되어 있는 경우가 있음)
2. git status : Local Repository의 상태를 체크하며, 어떤 파일이 저장소에 있는지, 커밋이 필요한 변경사항이 있는지, 현재 저장소의 branch 등의 상태정보를 출력
3. git add : workspace의 untracked 혹은, modified 파일을 staging area에 반영
4. git commit : Staging Area에 있는 파일을 Local Repository로 옮기는 명령어, 보통 git commit -m "" 으로 ""안에 변경사항에 대한 메세지를 입력하여, 버전관리의 편의성을 증대시킨다
5. git push : Local Repository에서 최종 commit된 내용을 Remote Repository에 반영한다, 그러나 Local Repository의 상태가 최신 버전이 아닌 상태에서 git push를 시도하면, 충돌이 일어난다.... 이 경우에는, git push 하기 전에, git fetch 하여 Remote Repository의 최신 버전을 먼저 받아 비교 대조한 후, git merge를 수행하고 git push를 진행하여야한다
6. git pull : Remote Repository의 변경사항을 Local Repository에 가져오고, Local branch를 기준으로 merge하려고 시도한다.
자동 병합 기능이며, 크게 권장하지 않는 커맨드.... (하지만 나를 포함한 많은 개발자들이 잘못 알고 사용한다고 한다) git fetch의 사용이 권장된다 (git pull = git fetch + git merge)
7. git fetch : Remote Repository의 변경사항을 Local Repository에 단순히 가져오는 기능을 하며, 그것을 현재의 branch에 merge할지 말지는 선택으로 남겨둔다
수동 병합 기능이며, git fetch하여 원격과 로컬의 차이를 비교 대조하고, git merge를 통해 병합을 한다
8. git merge : Local branch의 상태를 Remote branch와 통합한다 . 그림에서 master은 Local branch이며, origin/master은 Remote branch이다.
git merge 후,
9. git clone : Remote Repository의 데이터를 로컬 컴퓨터에 복사한다. 처음 프로젝트에 참여할시, 프로젝트 매니저가 생성해놓은 Remote Repository의 내용을 자신의 로컬 컴퓨터에 동기화하는데 사용한다
10 git branch : 새로운 branch를 생성
11. git checkout : 작업하는 branch를 이동하는 명령어이며, git checkout -b를 통해 새로운 branch를 생성하면서 이동하는 것이 가능하다.
ex 1) git checkout main -> main branch로 이동
ex 2) git checkout -b molly -> molly branch를 만들고, molly branch로 이동
12. git stash : 변경 내용을 임시 저장하는 명령어, untracked된 파일 (새롭게 생성된 파일)의 경우는 임시 저장되지 않는다. 임시 저장된 후, workspace는 최신의 commit 했던 상태로 돌아간다.
보통 commit하기 애매한데, branch를 이동해서 다른 작업을 해야하는 경우 사용된다. 작업하던 내용을 임시저장하고, branch의 작업을 끝낸 다음 git stash apply를 통해 임시저장된 내용을 다시 workspace에 적용한다.
1) git stash save "" : "" 안에 메세지를 넣어, 메세지와 함께 임시저장할 수 있다.
2) git stash list : 임시저장된 목록을 index와 함께 확인할 수 있다.
3) git stash apply stash@{index} : 임시저장된 목록 중 index를 적용한다.
13. git diff : workspace와 Staging Area 사이의 차이를 비교한다
*git diff HEAD는 workspace와 Staging Area의 변경사항 모두를 Repository의 HEAD Commit과 비교한다
14. git log : commit 내역들을 확인한다
참고자료
https://m31phy.tistory.com/146
https://ryanking13.github.io/2021/10/17/why-git-pull-is-broken.html
https://velog.io/@luna238/Git-branch%EA%B5%AC%EC%A1%B0%EC%99%80-git%EB%AA%85%EB%A0%B9%EC%96%B4
