Git의 동작원리를 알았다면 이제는 사용을 해봐야한다.
Git에는 수많은 기능들이 있지만, 여기서는 핵심적인 부분만 알아보려고 한다.
- Clone
- Add
- Commit
- Push
- Pull
- Branch
- Merge
- Fork
- Pull Request
Clone
git clone 원격저장소의 주소
직역하면 복제한다는 뜻이다. 다시 말하면, clone은 Remote Repository(원격 저장소)를 복제하여 Local Repository(로컬 저장소)에 저장한다는 뜻이다. 이전 시리즈에서 언급했듯이, Git은 버전관리를 위한 도구이면서, 협업에 최적화된 도구이다. 우리는 프로젝트를 작업하면서 각각의 로컬환경에서 기능을 구현하여 이를 Git의 Remote Repository(원격 저장소)에서 합쳐서 최종적으로 하나의 서비스를 만든다.
React를 사용하여 A라는 서비스를 만든다고 가정해보자. 이때, 참여인원은 총 3명이라면, 각자가 로컬에서 react 초기 셋팅을 진행한다는 것은 너무 시간의 낭비다. 이를 위해 한명이 먼저 로컬에서 react 초기 셋팅을 진행하고, 이를 원격저장소에 올리면, 나머지 2명의 인원은 이미 셋팅이 완료된 환경을 clone을 통해 추가적인 셋팅없이 각자의 local에서 진행하면 된다는 뜻이다.
Add
git add <파일/디렉토리의 경로>
로컬에서 내가 작업하는 환경 즉, working directory에서 local repository에 등록하기 전에 staging area에 등록하기 위해 거쳐야하는 과정이다. 이때, 주의해야할 점은 git add는 말 그대로 local repository에 등록하기 전에 하는 행위이기 때문에, git add를 수십번 하더라도 local repository에는 아무런 변화가 없다는 점이다. 즉, git add를 했다면, 언젠가는 반드시 commit을 해야한다.
Commit
git commit -m "메시지"
add로 staging area에 등록된 파일들을 모아서 일종의 snapshot의 형태로 local repository에 저장할 수 있게 한다. 때문에, commit을 할 때에는 해당 commit이 어떠한 내용(변경이 일어난 이유)과 관련된 것인지를 명확하게 알 수 있게 작성해야한다. 또한, 나의 과거 경험에 비추어봤을때, commit하는것을 절대 게을리 하면 안된다. 하루의 작업물의 양이 아무리 미미하고 보잘것없어서 내일것까지 합쳐서 commit해야지 라는 생각으로 commit을 미루었다가, 이후에 에러가 발생하였는데 commit의 내용과 관계없는 곳에서 에러가 발생하여 해결하는데 애를 먹었던 경험이 있었다. 때문에 되도록이면 기능을 구현하는 데 있어서 add는 한번에 하던지 아님 나눠서 하든지 각자의 자유겠지만, commit만큼은 하루의 루틴으로 정해놓고 그날 코드를 아예 건드리지 않은 이상 정해진 시간에 반드시 하는것이 좋겠다고 생각한다.
Push
git push 원격저장소명/브랜치명
commit까지가 나의 로컬에서만 일어나는 과정이었다면, push는 이제 이러한 변경들을 원격의, 다른 사람들과의 협업을 위해 적용하기 위해 사용된다. local repository에 저장된 snapshot을 remote repository에 전달하는 과정이다.
Pull
git pull 원격저장소명/브랜치명
단어 뜻 그대로 당긴다는 의미인데, 이제 pull 명령어는 fetch와 merge의 과정을 동시에 수행한다. fetch의 사전적 정의는 가져온다는 의미이다. 즉, 다른 사람들과의 협업을 통해 원격 저장소를 사용하는데, 이때, 원격저장소에 다른 사람이 변경된 사항을 업로드 했다면, 내가 pull 명령어를 사용했을 때, 나의 로컬과 다른 변경점들이 생긴다. 이때, 이러한 변경사항들을 나의 로컬 저장소에 가져온다. 그리고 merge의 사전적정의는 병합한다는 의미이다. 즉, 나의 로컬의 파일들과 병합하여 변경된 사항을 적용한다는 의미이다.
Branch
git branch 브랜치명 // 브랜치 생성
git checkout 브랜치명 // 브랜치 변경
사전적의미를 생각한다면, 가지 라는 의미이다. 다수의 인원간에 협업을 보다 효과적으로 진행하기 위해 git을 처음 생성하였을 때, 만들어지는 main branch(뿌리)에서 여러가지 목적으로 branch를 만들어서(가지를 뻗어서) 작업을 진행한다. 브랜치를 생성할 때에는, 어디서 그 가지를 뻗을지를 선택할 수 있고, 생성한 브랜치에서 작업시 그 branch가 뻗어나온 기존의 branch에는 영향을 미치지 않는다.
Merge
git merge 브랜치명
앞서서, pull에서도 그 개념이 나왔듯이 합치는 목적으로 사용된다. 어떠한 서비스에서 A라는 새로운 기능을 추가하기 위해 main branch에서 feat branch를 뻗어서 진행했다면, 해당 기능의 작성이 완료된 feat branch의 결과물을 main branch에 합치는 작업을 말한다.
Fork
일반적으로 Fork의 경우 앞서서 설명했던 clone과 유사하지만 하나의 큰 차이가 있다. clone의 경우 결국 Remote Repository에 있는 소스코드를 나의 Local Repository로 복제하기 위해 사용된다. 즉 원격에서 로컬로 복제할때, 사용한다. Fork는 다른 사람의 Remote Repository에서 나의 Remote Repository 즉, 원격에서 원격으로 복제할때, 사용한다.
Pull Request
종종 PR 보냈냐? 올렸냐?고도 한다. PR을 하는 상황은 크게 두가지가 있다.
첫번째는 다수의 인원이 하나의 서비스를 개발할 때, 만일 특정 기능을 추가하기 위해 branch를 새로 생성하여 작업후 merge를 요청하기 위해 사용된다.
두번째는 앞서 설명된 Fork를 해온 저장소에서 원본의 저장소에 merge를 요청할 때 사용된다.
두개의 경우 모두 필수적인 사항이 있는데, 당연하게도 branch를 생성하였거나 fork를 한 목적은 기존의 기능을 가져와서 여기에 어떠한 기능을 추가하거나 혹은 에러를 고치거나 등을 수행하기 위함이다. 때문에, PR은 곧 merge를 요청하기 위한 작업이기 때문에 반드시, 어떤 파일의 어떤 코드를 수정하거나 혹은 어떤 파일을 추가하고 그 목적은 무엇인지를 명확하게 작성하여야 한다.
