개인이나 회사에서나 개발 프로젝트를 진행할 때 대부분 Git을 사용하는 것을 볼 수 있다. Git이 무엇이고, 왜 사용하고, Git을 사용하는 방법에 대해서 정리를 해보고자 한다.
Git이란?
Git은 VCS(Version Control System)중에 하나로, 로컬 작업 공간에서 Project Code의 버전을 관리하기 위해 사용하는 프로그램이다.
Code Version을 관리해야 하는 이유?
- 수정할 때 마다 새로운 파일을 생성해야 하면 파일이 어마무지하게 쌓일 것이다... 따라서 별도의 파일 생성 없이 버전을 관리하는 것이 필요하다.
- 코드를 짜다가 갑자기 치명적 에러가 발생해서, 에러가 발생하기 전의 코드로 되돌리고 싶을 때가 있다. 버전을 관리해놓으면, 이전 버전으로 되돌리기만 하면 된다.
- 프로젝트는 여러명에서 한다!
여러명이 코드를 작성하는데 누가 이 부분을 수정했는지, 어떤 버전으로 배포되어야 하는지 알아야 협업이 가능하다.
그래서 GitHub는? Git이랑 무슨 차이일까?
Local에서 Git이라는 프로그램을 이용해하여 버전을 관리한 프로젝트를 Online상에 올려서 저장하고 관리하는 사이트이다.
지금부터는 Git Bash라는 콘솔창에서 작업이 이루어진다.
Git으로 버전을 관리하는 방법
1. git init
git init은 내가 버전을 관리하고자 하는 프로젝트 폴더에서 입력해야 한다.
내가 지금부터 이 폴더를 git을 이용해서 버전을 관리하겠다! 라는 명령이다.
이 명령어를 실행하고 나면, 폴더 내부에 .git 이라는 폴더가 생길 것이다.
2. git add .
띄어쓰기 주의!! add 다음에 띄우고 .을 붙여줘야 한다.
지금부터 파일이 수정된 이력들을 기록할 준비를 하겠다는 명령이다.
commit 하기 전에 무조건 이 명령어를 실행해줘야 한다.
3. git commit -m "커밋 내용"
File을 변경한 후 (새로운 코드를 작성하거나, 수정하거나, 삭제하거나 등등...),
수정 이력을 남겨야된다고 생각하는 시점에 사용하는 코드이다.
어떤 기능을 추가했는지, 어떤 부분을 업데이트했는지 그 내용을 -m 다음에 적어주면 된다. git commit -m "로그인 기능 구현"
4. git push origin 브랜치명
Local에서 commit한 내용들을 GitHub Repository(Online)의 해당 브랜치로 업로드하는 명령어이다.
아직은 깃허브와 연동된 것이 아니다. 위에서 커밋한 내용들을 앞으로 레포지토리에 넣어주기 위해서는, 로컬 프로젝트 폴더와 GitHub 레포지토리를 연결시켜주어야 한다.
GitHub 레포지토리와 프로젝트 폴더 연결 방법
1. gitHub 페이지에서 레포지토리를 생성한다.
2. git remote add origin 레포지토리 주소
origin이라는 변수에 레포지토리 주소를 저장한다고 생각하면 된다.
git remote를 쳐보면, origin이 생성된 것을 확인할 수 있다.
지금까지 커밋하고 푸시하는 기본적인 깃허브 사용법에 대해서 알아보았다.
처음 프로젝트를 시작할 때는 위의 방법대로 실행하면 되지만!
회사에서 프로젝트를 진행하는 경우, 기존의 프로젝트에 이어서 프로그래밍을 진행해야하는 경우가 대부분이다.
그래서 이미 존재하는 레포지토리를 내 컴퓨터로 가져오는 방법부터 브랜치를 나눠서 작업하는 방법, 다시 합치는 방법 등을 잘 숙지하고 있을 필요가 있다.
브랜치 나누는 이유?
master는 최종적으로 검증된 코드들이 합쳐지는(?) 구간이다. 만약 브랜치 없이 너도나도 master에 코드를 올린다면, 에러가 없는 보장된 코드가 보존되기 힘들 것이다. 그래서 각자 branch를 나눠서 작업을 하고, 문제가 없는 코드라고 판단이 되면, 그 때 관리자가 pull request를 통해 최종 코드를 master에 합치는 것이다.
Local로 Repository 가져오기
git clone 레포지토리 주소
레포지토리를 만들고자 하는 폴더에서 명령어를 실행하면 된다.
Branch 생성 / 삭제
git branch 브랜치명 / git branch -D 브랜치명
master -> branch로 전환하기
git checkout 브랜치명
repository에서 변경된 사항 가져오기
git pull origin master
강의 들은 내용과 자료를 바탕으로 다시 한번 그림을 그리면서 정리해보았다👩💻
1. 깃허브 레포지토리에서 로컬로 프로젝트 가져오기 (clone)
2. 내 브랜치 만들고 master -> branch로 넘어오기
branch를 만들고 해당 branch로 checkout했을 때,*가 현재 지정된 branch name 옆에 표시됨
3. 브랜치에서 작업한 내용 커밋, 푸시하기
4. 깃허브 레포지토리 들어가서
Pull Request보내기
5. 관리자가 Pull Request를 받고 내 코드를 Master에
merge함
6. 변경된 master의 내용을 내 로컬 프로젝트에 반영하기 위해,
다시 master branch로 바꾸고pull
[전체 과정]
GitHub에서 이루어지는 과정들이 어떻게, 왜 이루어지는지 잘 모르고 쓰다보니,
add -> commit -> push이 세 과정 빼고는 거의 써본적이 없는 것 같다.
Commit한 파일의 위치는? Local? Repository?
commit한 내용들을 push 했을 때 최종적으로 repository에 업로드 된다.
그럼 commit의 위치는 local인걸까, 레포지토리인걸까? 예상했을 때 local과 레포지토리 그 어딘가 라고 생각했는데, 더 자세히 알아보기 위해 찾아보았다.
정답은 Local의 Staging Area였다. Git에서 파일은 3가지 상태를 가진다.
Modified(파일 수정된), Staged(commit 대기 상태), Commited(commit된)
- add: 수정된 파일들을 Staging Area에 올릴 수 있게 됨
- commit: Staging Area에서 commit을 대기하고 있던 파일들을
로컬 레포지토리에 업로드- push: 로컬 레포지토리에 commit된 파일들을 리모트로 업로드
생각했던 것과 달리, push를 하기 전까지는 로컬에 있는 3개의 위치에서 파일이 저장된다는 것을 알 수 있었다.
마무리
전체적인 과정들을 순서대로 머리에 그려 넣고 나니, 각 명령어가를 언제 써야되고 어떨 때 써야하는지 더 확실해졌다. 명령어도 헷갈렸었는데, 그 과정들을 이해하니까 쉽게 이해할 수 있었던 것 같다.
이제는 불안해하지 않고 좀 더 적극적으로 깃허브를 이용할 수 있을 것 같다 ❗
