untitled

STEP01. Git 다운로드
http://www.git-scm.com/

※ 윈도우용 Git인 git-scm.com에서 다운 받는 Git과 msysGit은 동일한 버전이다. <출처 : http://gtko.tistory.com/m/post/263>

STEP02. 다운로드 받은 Git 설치

1) 컴포넌트 설정

사용자의 필요에 따라 변경하면 된다.

2) 환경 변수 설정

사용하는 Git 환경에 따라 환경 변수의  설정이 바뀐다. "Use  Git from Git Bash only"의 경우 Git에서 제공하는 Git Bash만 사용하는 것으로 윈도우 환경변수에 Git을  등록하지 않는다. "Use Git from the Windows Command  Prompt"는 윈도우 명령 프롬프트에서 Git을 사용하는 것으로 선택  시 윈도우 환경변수에 Git을 등록한다. 마지막으로 "Use Git and optional Unix tools from the Windows Command Prompt"는 명령 프롬프트를 사용하면서 명령 프롬프트 위에서 Git을 사용하면서 유닉스 도구를 사용할 수 있게 설치한다.

3) 개행 코드 설정

개행 코드 방식을 선택하는 화면으로 윈도우 환경에서 사용하기 때문에 첫 번째를 선택한다.

STEP03. Git 기본 설정

설치한 Git에서 Git Bash를 실행한 다음 아래의 명령어를 입력하여 Git에서 이용할 이름과 메일 주소를 설정한다.

git config --global user.name "your_name"

git config --global user.email "your_email@example.com"

위의 정보는 Git의 commit 로그 등에 사용된다. GitHub 리포지토리를 공개하는 경우에도 이 정보가 뜬다.

STEP04. SourceTree 다운로드 및 설치
Git은 기본적으로 콘솔 환경에서 사용된다. 이러한 Git을 GUI 환경에서 쉽게 사용하기 위해 TortoiseGit, Git for Windows, GitEye와 같은 툴이 사용되는데 이중에서 SourceTree를 설치한다.
https://www.sourcetreeapp.com/

* commit

파일 및 폴더의 추가 및 변경 사항을 버전화하여 리포지토리에 기록하는 것

* working directory (workspace, working copy, working tree)

실제 파일들로 이루어져있는 폴더. 수정된 내역들이 나타나는 곳. 파일 준비 등이 이루어지며, 리포지토리에 등록된 파일 변경 내역을 관리.

* index (staging area)

Commit을 하기전의 임시영역. 이곳에 올라온 파일들이 하나의 버전이 된다. 따라서 연관되어있는 수정된 파일과 완료된 파일들에 대해서만 commit을 통해 버전화 할 수 있다. (하나의 버전으로 묶길 원하지 않는 파일이 있을 경우 index로 올리지 않으면 된다.)

* revision

* checkout

리포지토리에서 파일을 받아오는 것

* 버전 관리 시스템 (Version Control System)

소프트웨어의 코드를 추가 또는 변경하는 과정을 모두 기록하여 특정한 시점으로 돌아가거나, 문제가 생긴 파일을 복원하는 등, 소프트웨어 개발 현장에서 사용하는 프로그램(시스템) 이다. CVS(Concurrent Versions System, 동시 버전 관리 시스템), SVN(Subversion), Git 등이 있다.

우리가 보통 프로젝트를 작업 할 때 프로젝트 진행과정에서 발생하는 수정사항이나 백업이 필요한 부분을 저장하기 위해 위와 같이 여러 개의 파일을 폴더 내에 복사하고 파일명을 구분되게 하는 방법을 사용한다. 이것을 버전 관리라 볼 수 있다. 하지만 이러한 방법은 프로젝트가 진행될수록 어떠한 파일이 어떤 부분이 변경된 것이고 왜 복사를 해두었는지 파악하기가 어려워진다. 최악의 경우 실수로 파일을 삭제해버리는 경우도 있다. 이러한 문제를 해결하기 위해 소스코드를 효율적으로 관리하기 위해 만들어진 것이 Git와 같은 버전 관리 시스템이다.

* 로컬 버전 관리 시스템

처음 버전 관리 시스템이 등장했을 때 간단한 데이터베이스에 해당 파일의 변경 사항을 아래와 같이 기록하였다. 유명했던 VCS 도구들 중 현재에도 널리 쓰이는 것으로 RCS라 불리는 시스템이 있다. RCS의 기본적인 동작 방식은 각 리비전들 간의 패치 세트(patch set)라고 하는 데이터의 차이점들을 특별한 형식의 파일에 저장, 특정 시점의 파일 내용을 보고 싶을 때 해당 시점까지의 패치들을 모두 더하여 파일을 만들어내는 것이다.

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

또 다른 문제는 시스템 외부에 있는 개발자들과 함께 작업하는 것이다. 중앙집중식 버전 관리 시스템은 이 문제를 해결하기 위해 개발되었다. CVS, Subversion, Perforce와 같은 시스템들이 여기에 속한다. 서버에 저장소(Repository)를 집중시켜 배치. 하나의 소프트웨어를 개발할 때 하나의 리포지토리만 존재한다. 이 중앙 서버에서 다수의  개발자가 파일들을 가져옴으로써(checkout) 위의 문제를 해결한다. 또한 데이터가 중앙 서버에 집중되므로 관리하기가 매우 단순해진다. 하지만 서버에 접속할 수 없거나 서버가 고장나면 최신 소스 코드를 받아올 수 없는 문제점이 있다.

* 분산 버전 관리 시스템 (Distributed Version Control System)

분산 버전 관리 시스템은 앞서 말한 문제를 해결하기 위해 개발되었다. Git, Mecurial, Bazaar, Darcs 등 분산 버전 관리 시스템에서는 클라이언트가 파일들의 마지막 스냅샷을 가져오는 대신 저장소(repository)를 통째로 복제한다. 따라서 서버에 문제가 생겨도 어느 클라이언트든 복제된 저장소를 다시 서버로 복사하면 서버가 복구된다. 체크아웃(checkout)을 할 때마다 전체 백업이 일어나는 셈이다.

집중형과 달리 여러 개의 저장소(Repository)가 존재한다. 서버에 있는 저장소를 원격 리포지토리라고 하며 개인마다 자신의 PC에 로컬 리포지토리라고 한다. 이로인해 사용자는 서버에 있는 저장소에 접속하지 않아도 개발이 가능하다. 하지만 중앙집중식 버전 관리 시스템에 비해 다소 복잡해진다. 아래의 그림의 Fork(포크)는 GitHub에 있는 특정 리포지토리를 자신의 계정으로 복제하는 것이고, 이렇게 복제된 리포지토리는 원래 리포지토리와 완전히 다른 리포지토리가 된다. 또한 서버(GitHub)와 사용자 만의 push, pull이 아닌 다른 사용자 사이에도 직접 push, pull이 가능하다.

* Git와 GitHub의 차이

Git은 Git 리포지토리라고 불리는 데이터 저장소에 소스 코드 등을 넣어서 이용하는것으로, 이러한 Git 리포지토리를 인터넷상에서 제공하는 서비스(호스팅 서비스)가 GitHub이다. GitHub에서 공개되는 소스 코드는 모두 Git으로 관리된다.

<출처 : https://git-scm.com/book/ko/v1/, https://backlogtool.com/git-guide/kr/, https://opentutorials.org/course/1492>