백업해둔 프로젝트를 내 컴퓨터로 받아오거나 협업을 위해 새로운 개발자가 프로젝트를 로컬 저장소로 받아와야하는 경우가 있다. 이때 clone을 통해 로컬 저장소에 원격 저장소에 있는 프로젝트를 가져올 수 있다.


STEP01.

GitHub에 있는 가져올 원격 저장소에 접근하여 HTTPS 값을 복사한다.


STEP02.

SourceTree에서 왼쪽 하단의 "Add Repository"버튼을 누른다.


STEP03.

"Clone Repository"탭에서 "Source Path/URL"에 복사해둔 HTTPS값을 붙여넣고 "Destination Path"에 받아온 프로젝트를 저장해둘 경로를 지정해준다. 마지막으로 "Bookmarks"에 SourceTree에 표시할 저장소의 이름을 지정해주고 "Clone"버튼을 누른다.


STEP04.

아래와 같이 SourceTree에 원격 저장소에 존재하던 프로젝트가 생성되었으며 지정해둔 프로젝트 생성 경로에 해당하는 프로젝트 파일이 생성되었다.

<BranchMerge Git 저장소가 생성>


<설정한 경로에 GitHub의 원격 저장소에 존재하던 프로젝트가 저장됨>


Posted by gangju
,

GitHub에 로컬 저장소의 프로젝트를 최초로 동기화한 이후 로컬 저장소 프로젝트에 변경 사항이 발생하여 수정을 하였다. 이 경우 다시 push를 통해 로컬 저장소와 원격 저장소를 동기화 해주어야 한다.


STEP01.

프로젝트의 소스코드를 수정하고 commit과정을 거친다.

<printMessage 메소드 추가>


<commit을 통해 새로운 버전 생성>


위의 그림과 같이 새로운 버전이 생성이 되었다. 여기서 버전 목록을 보게 되면 최신 버전이 master 브랜치로 되어있고 그 바로 밑의 버전에 origin의 master 브랜치로 표시 되어있다. 이것은 아직 로컬 저장소와 원격 저장소를 동기화 하지않아 두 개의 저장소 사이에 하나의 버전이 차이난다는 것을 보여주는 것이다. 또한 상단의 "Push"버튼에 1이라는 숫자가 보이는데 이것 또한 로컬 저장소와 원격 저장소가 하나의 버전이 차이난다는 것을 보여주는 것이다.


STEP02.

마찬가지로 로컬 저장소와 원격 저장소를 동기화하기 위해 SourceTree의 상단에 있는 "Push"버튼을 누르고 아래의 화면에서 push할 브랜치를 선택하고 "OK"버튼을 누른다.


STEP03.

push과정이 끝나면 두 개의 저장소가 동기화되어 아래와 같이 master 브랜치와 origin/master 브랜치가 같은 버전으로 존재하게 된다. 또한 GitHub 사이트에 접속하여 원격 저장소를 확인해보면 소스코드가 동기화되어 있다.

<master 브랜치와 origin/master 브랜치가 똑같은 버전으로 되어있다.>


<업데이트된 원격 저장소>

Posted by gangju
,

앞서 GitHub를 통해 생성한 원격 저장소를 내 컴퓨터에 존재하는 로컬 저장소와 연결을 하였다. 이렇게 연결한 원격 저장소에 내 컴퓨터에서 작업하던 프로젝트를 백업 또는 협업하기 위해 프로젝트를 동기화할 수 있다. 이것을 push라 한다.


STEP01.

SourceTree에서 해당하는 로컬 저장소를 선택한 뒤 상단 메뉴의 "Push"버튼을 누른다.


STEP02.

상단의 선택 메뉴에서 프로젝트를 올리고자 하는 원격 리포지토리를 선택하고 (origin 또는 또 다른 원격 저장소) 다음으로 올리고자 하는 branch를 선택한다. 마지막으로 "OK"버튼을 누른다.


STEP03.

Username과 Password를 입력하라는 창이 나오면 자신의 GitHub 계정을 입력하면 된다.


STEP04.

push가 완료되면 아래 그림과 같이 원격 저장소 origin에 push과정에서 선택한 master 브랜치가 등록 되어있다. 또한 GitHub 사이트에 접속하여 해당 원격 저장소를 확인해보면 로컬 저장소의 프로젝트가 동기화되어 있다.

<원격 저장소 origin에 등록된 master 브랜치>


<GitHub의 원격 저장소에 동기화된 프로젝트>


Posted by gangju
,

