Git에 관련된 용어와 명령어

KIMYEONGJUN·2024년 1월 11일
0

목적

회사를 다니면서 Git을 자주 접하게 된다. 회사를 다닐때 git을 제대로 공부못한 사람으로 인식이 되어서 이번기회에 git을 정리하고 나중에 내가 git용어를 까먹었을 때를 대비해서 나를 다시 가르치는 느낌으로 글을 써보겠다.

Git은 버전 관리 시스템(Version Control System, VCS)의 하나이다.
쉽게 이야기하면 말 그대로 버전을 관리할 수 있는 수단이다. 수정 사항이나, 업데이트 사항 등을 그때 그때 바로 반영 할 수 있도록 하는 시스템을 말한다.

버전 관리 시스템(VCS)는 파일 내 변화를 시간의 흐름에 따라 기록했다가 이후 필요한 상황에서 그 파일을 꺼내올 수 있는 시스템을 말한다.

우리가 문서를 작성할때 최종 시안을 작성하기위해서 수많은 수정이 발생한다. 그때마다 파일 이름을 변경해가면 파일을 덮어쓰기를 한다.

이때 특정 시점의 내용으로 돌아가 그 내용을 파악하려고 하면 그게 가능할까? 물론 가능하다. 하지만 내용이 많이 수정되었기 때문에 하나 하나 파악하는데 시간이 많이 들게된다.

이런 상황을 대비해서 활용할 수 있는것이 버전 관리 시스템이다.
버전 관리 시스템을 활용해서 시간에 따른 수정 사항 및 수정자를 확인 할 수 있다. 또한 이전 버전으로 돌아갈 수 있고, 문제가 발생했을때도 쉽게 파악할 수 있다.

VCS의 종류는 뭐가 있을까?

로컬 버전 관리 시스템(Local VCS)

로컬 버전 관리 시스템은 간단한 데이터베이스를 이용해 파일의 이력을 관리하는 시스템이다. 유명한 로컬 버전 관리 시스템으로는 RCS(Revision Control System)가 있다

중앙 집중식 버전 관리 시스템 (CVCS, Centralized Version Control System)

중앙 집중식 버전 관리 시스템은 파일 및 변경 이력 등을 서버로 옮긴 것이다. 중앙의 서버가 파일들과 이들의 변경 이력을 관리하고, 각 클라이언트는 서버에 접속해서 특정 버전의 스냅샷(snapshot)을 받아서 사용하는 형태로 동작한다.

스냅샷은 사진을 찍듯이 특정 시간(시점)에 데이터 저장 장치(스토리지)의 파일 시스템을 포착해 별도의 파일이나 이미지로 저장, 보관하는 기술을 말한다.

CVCS를 사용하면 프로젝트에 참여한 사람들 중 누가 어떤 작업을 하는 지 쉽게 확인 가능하다는 장점이 있다. 또한 모든 클라이언트의 로컬 데이터베이스를 관리하는 것보다 VCS 하나를 관리하는 것이 훨씬 쉽기 때문에 협업 시 많이 사용된다.

하지만, 중앙 서버가 다운되는 등의 문제가 발생할 경우 그 상황 동안에는 작업이 불가능하다. 또한 하드디스크에 문제가 발생하면 모든 히스토리를 잃을 수도 있다는 단점이 있다.

분산식 버전 관리 시스템 (DVCS, Distributed Version Control System)

개발자들이 독립적으로 작업한 다음에 변경 사항을 병합할 수 있기 때문이다.

분산 버전 관리 시스템에서의 클라이언트는 단순히 파일의 마지막 snapshot을 사용하지 않는다. 저장소를 히스토리와 더불어 전부 복제하는 방식이다. 만약 서버에 문제가 생긴다면, 복제했던 것을 통해 다시 작업을 시작할 수 있다. 또한 클라이언트 중에서 아무거나 골라도 서버를 복원할 수 있다.

따라서 다양한 협업 시 주로 사용되며, git이 이 분산 버전 관리 시스템에 속한다.

Git를 사용하는 이유?

쉽게 버전 관리를 할 수있다. 또한 분산 버전 관리 시스템이기 때문에 중앙 서버가 필요없고 인터넷이 연결되어 있지 않는 상황에서도 작업이 가능하다. 그리고 작업 도중에 이상이 생겨서 저장소가 날라가도 복구가 가능하다.

Git의 주요 개념

Repository (저장소): 소스 코드들이 저장되어 있는 물리적인 공간을 의미한다. 작업을 시작할때 원격 저장소에서 로컬 저장소로 소스 코드를 복사해서 가져오고(clone) 이후 소스코드를 변경한 다음 커밋(commit)한다. 커밋한 소스는 로컬 저장소에 저장되고 push 하기전까지는 원격 저장소에 반영되지 않는다.

Working Tree: 내가 사용하는 폴더를 말한다.

Index (= Staging Area): commit을 실행하기 전의 저장소와 Working tree 사이에 존재하는 공간을 말한다.

Commit: 작업 과정들에 대한 점검을 마친뒤 저장소에 남기는 과정을 의미한다. git log 명령어를 통해 커밋된 내용을 확인할 수 있다.

Checkout: 특정 시점이나 branch의 소스 코드로 이동하는 것을 의미한다.

Branch: commit 단위로 구분된 소스 코드 타임라인에서 분기해서 새로운 commit을 쌓을 수 있는 가지를 만드는 것을 말한다. branch에서 작업을 완료하면 commit을 하고 push를한다음에 merge 작업을 하면된다.

Merge: branch와 branch의 내용을 합치는 작업이다. 즉 병합을 말하며 branch와는 다소 반대되는 개념이다. 병합과정중 두 branch에서 하나의 동일한 파일에서 서로 다른게 수정한 경우 충돌이 발생하며 병합이 일시정지 된다. 이때 충돌 부분을 직접 수정하거나 merge tool을 이용해서 충돌된 부분을 해결한후에 병합을 해주면된다.

