Git
항상 올바른 표현으로 코드를 작성하고 수정할 수 있다면 좋겠지만, 우리는 사람이기 때문에 실수를 할 수 있다. 비단 실수 뿐 아니라, 새로운 기능을 추가하거나 버그를 해결하면서 돌이킬 수 없는 문제가 발생할 수 있기 때문에 코드를 작성할 땐 이전에 작성한 내용을 보존할 필요가 있다. 이렇게 버전별로 코드를 보존해주는 시스템을 버전 관리 시스템(Version Control System)이라 한다. 버전 관리 시스템은 단순히 버전을 관리해주는 것을 넘어, 협업을 하는데에 있어서도 중요하다. 여러 사람이 동시에 같은 코드를 작업했을 때 버전 관리가 가능하다면 손쉽게 이전 상태로 돌아갈 수 있으며, 해당 버전에 어떤 사항이 변경되었는지 코멘트를 남기는 것도 가능하기 때문이다.
버전 관리 시스템 중 가장 많이 쓰이는 Git은 개발자의 코드를 효율적으로 관리하기 위해 개발된 ‘분산형 버전 관리 시스템’이다. 가장 강력하고 대중적이며 현업에서는 물론 취업을 위한 포트폴리오, 레퍼런스로도 많이 쓰인다.
commit
버전 관리 시스템의 기본적인 모습은 위와 같다. 날짜 별로 어떤 파일이 어떻게 바뀌었는지 확인이 가능하며 특정 시점에 생성된 백업 복사본을 스냅샷이라 하는데, 이렇게 하나하나 스냅샷을 만들어주는 작업을 commit이라 한다. commit을 통해 변경 사항에 대한 스냅샷이 만들어지고 이전 기록에 대한 추적이 가능하며 이는 버전 관리뿐 아니라 회사에서의 협업에도 유용하다.
Git Repository
Git으로 관리되는 폴더, 즉 Git에서 코드를 저장하는 공간을 Git Repository라 한다. Git Repository는 Remote Repository(이하 Remote)와 Local Repository(이하 Local) 두 종류의 저장소를 제공하며 작업은 내 컴퓨터의 저장소인 Local에서 진행하게 되고 클라우드인 Remote에 프로젝트를 업로드하여 사람들과 공유할 수 있다. 물론 다른 사람이 Remote에 올려놓은 소스 코드를 내 Local에 가지고 올 수도 있다.
Fork와 Clone
다른 사람의 Remote에 올려둔 소스 코드를 내 Remote로 가져오는 작업을 Fork라 한다. 하지만 이 작업만 하게 되면 Local에 저장된 것이 아니기 때문에 실질적인 작업을 진행할 수는 없다.
Fork한 소스 코드를 Remote에서 내 Local로 가져오는 작업을 Clone이라 한다.
Push와 Pull
내 컴퓨터에서 소스 코드 변경작업을 완료했다면 변경한 내용을 commit을 통해 저장한 뒤, 반대로 Remote에 업로드하여 반영하는 작업을 해야한다. 이 작업을 Push라 하며 만약 다른 사람의 프로젝트에 내가 기여를 하는 상황이라면 내가 제안한 코드 변경사항에 대해 반영 여부를 요청하는 Pull Request 기능을 사용할 수 있다.
반대의 경우도 있다. Remote에 변경사항이 있어 내 Local에 반영을 해야할 때는 Pull 작업을 사용할 수 있다.
Github
Git이 소스 코드 기록을 관리하고 추적할 수 있는 버전 관리 시스템이라면, Github는 Git Repository를 관리할 수 있는 클라우드 기반 서비스다. 즉, Git으로 관리되는 폴더에 대해 여러 사람들이 공유하고 접근할 수 있는 개발자의 SNS이며, Github에서 Code Review 등의 협업이 가능하고 수많은 오픈 소스 프로젝트에 접근하여 자유롭게 기여할 수 있다. 또한, 클라우드 기반 서비스이기 때문에 내 컴퓨터에서 Git으로 관리하는 프로젝트를 올려두고 백업에 활용할 수 있다.
Git 사용법
Local Repository
로컬 환경의 디렉토리에서 Local을 생성하면 해당 디렉토리의 파일 변화를 감지할 수 있다. 파일의 변화를 기록하는 절차는 다음과 같다.
1. git init : 코드를 저장할 디렉토리에 Local Git repository를 생성
.git 이라는 폴더가 생성된다.2. git add : 작업 공간의 파일 및 디렉토리를 staging area에 추가
파일을 생성하고 변경했다면 Git이 트래킹할 수 있도록 이 코드를 하나로 모아두는 과정을 거치게 된다. 이 공간을 staging area라 한다. git add <경로명> 명령어를 통해 staging area로 옮길 수 있으며, 현재 경로에서 변경이 감지 된 모든 파일을 한 번에 추가하려면 git add .을 입력하면 된다.
git status를 입력하여 확인할 수 있다. 변경되었거나 추가되지 않은 파일은 빨간색으로 표시된다.
3. git commit : staging area에 있는 코드에 라벨링하기
staging area의 파일은 commit이 가능하며, 이를 통해 Local에 내 코드를 기록할 수 있다. 다시 말해 staging area에 임시 저장해둔 파일의 저장을 확정짓고 이름을 붙이는 것이다. commit한 내용에 코멘트를 추가하려면 git commit -m "<commit Message>" 을 쓰면 된다.
Remote Repository
만들어진 Local은 Remote와의 연결이 필요하다. 그 절차는 아래와 같다.
1. Github에서 원격 리포지토리를 생성
Github에 접속하여 새로운 리포지토리를 생성한다. 이 때, Public / Privite 여부를 결정할 수 있다. 이름은 가능하면 Local의 디렉토리 이름과 같게 설정하면 좋고, Owner가 자신의 아이디인지 꼭 확인하자.
2. git remote add : Local에 Remote Repository git url을 등록
Local에 Remote 주소를 등록한다. 쉽게 Remote를 파악하기 위해 이름을 지정할 수 있고, 이름 뒤에 Remote의 주소를 적으면 작동한다. git remote add <name> <URL>
<name>: 앞으로 Local에서 Remote의 주소를 대신할 이름 (ex.origin)
<URL>: Remote 주소 (ex.git@github.com:codestates-seb/agora-states-fe.git)
3. git push : Local에 기록한 내역을 Remote에 반영
Local에서 commit이 완료된 내역을 Remote에 반영한다. 이 때, git push <remote> <branch> 와 같은 방식으로 매개변수를 추가로 작성할 수 있다.
<remote>: Remote의 이름
<branch>: 브랜치의 이름
4. git pull : Remote에 반영된 내역을 Local에 합치기
개인 작업일 경우 Fork해온 프로젝트가 아닌 이상 쓸 일이 많지 않지만 협업 시에는 많이 사용한다. Remote에 반영된 수정사항 등을 기존 작업중인 Local에 합친다. git pull <remote> <branch>
<remote>: Remote의 이름
<branch>: 브랜치의 이름
이 때 특정 commit 시점으로부터 각기 다른 commit을 만들면 기본적으로는 자동으로 병합(merge)이 된다.
기타 명령어들
git reset: commit한 기록을 되돌릴때 사용한다.git reset HEAD를 입력하면 직전에 커밋한 기록을 지울 수 있으며,HEAD~$의 형식으로 숫자를 입력하여 직전 커밋의 갯수도 지정 가능.
git log: commit log를 확인할 수 있다.
git remote --verbose: 연결된 리모트 리파지토리의 목록을 확인한다.-v로 축약도 가능하다.
Uploaded by N2T