프로젝트를 다른사람과 협업하기 위해, 또는 자신의 프로젝트를 안전하게 유지하기 위해 자신의 컴퓨터가 아닌 다른 곳에 저장을 해두어야 한다. 이러한 기능을 GitHub에서 제공하는 저장소를 사용할 수 있는데 이러한 자기 자신의 컴퓨터에 있는 로컬 저장소가 아닌 외부에 있는 저장소를 원격 저장소라고 한다. GitHub에 원격 저장소를 생성하고 자신의 컴퓨터에 있는 로컬 저장소와 연결하는 방법은 아래와 같다.


STEP01.

GitHub(https://github.com)에 접속하여 회원가입을 하고 로그인을 한다.


STEP02.

화면 우측에 있는 "New repository" 버튼을 누른다.


STEP03.

"Repository name"란에 저장소의 이름을 쓰고 하단의 "Create repository" 버튼을 누른다.

※ new repository의 옵션

- Description : 생성하는 저장소에 대한 설명

- Public or Private : 해당 저장소가 공개 저장소인지 비공개 저장소인지 설정. GitHub의 경우 비공개 저장소일 경우 유료이다.

- Initialize this repository with a README : 생성하는 저장소가 신규 저장소일 경우 저장소를 초기화하고 프로젝트에 대한 설명을 입력하기 위한 README.md 파일을 생성. 기존 저장소를 복제하기 위한 경우 체크하지 않아도 된다.

- Add .gitignore : Git에서 관리하지 않을 파일의 목록을 관리하는 .gitignore 파일을 작성한다.

- Add a license : 작성하는 코드의 라이센스를 관리하는 LICENSE 파일을 작성한다.


STEP04.

생성된 저장소에 자신의 컴퓨터에 저장되어 있는 저장소를 복사하기 위해 상단의 "HTTPS" 항목의 주소 값을 복사한다.

※ 아래 "or create a new repository on the command line" 이하의 항목은 SourceTree와 같은 그래픽 유저 인터페이스 기반이 아닌 텍스트 기반 인터페이스에서 원격 저장소를 추가하기 위해 사용된다.


STEP05.

SourceTree 상단 메뉴의 "Repository-Add Remote" 를 누른다.


STEP06.

"Add Remote"에 들어가게 되면 아래의 그림과 같이 해당 로컬 저장소의 원격 저장소를 관리하는 창이 나온다. 이 곳에서 "Add" 버튼을 눌러 준다.


STEP07.

앞서 복사해두었던 GitHub의 원격 저장소 "HTTPS" 항목의 값을 "URL / Path"란에 적어준다. 또한 원격 저장소가 로컬 저장소의 첫번째 원격 저장소일 경우 "Default remote"를 체크하여 기본 원격 저장소(origin)로 지정해준다. 마지막으로 "OK" 버튼을 누른다.

STEP08.

아래와 같이 원격 저장소 목록에 금방 연결한 "origin"이 생성되었다. "OK" 버튼을 누른다.


STEP09.

SourceTree의 메인화면 Remotes 항목에 원격 저장소 origin이 표시된다.

<로컬 저장소에 추가된 GitHub의 원격 저장소>

Posted by gangju
,

앞에서 배운 branch를 통해 하나의 프로젝트에 두 가지의 다른 작업을 동시에 진행하며 Git에서 버전관리를 받는 것을 배웠다. 이번에는 앞서 예를 들었던 두 가지의 작업이 시간이 지나 모두 완성되었다고 한다. 그렇다면 이 두 개의 작업을 하나의 버전으로 만들어 서비스를 제공해야 할 것이다. 이 때 진행되던 이 두개의 작업를 하나로 합치는 것을 merge라고 한다.



<master branch의 상태>



<실험 branch의 상태>


STEP01.

합칠 branch를 checkout 한다. (다른 branch를 가져와서 원본으로 만들 branch)

※ checkout : branch를 선택하는 것. checkout 하는 branch에 따라 소스코드가 바뀐다.


STEP02.

가져올 branch를 마우스 오른쪽 클릭을 하고 "Merge 실험 into current branch"를 누른다.


STEP03.

Confirm Merge 팝업이 뜨면 "OK"를 누른다.


STEP04.

두 개의 branch를 합치는 commit이 자동으로 실행되어 하나의 버전이 생성되었다. 또한 merge를 통해 가져온 branch는 해당 branch를 마우스 오른쪽 클릭을 하고 delete "branch 명"을 이용하여 삭제 가능하다.



<merge를 통해 두 개의 branch가 자동으로 합쳐진 소스 코드 결과>


※ Merge 과정에서의 충돌(Conflict) 문제

만약 master branch와 실험 branch의 코드를 수정하여 아래와 같은 상태에 있다고 하자.

<master branch의 상태>


<실험 branch의 상태>


여기서 master branch에 실험 branch를 merge할 경우 아래와 같이 "Merge Conflicts" 메세지가 발생하게 되고 merge의 결과가 master branch의 버전 목록에 "Uncommitted changes"로 아직 commit 되지 않은 상태로 존재하게 된다.

<Merge Conflicts 메세지>


<master branch의 버전목록>


이러한 메세지의 발생 원인은 두 개의 branch의 소스코드들을 각각 수정할 때, 동일한 위치의 코드를 추가하거나 수정하였기 때문에 Git을 통한 merge 과정에서 충돌을 일으키기 때문이다. 위의 소스의 경우 두 개의 branch가 동일한 위치에 있는 4번째 줄의 System.out.println()의 내용을 수정하였기 때문에merge 과정에서 어떤 코드를 삽입해야 하는지 처리하지 못해 충돌이 발생하였다.


충돌이 발생한 후 master branch의 소스코드는 아래와 같이 두개의 branch 내용을 모두 포함하면서 사용자에게 코드의 수정을 요구한다.

<Merge  Conflict가 발생한 소스코드>


이러한 충돌의 해결 방법은


STEP01.

위와 같이 merge의 결과로 나온 소스코드를 사용자의 필요에 맞게 수정한 다음 (위의 코드는 두 개의 System.out.println() 내용이 필요하다는 가정하에 아래와 같이 수정하였다.)

<수정한 소스코드>


STEP02.

SourceTree에서 working copy의 conflict 항목에 마우스 오른쪽 클릭을 하고 아래 그림과 같이 Mark Resolved를 누른다. Mark Resolved는 confilct를 해결 했다는 것을 Git에게 알려주는 것으로 Mark Resolved를 해주지 않을 경우 위 상태에서 commit이 되지 않는다.


※ Mark Resolved 이외의 옵션

- Mark Unresolved : Mark Resolved한 것을 다시 이전의 상태로 되돌린다.

- Resovle Using 'Mine' : 자동으로 가져오는 branch의 내용을 삭제하고 현재 checkout한 branch의 내용을 merge에  사용한다.

- Resovle Using 'Theirs' : 자동으로 현재 checkout한 branch의 내용을 삭제하고 가져오는 branch의 내용을 merge에 사용한다.



STEP03.

그 결과 아래와 같이 느낌표 모양의 conflict 표시가 사라지고 index영역에 새로운 내용이 올라온다.


STEP04.

마지막으로 이 부분을 commit을 해주게 되면 자동으로 commit Message가 생성이되고 이것을 commit 해주면 conflict가 발생한 merge가  마무리 된다.

<자동 생성된 commit Message>


<conflict를 해결한 master branch>

Posted by gangju
,

만약 프로젝트에 새로운 기능을 추가하고자 한다. 동시에 기존의 프로젝트에서 발생하는 버그와같은 수정사항을 고쳐야 하는 상황이다. 그렇다면 다른 방향의 두 가지의 작업을 함께 진행 하여야하는데 만약 새로운 기능을 추가하는 작업이 취소되거나 수정되어 기능을 추가하기 전의 상태로 돌아가야하는 상황이 발생할 수 있다. 하지만 이 때 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 같은 이전상태로 되돌리는 작업이 가능하고 또한 지금까지 해왔던 작업을 취소할 수 있게 된다.

Posted by gangju
,

앞에서 배운 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하여야 한다.

Posted by gangju
,

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


<소스코드 수정 전>


<소스코드 수정 후>


STEP01.

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


STEP02.

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



STEP03.

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


<결과>

Posted by gangju
,

프로젝트를 진행하다보면 하나의 기능을 완성하거나 더 이상 수정을 할 필요가 없다고 생각할 때 완성된 기존의 소스를 다른 곳에 백업을 해둔다. 이것을 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이 되지 않는다.

Posted by gangju
,

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


STEP01.

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


STEP02.

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


STEP03.

실제 생성된 리포지토리



'Git&GitHub' 카테고리의 다른 글

SourceTree를 활용한 commit 전 수정사항 취소하기(discard)  (0) 2015.11.16
SourceTree를 활용한 버전 만들기(commit)  (0) 2015.11.15
Git/SourceTree 설치  (0) 2015.11.12
Git 용어 설명  (0) 2015.11.12
Git/GitHub 개념  (0) 2015.11.05
Posted by gangju
,