이 글은 Git에 대해 적은 글입니다. 이 포스팅을 포함해 게시된 모든 포스팅의 큰 주제는 순차적인 흐름을 지키지 않습니다. 혼란에 주의해 주세요!
개인의 실수로 폭파된 Git은 책임지지 않습니다!!!
들어가기 전에, 나는 Git으로 정말 많이 사고를 쳐본 경험이 있다. 프로젝트를 할 때도, 개인적으로 리팩토링을 할 때도, 혼자 Git을 활용하다 코드를 날려버린 적도, repository를 다시 생성한 적도 많았다. 때문에 난, 독보적인 Git 폭파범이란 꼬리표가 달렸었고, 한 때는 Git에 대한 트라우마(?)가 생겨 push를 하기 전에 반드시 옆에 동기나 멘토님을 끼고 push를 했던 기억이 있다. 그래서 이번에 정리하는 Git에 대한 내용은 내 개인적인 공부를 위함도 있지만, 동시에 하나의 반성문(?)이 되지 않을까 싶다. 아무튼 이번에 다루는 내용은 심화된 내용이 아닌 정말 기초적인 부분부터 다시 짚어볼 예정이니 참고하자!!
Git
형상 관리 도구이자 버전 관리 시스템
Git은 프로그램 소스 코드를 효과적으로 관리할 수 있는 위한 분산 버전 관리 시스템이자, 무료 공개 소프트웨어다. 분산 버전 관리라는 단어가 익숙하지 않은데, 다수의 개발자가 소프트웨어의 동일한 기능을 동시에 개발한다고 할 때, 작성된 소스 코드와 변경사항을 확인하고, 수정하는 협업을 도와주는 시스템이라고 생각하면 쉽다. 그런데 왜 이렇게 하여 작업을 진행하는 것일까? 지금부터 Git을 활용하는 이유와 장점을 동시에 알아보자.
🤔형상 관리 도구(Configuration Management Tool)
Git은 형상 관리 도구다. 형상 관리란, 소프트웨어 개발 및 유지보수 과정에서 발생하는 소스코드, 문서, 인터페이스 등 각종 결과물에 대해 형상을 만들고, 이들 형상에 대한 변경을 체계적으로 관리, 제어하기 위한 활동을 말한다. 다시 정리하면, 프로젝트를 진행하며 생성한 소스들을 Git과 같은 버전 관리 시스템을 이용하는 것이 바로 형상 관리다.
Git을 활용하는 이유와 장점
개발자들 간의 협업
혼자 개발을 한다면 막대한 업무량을 부담해야 하고 많은 시간 또한 투자해야 할 것이다. 이렇게 혼자 소프트웨어를 개발한다는 건 굉장히 어려운 일이기에, 수많은 개발자들이 하나의 프로젝트에 모여 협업을 하게 된다. 바로 이 협업이란 개념이 Git을 활용하는 이유이자 가장 큰 장점이다. Git을 통해 여러 개발자들이 동시에 작업할 수 있는 이른바 병렬 개발이 가능하다.
이렇게 협업을 진행하여 개발을 진행하면, 개발자들마다 구현한 기능도 다양해지겠지만, 소스의 양이 점점 많아지고 페이지도 방대해진다. 이런 상황을 방치하면 굉장히 업무가 비효율적으로 진행되지만, Git처럼 형상 관리 도구를 사용하여 특정 저장소에 소스코드, 문서 등을 보관할 수 있다. 게다가 내가 수정한 최신 소스코드를 저장소에 업로드하고, 다른 개발자의 소스코드를 내 저장소에 최신화하여 프로젝트를 진행을 고도화하여 형상관리를 할 수 있다. 이 밖에도, 내가 변경한 코드 이력과 다른 개발자가 변경한 코드 이력을 참고할 수 있어 훗날 코드를 다 같이 공유할 때 발생하는 충돌을 해결할 수 있다.
개인적으로 생각하는 Git의 최고의 장점은 바로 이전 버전으로 코드를 복구할 수 있다는 점이다. 수많은 개발자들이 동시에 작업을 하다 보면, 프로젝트 문서가 자주 업데이트될 것이다. 그러다 누군가가 잘못 작업해 특정 소스코드를 덮어써버리는 대형사고도 발생한다.(내가 그랬다.) 하지만, 분산 버전 관리 시스템의 특징은 특정 저장소에 어떤 이슈가 발생하여도, 원상복구 가능하다.(조금 억지스러운 부분도 있으나, 백업의 역할도 가능하다고 생각하면 이해하기 쉽다.)
Git을 활용하면 얻을 수 있는 장점
1. 프로젝트 소스코드를 협업에 참여하는 개발자 및 팀원들과 쉽게 공유할 수 있다.
2. 코드 변경이력을 참고할 수 있다.
3. 여러 개발자가 동일한 소스 코드를 공유하여 프로젝트를 진행할 수 있으며, 코드를 공유할 때 발생하는 충돌 문제를 해결할 수 있다.
4. 이슈 발생 시 이전 버전으로 원상 복구할 수 있다.
Git 기초 용어와 명령어 알아보기
기본적인 Git 관련 용어
Working Directory
작업 중인 프로젝트 파일들이 있는 내 PC의 디렉터리를 말하고, 자유롭게 프로젝트를 개발할 수 있다.
Staging Area
커밋할 변경 내역들이 대기하는 장소를 말한다. 'git add'명령어를 사용하면, 디렉터리에서 변경된 내용을 이 공간에 올려둔다. 명령어 옵션을 통해 이 과정을 생략할 수도 있다.
Commit
현재 폴더에서 변경된 작업내용 점검을 마치고 확정한 후, 저장소에 저장하는 작업이다. 커밋하게 되면, 저장소에 스냅샷을 기록하게 되면서 복원할 수 있는 지점을 만들게 된다.
Repository
파일이나 폴더를 저장해 두는 곳이다. Git 저장소의 장점 중, 하나는 파일들이 변경 이력 별로 구분되어 저장된다는 점이다. 종종 'repo'로 줄여서 말하기도 한다.
Branch
현재 진행 중인 작업과 성격이 다른 작업을 해야 할 때, 브랜치를 생성하여 작업을 한다. 보통 '브랜치를 딴다'라는 표현을 쓰며, master를 기준으로 브랜치가 생성된다. 브랜치를 통해 발자들이 동시에 다양한 작업을 할 수 있게 된다. 브랜치가 생성된 시점에서 master코드 작업과 분리되어 작업을 진행하게 되며, 브랜치에서 작업한 소스 코드는 나중에 merge작업을 통해 master코드 작업에 포함시킨다.
Master
Git에서 최초로 저장소를 만들게 되면, 자동으로 'master' 브랜치가 생성된다. 'master 브랜치'란 모든 저장소의 기본 이자 메인이라고 보면 된다. 일반적으로 저장소의 모든 것은 master 브랜치가 중심이 된다. 최종 결과물은 master 브랜치에 있기 마련이며, master branch로부터 파생된 다른 branch들로부터 수정 사항을 만든 다음 master에 병합하는 과정을 거치게 된다.
Merge
다른 브랜치에서 작업하여 커밋한 내용을 현재 브랜치(일반적으로 master 브랜치)로 가져와 병합하는 과정을 말한다.
😰 Master는 신성한 영역이다.
일반적으로 협업할 경우 각자 따로 브랜치를 쓰게 되며, 각 브랜치에서는 새로운 기능을 개발하거나 버그 수정이 이루어진다. 앞의 작업이 완료되면 최종적으로 'master 브랜치'에 병합을 하게 되는데, 브랜치를 따로 생성하지 않고 작업을 하게 되면, 메인 저장소의 코드를 수정하게 되는 것이다. 그러니 반드시 작업할 브랜치를 생성하고, 그곳에서 코드 수정 후 커밋하도록 하자!!
Git을 사용하기 위한 기초 명령어
git init
새로운 Git 저장소를 생성하거나 기존 저장소를 초기화하는 명령어.
git clone 저장소 경로
다른 곳에 있는 저장소를 복제하여 새로운 디렉토리로 생성하는 명령어. clone 명령어 뒤에는 로컬 저장소의 경로 혹은 원격 서버 저장소의 경로가 붙는다.
git branch 생성할 브랜치명
새로운 브랜치를 생성하는 명령어. 협업 과정에서 서로 다른 성격의 작업을 진행할 때, 각자 브랜치를 생성하여 자신만의 수정사항을 추가하고 커밋 스냅샷을 남긴다. 명령어 뒤에는 생성하고 싶은 브랜치 이름을 작성하면 된다.
git checkout 접근하고 싶은 브랜치명
브랜치를 이동할 수 있게 하는 명령어. 명령어 뒤에 생성되어있는 브랜치 이름을 붙인다.
git add . (권장하는 명령어)
git add 추가할 파일 이름
git add *
add 명령어는 Git에서 파일이 새로 추가되거나 변경된 것을 추적하여 Staging Area에 저장하는 명령어. add 뒤에 해당 파일 이름을 붙이면, 해당 파일만 추적이 되며 '.'을 붙이면 전체 파일을 추적하게 된다. 추가로 '*'을 사용하면 모든 파일을 Staging Area에 저장한다.
git commit -m "커밋 내용 요약 메세지"
바뀐 내용을 저장소에 기록하는 명령어다. Git의 핵심 명령어이며, 협업 중에 어떤 내용을 커밋하였는지 개발자들이 쉽게 파악할 수 있도록, 커밋 메시지를 직관적으로 작성한다.
git push
로컬에서 작업하여 커밋한 내용을 원격 저장소에 업로드하는 명령어. 보통 push 뒤엔 작업했던 브랜치명을 붙이게 되는데, master 브랜치에 push 하면 메인 저장소의 코드가 영향을 받으니 반드시 주의하자!!
git pull
로컬에서 작업하는 동안, 다른 개발자들에 의해 메인 저장소가 업데이트되는 경우가 발생한다. 이때, 저장소를 최신 버전으로 업데이트하기 위해 사용하는 명령어다. 보통 메인 저장소인 master 브랜치로 이동하여 pull 하여, 최신 코드를 업데이트한다.
git help
Git 명령어를 잊어버렸을 때, 사용하면 유용한 명령어. help 뒤에 사용하고 싶은 명령어를 입력하면, 해당 명령어에 관한 설명이 출력된다.
git status
현재 저장소의 상태를 확인하는 명령어. 저장소에 어떤 파일이 저장되어 있는지, 어떤 브랜치에서 작업 중인지 확인이 가능하다.
git log
커밋 기록을 조회하는 명령어.
git merge 브랜치명
브랜치 작업을 마치고, 프로젝트에 참여하는 모든 개발자들이 확인할 수 있도록 master 브랜치로 병합하는 명령어. merge 명령어 뒤에 병합시킬 브랜치명을 붙인다.
🤔일반적인 Git 적용 순서
1. 'git init' 혹은 'git clone'을 통해 디렉토리를 생성한다.(최초 1회 실행)
2. 'git branch' 명령어로 새로운 브랜치를 생성하고 'git checkout 브랜치명'으로 이동한다.
3. 이동한 브랜치에서 작업을 진행 및 완료가 되면, 'git add .'으로 Staging Area에 저장한다.
4. 'git commit -m "커밋 내용 요약 메세지"로 간단하게 작업한 내용을 기록한다.
5. 커밋 후, 'git push 브랜치명'으로 작업한 브랜치에 푸시한다.
6. 변경사항을 테스트하고, 이상 없다면 'git merge'를 통해 master 브랜치에 적용시킨다.
정리하며...
이번 포스팅을 통해, Git에 관한 정말 기본적인 부분을 짚어봤다. 물론 Conflict 이슈나, git rebase 명령어, Git의 동작 과정 등, Git에 관하여 다뤄야 할 부분이 아직까지 많이 남았다.(특히, 테러리스트인 나에겐 더더욱 Git 공부를 열심히 해야 한다.) 하지만, Git에 대한 개념과 사용하는 이유 그리고, 사용 명령어 등을 알아보며 Git에 대해 조금의 이해와 관심이 생겼을 것이라고 생각한다.(행복 회로) 아무튼, 기본적인 내용은 여기까지 정리하고, 조만간 Git에 대한 심화된 내용을 공부한 뒤에 포스팅해보겠다.
'ivory's DevLog' 카테고리의 다른 글
| JWT(JSON Web Token) (0) | 2020.12.19 |
|---|---|
| [React] - React Router (0) | 2020.11.22 |
| Webpack (0) | 2020.10.28 |
| Babel (0) | 2020.10.18 |
| [JavaScript] - this (0) | 2020.10.04 |