untitled

만약 프로젝트에 새로운 기능을 추가하고자 한다. 동시에 기존의 프로젝트에서 발생하는 버그와같은 수정사항을 고쳐야 하는 상황이다. 그렇다면 다른 방향의 두 가지의 작업을 함께 진행 하여야하는데 만약 새로운 기능을 추가하는 작업이 취소되거나 수정되어 기능을 추가하기 전의 상태로 돌아가야하는 상황이 발생할 수 있다. 하지만 이 때 Git을 통해 이전의 상황으로 돌아갈 경우 동시에 작업하던 프로젝트의 수정 작업 역시 사라지고 이전 상태로 돌아가는 문제가 발생한다. 이때 Git의 branch 개념이 필요하다.

STEP01.

상단 메뉴의 Branch 버튼을 클릭한다.

STEP02.

새롭게 만들 Branch의 이름을 쓰고 Create Branch 버튼을 누른다.

STEP03.

다음과 같이 하나의 리포지토리에 두 개의 브랜치(master, AddNewMethod)가 생성되었다.

<AddNewMethod 브랜치>

<master 브랜치>

STEP04.

먼저 SourceTree에서 AddNewMethod 브랜치를 선택한 후 프로젝트의 코드를 수정하고 commit을 해본다.

<AddNewMethod 브랜치 선택 후 subXY 메소드 추가>

<AddNewMethod 브랜치에 새로운 버전(subXY) 생성>

STEP05.

다음으로 master 브랜치를 선택한 후 프로젝트의 코드를 수정하고 commit을 해본다. 여기서 master 브랜치를 선택할 경우 아래와 같이 AddNewMethod 브랜치에 commit한 수정사항이 사라진다.

<master 브랜치 선택 후 사라진 subXY 메소드>

<master 브랜치 선택 후 mulXY 메소드 추가>

<master 브랜치에 새로운 버전(mulXY) 생성>

STEP06.

아래와 같이 2개의 다른 브랜치에 각각의 버전이 생성되었다.

<master 브랜치>

<AddNewMethod 브랜치>

이렇게 새로운 branch를 생성하게 되고 프로젝트의 새로운 기능 추가는 새로운 branch에서, 기존 프로젝트의 버그 수정은 기존 master branch에서 작업해줌으로써 두 개의 작업이 동시에 수행가능하다. 이로인해 만약에 상황 발생 시, 두 작업이 서로 영향을 받지 않으면서 revert 나 reset 같은 이전상태로 되돌리는 작업이 가능하고 또한 지금까지 해왔던 작업을 취소할 수 있게 된다.

앞에서 배운 reset과 마찬가지로 이전의 버전으로 돌아가기 위해 revert를 사용할 수 있다.

STEP01.

취소할 버전을 선택하고 해당 버전에 마우스 오른쪽 클릭을 한다. 팝업이 뜨면 "Reverse commit"을 누른다.

STEP02.

Confirm reverse commit 팝업이 뜨면 Yes를 누른다.

STEP03.

다음과 같이 revert로 선택한 "Circle클래스 수정"을 취소하는 버전인 "Revert "Circle클래스 수정"이 commit 되었다. 소스코드 역시 "Circle클래스 수정" 버전을 실행하기 전인 "mainCode 수정 Circle 선언" 버전으로 돌아간다.

※ reset과 revert의 차이점

reset은 선택한 버전을 reset할 경우 선택한 버전의 이후 버전을 모두 삭제하고 선택한 버전의 상태로 되돌아간다.

revert는 선택한 버전을 revert할 경우 선택한 버전의 바로 전 버전으로 돌아가는 새로운 commit을 자동으로 실행한다.

※ 여러 버전을 건너뛰어 Revert하게 되면 충돌이 발생한다. 예를 들어, 위 예제에서 "Circle클래스 추가" 버전으로 돌아가고 싶을 경우 최근 버전인 "Circle클래스 수정" 버전부터 차례로 revert하여야 한다.

프로젝트가 진행되던 도중 문제가 발생하여 이전의 버전으로 돌아가야 하는 상황이 발생한다. 이때 돌아가길 원하는 버전으로 reset을 통해 되돌릴 수 있다.

STEP01.

되돌아갈 버전을 선택하고 마우스 오른쪽 버튼을 클릭하고 "Reset current branch  to this commit"을 누른다.

STEP02.

Reset to Commit 창이 아래와 같이 뜬다. 여기서 3가지의 mode가 존재하는데 Soft, Mixed 그리고 Hard는 다음을 의미한다. 원하는 mode를 선택 후 OK를 클릭한다.

1) Soft : index에 올라온 수정사항 보존, working tree에 올라온 수정사항 보존

2) Mixed : index에 올라온 수정사항 취소, working tree에 올라온 수정사항 보존

3) Hard : index에 올라온 수정사항 취소, working tree에 올라온 수정사항 보존

STEP3-1.

