learn-git-1

GI JUNG·2022년 11월 27일

VSC fetch vs pull git git basic git command git fetch git pull github

git

목록 보기

1/3

git을 배우고자 한 것은 react로 오류가 떴는데 이를 따로 기록하고 내용을 기록하고자하다가.... 원본 파일과 오류를 고치는 도중 코드가 뒤엉켜(심지어 백업도 안 함ㅋㅋㅋㅋ) 병합하고 복구하는 정도는 배워야겠다고 생각하여 배우게 됐다.

시작하기 전에 git은 VCS(Version Control System)이다.
VCS가 먼지 살펴보자

🍀 VSC(Version Control System)

VSC의 풀네임을 보면 알 수 있듯이 버전을 관리해주는 시스템으로 해석할 수 있다.

vcs는 아래와 같이 총 3가지의 종류로 나눌 수 있다.

Local VCS: database를 이용하여 버전을 관리 함
Ex) RCS(Revision control system)가 존재한다.

CVCS(Centralized VCS): 중앙집중 버전관리로 다수의 사용자가 한 서버를 통해서 버전을 관리한다.
Ex) CVS, Subversion등이 존재하지만, 중앙 서버에 문제가 생기거나 충돌이 일어나서 생기는 단점이 존재한다.

DVCS(Decentralized VCS): 분산 버전관리 시스템으로 여러 명의 사람들이 다수의 서버에 접근하여 버전을 관리하는 시스템으로서, 한 서버에 문제가 생겨도 해결이 가능하며 충돌이 없고, 버전을 복구하는 것에도 문제가 없다.
Ex) Git, Mecurial, Bazaar 등이 존재한다.

🍀 What is Git & GitHub?

Git

Git 공홈을 보면 Git을 분산집중 버전 제어 시스템으로 repository들을 조직화 하며, 작거나 큰 프로젝트들을 빠르고 효율적으로 관리하기 위해 만들어진 소프트웨어로 소개한다.

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Git은 일단 사용자수가 워낙 많아 참고할 자료들이 많아 문제해결이 쉽고 Google, Microsoft, LinkeIn 등 거대 공룡 기업들도 사용하고 있다.

미루고 미루었던 Git은 2022 stackoverflow developer survey(technology -> vsc에서 확인가능)에서 무려 93.87% 개발자가 사용함을 알 수 있다.

그나저나 자료를 찾다가 stackoverflow에서 개발자를 대상으로 조사하는 것을 처음 알았다 ㅋㅋㅋㅋㅋㅋ 개발 트렌드를 읽기 매우 유용한 자료로 보인다. 🥳🥳🥳

GitHub

처음에 Git과 GitHub가 같은 줄 알았다... 하지만, 둘은 엄연히 다른 존재이다.
GitHub는 Version Control Platform으로서 Git repositories에서 클라우드 호스팅 제공자 역할을 수행한다. 즉, 우리가 작업하는 로컬 작업공간에 있는 코드들을 GitHub의 도움을 받아 서버에 저장할 수 있는 기능을 제공하는 것이 GitHub의 역할이다.

🍀 Git basic command

$ git status: 바뀌거나 추가 또는 commit해야 할 파일들을 나열해준다.
$ git config --global --user.name: git 사용자의 이름을 수정
$ git config --global --user.email: git 사용자의 email을 수정
$ git add file, [..., files]: staging area에 file들을 추가한다.

staging 영역을 모른다면 여기를 참고하자

$ git add -u(--update): 수정된 파일들만은 staging 영역에 추가한다.

git ls-files | xargs

$ git add .: 변경된 파일들을 모두 staging area에 추가한다.
$ git add -A: 변경된 파일 상관없이 모두 staging area에 추가한다.
$ git add -p: staging area에 추가하기 전에 하나하나 확인할 수 있다.
$ git log: 현재 있는 branch의 영역과 commit한 내용들을 볼 수 있다.
$ git log --oneline: git log의 명령어를 한 줄로 간단하게 볼 수 있다.

💡 git log를 통해 commit history를 조회하는 것은 아주 다양하다. 여기서 더 배울 수 있다.

$ git commit --amend --reset-author: commit 작성자를 변경한다.
$ git commit -m "기록한 메세지": push를 하기 전에 변경사항에 대해서 메세지를 단다.
$git push origin [repo]: 원격 저장소에 staging area에 있는 file들을 밀어넣는다.
$ git remote add orign [repo address]: 원격 저장소와 로컬을 연결한다.

🍀 git 사용해보기

git이 뭔지 알았으니 요놈을 사용해보고 익히기 위해 연습해보자.

☁️ remote repository 생성

