1. Git & Github
1) VCS(Version Control System)
- Version : 어떤 프로그램을 수정하고 개선해서 완성하는것, 이전과 약건씩 다른 변화들을 구분하는 표시를 말한다. (feat. git)
예) - 버전 관리 없이 작성한 파일
사진출처 : 나무위키
- 위 이미지처럼 파일 이름을 대충 지으면 파일 이름이 장황해지고 무엇이 더 먼저인지 알기 어려워진다. (즉, 누가 작성하고 수정했는지? 작성하고 수정한 날짜와 시간이 언제인지? 몇번째 버전으로 작성한 것인지 정확하게 알기 어려워 버전별로 관리하기 어렵다는 뜻이다.)
2) Git
- 프로젝트 파일의 변경 사항을 추적하는 분산 버전 관리 시스템으로, 이를 통해 개발자들은 프로젝트의 변경 사항을 기록하고, 특정 시점의 버전으로 언제든 돌아갈 수 있다.
- 개별 버전의 프로젝트를 병합하여 기준이 되는 버전의 프로젝트에 적용 할 수 있다.
- 많은 사람들이 효율적으로 함께 작업하고, 프로젝트를 중심으로 협업할 때 사용할 수 있다.
3) 형상관리란?
- 버전관리(Version Management) 라고도 부름
- 각자가 개발한 코드들을 하나의 통합적인 관리도구 안에서 버전별로 분류하여 관리함
- 형상관리는 보통 중앙집중식과 분산관리식으로 나뉨
- 중앙집중식 : 개발자가 작성한 코드/파일들을 한대의 컴퓨터 시스템 안에서 제어해서 관리 (ex. SVN)
- 분산관리식 : 한대의 컴퓨터에서만 코드/파일들을 제어하지 않고 Tree 형식의 버전별로 분산시켜 관리 (ex. git)
3-1) Git & SVN의 장단점
-
SVN(Subversion) : 로컬 PC에서 프로젝트를 commit하면 중앙 저장소에 반영
(장점 : 직관적이라 사용하기 쉬움)
(단점 : 프로젝트를 commit 하다가 충돌이 일어나거나 에러발생시 복구가 어려움) -
Git : 로컬 PC에서 프로젝트를 commit 하면 로컬 저장소에 반영되고, 로컬 저장소에서 push 하면 원격 저장소에 반영
(장점 : 처리 속도가 SVN보다 빠르고 에러가 발생해도 복구가 쉬움)
(단점 : 직관적이지 못하고, 공유과정이 복잡함)
- commit : 실제로 제작한 프로젝트 수정 내용을 이력을 기록한다는 뜻
- push : 작성한 코드를 원격 저장소에 업로드 한다는 뜻
4) 왜 코드도 버전 관리를 해야할까?
- 수정할때 마다 파일을 새로 만들면 관리가 힘들기 때문
- 언제든 이번 버전의 코드로 돌아갈수 있기 때문
- 어떤 개발자가 코드를 작성했는지 확인할수 있기 때문
- 하나의 프로젝트를 두고 여러명의 개발자들이 협업 할수 있기 때문
5) Github
- Git repository를 위한 호스팅 플랫폼으로, GitHub (및 유사한 플랫폼(예 : Source Tree)) 없이도 Git을 사용할 수 있지만 다른 개발자와 같은 프로젝트를 두고 협업하거나 내 코드를 직접적으로 공유하긴 어렵다.
(6) 기본적인 Git 명령어
-
Git init : git 저장소의 버전 관리를 위한 정보 생성
(버전관리를 하고 싶은 디렉토리에서 확인하고자 할때 쓰는 명령어 : git init)
-
Git status : git 상태 확인
(디렉토리에서 일어나고 있는 지금의 상태를 확인하는 명령어 : git status)
예제 실습)
(1) git_practice 폴더에 파일이 없을 경우
(2) git_practice 폴더에 파일을 생성시켰을 경우
(요약 : mkdir로 git_practice 폴더를 생성하고 git status로 해당 폴더에 Git 프로젝트 및 문서 내용들이 있는지 확인했는데 폴더에 내용이 없었고, 지금은 md(mark down)로 파일을 생성해서 넣었더니 seonghokim.md 라는 파일이 있다고 터미널에 보여줌
(다만 파일이 추적이 되고 있지만 기록이 없는 파일 (untracked files)) -
Git add : 파일 수정 이력을 기록 준비
(예 : A사 태플릿 PC를 구매하기 위해 카드 결제를 준비하는 것)
.
(git 에서 수정한 파일의 이력을 남길 준비를 하는 명령어)
.
(1. 특정 파일에만 이력을 남기고 싶을때 : git add[파일이름])
(2. 변경된 파일의 전체 이력을 남기고 싶을때 : git add .)
.
예제실습)
(1) 한줄의 commit 메세지 작성 준비가 끝났을 경우
(요약 : md 파일에 commit 메세지를 작성해서 기록할 준비가 완료됐다는 뜻) -
Git commit : 수정한 프로젝트의 내용 이력을 실제로 메세지로 기록
(수정한 파일의 이력을 남기는 명령어)
.
(1. 한줄로 커밋 메세지를 남기고 싶을때 : git commit-m "메세지")
(2. 여러줄의 커밋 메세지를 남기고 싶을때 : git commit)
.
예제실습)
(1) 한줄안에서만 메세지를 작성할 경우
(2) 여러줄에서 commit 메세지 작성할 경우
-
Git log : commit의 이력을 확인
(남겨진 이력들을 확인할때 사용하는 명령어 : git log)
.
**예제실습)
(1) 처음에 작성한 한줄 commit 메세지 이력을 확인하고자 할경우
( 요약 : git log로 md 파일에 commit한 메세지 "자기소개 파일 생성" 가 잘 적용되었다고 나옴)
- Git push : 작성한 코드(또는 프로젝트)를 원격 저장소에 업로드(저장시킨다.)
(이력을 남긴 코드들을 github에 올리고 싶을때 사용하는 명령어 : git push origin [브랜치이름])
2. Repositories(저장소)
- Git repository는 Git으로 관리하는 프로젝트 저장소를 말하며 Git repository는 크게 두 가지 종류가 있다.
- Local repository(로컬 저장소) : 본인의 컴퓨터에 저장된 로컬 버전의 프로젝트 저장소
- Remote repository(원격 저장소) : 외부(일반적으로 원격 서버) 버전의 프로젝트 저장소, 즉 Github의 원격 저장소를 말한다. 원격 저장소는 팀에서 작업 할 때 특히 유용하며, 프로젝트 코드를 함께 공유할 수 있고, 다른 사람의 코드와 Pull Request를 활용한 코드 리뷰도 확인할 수 있다. 또, 로컬 버전의 프로젝트와 병합하고, 변경 사항까지도 적용 할 수 있는 곳이다.
3. branchs (브랜치)
- 브랜치는 독립적으로 어떤 작업을 진행하기 위한 개념으로, 필요에 의해 만들어지는 각각의 브랜치는 다른 브랜치의 영향을 받지 않기 때문에, 여러 작업을 동시에 진행할 수 있다.
- 여러 명이서 동시에 작업을 할 때에 다른 사람의 작업에 영향을 주거나 받지 않도록, 먼저 메인 브랜치에서 자신의 작업 전용 브랜치를 만들어야 하며, 각자 작업을 진행한 후, 작업이 끝난 사람은 메인 브랜치에 자신의 브랜치의 변경 사항을 적용시킨다.
- 저장소를 처음 만들면, Git은 바로 'master' 또는 'main'라는 이름의 브랜치를 만들어 두게 된다. 이 새로운 저장소에 새로운 파일을 추가 한다거나 추가한 파일의 내용을 변경하여 그 내용을 저장(Commit)하는 것은 모두 'master' 또는 'main' 라는 이름의 브랜치를 통해 처리할 수 있는 일이 된다.
브랜치와 관련된 Git Flow 에 대한 자세한 내용을 확인하려면 여기를 클릭해주세요
👍 Git & Github 용어요약
- Git : 프로젝트 파일의 변경 사항을 추적하는 분산 버전 관리 시스템
- Github : Git을 사용하는 프로젝트를 위한 호스팅 서비스, 버전관리를 한 프로젝트들을 모아놓은 저장소
- 로컬(local) : 내 컴퓨터 환경을 말한다
- 원격 저장소 : 외부(일반적으로 원격 서버) 버전의 프로젝트 저장소, 즉 Github의 원격 저장소
👍 Git 명령어 요약
- init : Git 저장소의 프로젝트 버전을 관리를 위한 정보를 생성함
- status : Git 저장소의 현재 상태를 확인함
- add : Git 프로젝트(파일)의 수정 이력을 기록할 준비
- commit : Git 프로젝트의 수정 이력을 넣을 메세지
- log : 프로젝트의 기록 이력을 확인함
- push : 작성한 코드(프로젝트)를 저장소에 업로드(저장)함