Hard mode를 선택할 경우, Reset한 버전이후의 버전이 모두 삭제되며 소스코드 역시 해당 버전의 소스코드로 수정되어있다.

STEP3-2.

Mixed mode를 선택할 경우, Reset한 버전이후의 버전이 모두 삭제되었으나 working tree의 소스코드는 유지되어 Uncommitted changes 항목이 표시되어있다. 또한 소스코드 역시 그대로 유지되어 있다.

만약 소스코드를 수정을 하고 commit을 하기 직전의 상황에서 수정한 내용에 문제점이 발견되고 수정한 부분을 되돌리려고 한다. 직접 이 부분을 사람이 되돌리고자 하면 하나하나 원 상태와 똑같이 지우고 수정해가며 이전의 상태로 되돌릴 수 있다. 이 때 Git의 discard를 통해 자동으로 수정하기 전의 commit한 버전으로 돌아갈 수 있다.

<소스코드 수정 전>

<소스코드 수정 후>

STEP01.

위와 같이 소스코드가 수정되면 SourceTree의 working tree에 아래와 같이 표시가 된다. 이 상태에서 commit을 하기 전 소스코드에 문제가 발생하여 수정하기 전으로 소스코드를 되돌리고 싶다면 SourceTree의 상단 메뉴에서 Discard 버튼을 클릭한다.

STEP02.

Discard Changes 창이 뜨면 되돌리고 싶은 파일을 선택 후 하단의 Discard Changes 버튼을 클릭해준다. Confirm Discard 팝업창이 뜨면 OK를 클릭한다.

STEP03.

Discard 완료 후 "Uncommitted changes"가 사라졌으며 작성하던 소스코드를 확인해보면 수정하기 전의 코드로 돌아가있는 것을 확인할 수 있다.

<결과>

프로젝트를 진행하다보면 하나의 기능을 완성하거나 더 이상 수정을 할 필요가 없다고 생각할 때 완성된 기존의 소스를 다른 곳에 백업을 해둔다. 이것을 Git에서는 commit이라 한다.

STEP01.

SourceTree를 통해 생성한 Git 리포지토리(자신의 프로젝트 폴더)에 소스 파일을 작성하고 생성한다.

STEP02.

소스 파일을 저장한 후 SourceTree를 확인해보면 다음과 같이 새롭게 생성하거나 수정한 파일들이 SourceTree의 Unstaged files 목록(working copy)에 표시된다. 이 목록에서 commit 하고자하는 파일을 check 한다. (add)

(Unstaged files 목록에 있는 파일들 앞에 보면 아이콘이 표시된다. 파란색 물음표 아이콘의 경우 Git에 최초 commit이 되지않은, Git이 현재 관리하지 않고 있는 파일을 의미하며, 주황색 "..." 아이콘의 경우 최초 commit을 이미 하였으며 Git에 의해 버전관리를 받고 있는 파일을 의미한다.)

STEP03.

Unstaged files 목록에서 check를 하게되면 check된 파일들이 상단의 Staged files(index)로 이동하게 된다. 이것은 commit 하기 전의 임시영역(index)에 해당 파일들이 commit 될 준비가 되었음을 나타낸다. 그런 다음 SourceTree 상단의 Commit 버튼을 클릭해준다.

STEP04.

끝으로 commit을 하기 위해 commit 할 파일의 변경 사항과 같은 정보를 commit 메시지를 통해 기록한다. 기록이 완료되었으면 하단의 Commit 버튼을클릭한다.

STEP05.

다음과 같이 파일의 버전이 생성된다.

※ 파일을 하나씩 클릭해보면 실제 파일에 기록된 코드나 정보를 확인할 수 있는데 초록색 영역은 추가되거나 수정된 부분을 의미하며 빨간색 영역은 예전 버전에서 삭제된 부분을 의미한다.

※ index에 파일이 올라간 후 다시 그 파일을 수정할 경우 index에 위치한 버전과 또 다른 버전이 Unstaged files 목록에 표시된다.

※ Unstaged files 목록에 있는 항목중 commit을 원하지 않는 항목(하나의 버전으로 묶이는걸 원하지 않는 파일)은 check를 해제하면 Staged files 목록으로 이동하지 않으며 commit 버튼을 눌러도 commit이 되지 않는다.

Git을 통해 버전관리를 받기 위해 작업하는 프로젝트 폴더를 Git의 Repository로 지정해주어야 한다. 이것을 init이라 하며 SourceTree에서는 아래와 같은 과정을 거친다.

STEP01.

SourceTree를 실행 후 왼쪽 하단의 Add Repository 아이콘을 클릭한다.

STEP02.

새롭게 뜨는 팝업 창에서 Create New Repository 탭을 클릭 후 자신이 사용할 프로젝트 디렉토리(JAVA 프로젝트 디렉토리 같이 실제 소스 코드들이 저장되는 디렉토리)를 지정해 준다. Create 버튼을 통해 생성한다.

STEP03.

실제 생성된 리포지토리

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>