git 명령어

충돌방지 실행 권장순서
pull -> coding -> commit -> pull -> push
충돌을 최소화하기 위해서 자신의 저장소와 원격 저장소의 상태를 자주 업데이트해줘야한다.

분류명령어내용 설명
새로운 저장소 생성$ git init.git 하위 디렉토리 생성 (폴더를 만든 후, 그 안에서 명령 실행 => 새로운 git저장소 생성)
저장소 복제/다운로드(clone)$ git clone <https:.. URL>기존 소스 코드 다운로드/복제
$ git clone /로컬/저장소/경로로컬 저장소 복제
$ git clone 사용자명@호스트:/원격/저장소/경로원격 서버 저장소 복제
추가 및 확정(commit)$ git add <파일명>
$ git add *
커밋에 단일 파일의 변경 사항을 포함 (인덱스에 추가된 상태)
$ git add -A커밋에 파일의 변경 사항을 한번에 모두 포함
$ git commit -m "커밋 메시지"커밋 생성 (실제 변경사항 확정)
$ git status파일 상태 확인
가지(branch)치기 작업$ git branch브랜치 목록
$ git branch <브랜치이름>새 브랜치 생성 (local로 만듦)
$ git checkout -b <브랜치이름>브랜치 생성 & 이동
$ git checkout mastermaster branch로 되돌아 옴
$ git branch -d <브랜치이름>브랜치 삭제
$ git push origin <브랜치이름>만든 브랜치를 원격 서버에 전송
$ git push -u < remote > <브랜치이름>새 브랜치를 원격 저장소로 push
$ git pull < remote > <브랜치이름>원격에 저장된 git 프로젝트의 현재 상태를 다운받고 + 현재 위치한 브랜치로 병합
변경 사항 발행(push)$ git push origin master변경사항 원격 서버에 업로드
$ git push < remote > <브랜치이름>커밋을 원격 서버에 업로드
$ git push -u < remote > <브랜치이름>커밋을 원격 서버에 업로드
$ git remote add origin <등록된 원격 서버 주소>클라우드 주소 등록 및 발행 (git에게 새로운 원격 서버 주소 알림)
$ git remote remove <등록된 클라우드 주소>클라우드 주소 삭제
갱신 및 병합(merge)$ git pull원격 저장소의 변경 내용이 현재 디렉토리에 가져와지고(fetch) 병합(merge)됨
$ git merge <다른 브랜치이름>현재 브랜치에 다른 브랜치의 수정사항 병합
$ git add <파일명>각 파일을 병합할 수 있음
$ git diff <브랜치이름><다른 브랜치이름>변경 내용 merge 전에 바뀐 내용을 비교할 수 있음
태그tag 작업$ git log현재 위치한 브랜치 커밋 내용 확인 및 식별자 부여됨
로컬 변경사항 return 작업$ git checkout -- <파일명>로컬의 변경 사항을 변경 전으로 되돌림
$ git fetch origin원격에 저장된 git프로젝트의 현 상태를 다운로드

remote
저장소는 각자의 고유한 브랜치(branch)를 생성하고 관리한다. 원격 저장소에 생성한 브랜치를 리모트 브랜치(remote branch)라고 한다.

git fetch
원격 저장소에서 코드를 수동으로 내려받는 작업이다.
원격 저장소에서 커밋된 코드를 임시 브랜치로 내려받는다. 내려 받은 후 현재 브랜치와 자동 병합하지 않는다.

git checkout
현재 branch를 떠나 새로운 branch로 이동한다.
깃은 하나의 워킹 디렉토리만 갖고있기 때문에 한 브랜치에서만 작업과 커밋을 할 수 있다. 다른 브랜치에서 새로운 작업을 하려면 반드시 브랜치를 변경하여 워킹 디렉토리를 재설정해야 한다.

git log
현재까지 작업한 로그 기록을 확인한다.
--graph 옵션을 함께 사용하면 로그를 출력할 때 브랜치 흐름도 같이 출력한다.
--graph --all을 사용하면 모든 로그를 출력한다.
q를 눌러서 종료한다.

git add
워킹 디렉토리에 파일을 추가하면 추적되지않음 상태이다.
이때 git add를 실행해서 스테이지 영역에 등록하고 tracked(추적) 상태로 변경해야 한다.

git commit
변경된 파일 차이를 깃 저장소에 기록한다.
생성된 객체를 기록하는 것과 동시에 이를 구별할 수 있는 메시지를 같이 작성해야 한다.
-s => 개발자의 싸인
-m => 커밋메시지를 작성
-a => 커밋을 하기 전에 자동으로 모든 파일을 등록하는 과정을 미리 수행한다.

git push
원격 저장소로 로컬 깃 저장소의 커밋된 파일들을 업로드하는 작업이다.

git pull
원격 저장소의 갱신된 내용을 추가로 내려받는 작업이다.
로컬 저장소보다 최신인 갱신된 원격 저장소의 커밋 정보를 현재 로컬 저장소로 내려받는다.
pull 명령어를 주기적으로 사용하면 최신 커밋 정보로 로컬 저장소를 유지할 수 있다.

마무리

Git에 관련된 용어와 명령어관련된 개념을 복습했다. 하지만 양이 너무 많기때문에 단번에 익히고 작업을 할 수는 없을것같다. 계속 자주 자주 보는면서 익힐려고 한다. 오늘 복습한 양이 너무 많아서 머리가 아프지만 앞으로 조금더 나은 개발자가 되기위해서 한걸음더 노력하고싶다.

profile
Junior backend developer

0개의 댓글