git을 연습하기 위해서 원격 저장소를 만들어준다.
위와 같이 만들어 주면 local에서도 설정을 해주어야 하는데 아래와 같이 한다.

# git을 연습할 폴더 생성
$) mkdir learn-git
# local 저장소 git으로 초기화
$) git init
# local과 remote repo를 연결
$) git remote add origin [repo_uri]
# 연결된 remote 확인
$) git remote -v
# 변경사항 만듬
$) touch something.txt
# 변경사항 staging area에 넣기
$) git add something.txt
# 변경사항에 대한 snapshot을 commit으로 찍기
$) git commit -m "create something.txt"
# remote repo와 동기화
$) git push origin main

something.txt 파일을 만들면 local에서 변경사항이 생겨 staging area로 밀어넣어주고 commit message를 단 후 remote repo에 push를 하면 아래와 같이 원격 저장소에도 local과 같은 상태를 유지함을 볼 수 있다.

혼자서 개발할 때는 push를 하는 순간 원격 저장소와 로컬 저장소가 같을 수 밖에 없지만 팀원과 협업을 할 때는 나의 local 저장소와 원격 저장소의 상태가 같지 않을 수 있다. 이를 해결하기 위해서는 원격 저장소와 나의 저장소의 상태를 맞춰주어야 하는데 이 때 pull 또는 fetch를 사용할 수 있다.

☁️ fetch VS pull

fetch와 pull은 원격저장소의 상태를 가져오는 것은 같지만 가져온 내용을 병합 할지 말지와 연관이 있다.

fetch: 원격 저장소에서 내용을 가져 오기만 하며 local에 merge 하지 않는다.
pull: 원격 저장소에서 내용을 가져옴과 동시에 local에 merge가 진행된다.

즉 pull은 “fetch + merge” 의 형태라고 볼 수 있다. 이를 확인해보기 위해 간단한 실험을 해보자.

우선, github에서 [README.md] 를 수정하여 remote repo와 local 저장소의 상태를 다르게 만들자.

변경사항을 추가하고 commit을 하면 remote repo와 local의 저장소는 다른 상태를 갖게 된다. 이렇게 서로 다른 상태를 갖는다는 것은 다른 팀원의 local에서 remote repo로 push했음 을 의미한다.

이제 local로 돌아와서 README.md 파일을 확인해보면 아래와 같이 변경이 되지 않음을 확인 할 수 있다.

1️⃣ fetch

fetch를 이용하여 remote repo와 local repo의 상태를 fetch 를 이용하여 맞추어주자.

$) git fetch origin main

위의 명령어를 실행하고 다시 README.md 파일을 보아도 변경된 사항을 찾아볼 수 없다. 즉, 아직 병합이 진행되지 않았음
을 의미한다.

$) git status

git status command를 이용하여 변경사항을 확인해보면 아래와 같은 메세지를 확인할 수 있다. local에서 commit을 가리키는 HEAD는 remote에서 가져온 commit을 가리키는 HEAD와 다른 곳을 가리킨다는 메세지이다.

따라서 이제 remote와 local을 merge 를 이용하여 같은 상태를 맞춰 줄 수 있다. 아래 명령어를 실행해 보자

$) git merge

성공적으로 merge됐다는 메세지와 함께 README.md 파일도 변경됨을 확인 할 수 있다.

2️⃣ pull

위에서 pull 명령어는 fetch + merge 가 합쳐진 형태라고 언급했다. 한 마디로, pull을 진행하면 remote와 local이 자동 동기화가 된다는 의미다.

다시 github로 가서 remote repo의 README.md 파일을 변경하고 아래와 같이 pull을 진행해보자

$) git pull origin main

👇 pull 성공

👇 변경사항 병합 확인

결과를 보면 fetch와 달리 merge를 따로 진행하지 않아도 remote repo와 local repo의 상태가 맞춰졌음을 확인할 수 있다.

🥺 마치며

사실 git을 배우고자 했을 때는 todolist를 혼자 React로 개발하다가 오류가 너무 나서 파일을 찐 최종 과 같은 형식으로 local에서 관리를 하다가 잘못 삭제하는 바람에 의욕이 떨어져 다 던졌었다. 이 블로그를 처음 작성할 시기에는 지금으로부터 몇 개월 전에 작성하다가 revert, rebase를 배우다가 손을 놓아버렸지만 calendar라는 프로젝트를 혼자 진행하면서 다시 배우고자 마음 먹고 내용을 추가 보완하려고 들어왔다. 이번에는 git에 관한 블로그를 cherry pick까지 공부하고 올리는 것이 목표이다.