깃 & 소스트리는 파일 버전 관리를 목적으로 사용합니다.
| 구분 | 내용 | 사이트 |
| 깃(Git) | 파일의 버전 관리를 위한 시스템 | https://git-scm.com/ |
| 소스트리(SourceTree) | Git 사용을 도와주는 GUI 프로그램 | https://www.sourcetreeapp.com/ |
1. git 설정하기
- 깃을 이용해 만드는 모든 버전에 "만든사람", "지은이"와 같은 개념으로 이름 및 이메일 설정
junmy@DESKTOP-2076K9C MINGW64 /c/git_test
$ git config --global user.name "ojm"
junmy@DESKTOP-2076K9C MINGW64 /c/git_test
$ git config --global user.email junmyung2020@gmail.com
junmy@DESKTOP-2076K9C MINGW64 /c/git_test
$ git config user.name
ojm
junmy@DESKTOP-2076K9C MINGW64 /c/git_test
$ git config user.email
junmyung2020@gmail.com
- 깃의 현재 설정값 확인
junmy@DESKTOP-2076K9C MINGW64 /c/git_test
$ git config --list
2. 소스트리 설치 및 깃허브 회원가입
3. 버전관리
버전이 만들어지는 과정을 이해하려면 깃이 관리하는 Working directory, Stage, Repository를 먼저 이해해야 합니다.
버전을 만든다는 것은 특정 순간의 변경 사항을 기억한다는 말과 같습니다.
- 작업 디렉토리(Working directory)는 프로젝트가 위치할 공간을 의미
- 스테이지(Stage)는 작업 디렉토리 내에서 변경된 파일들 중 새로운 버전이 될 파일을 선별하여 옮기는 공간
- 저장소(Repository)는 스테이지의 파일들을 바탕으로 새 버전이 만들어지고 관리되는 공간
4. 소스트리를 통한 버전 관리
소스트리를 통해 버전 관리할 폴더를 지정하고, txt파일을 생성하면 소스트리의 작업 디렉토리에 변경사항이 호출됩니다. 그러면 해당 변경사항에 대한 설명을 기록하여 커밋하고 스테이지에 올리면, 트리형태의 리스트가 생성됩니다.
(추가로 .gitignore 파일을 생성하여 안에 파일명을 기록하면 해당 파일은 버전 관리에서 무시됩니다.)
서비스를 사용자에게 선보이기까지 수많은 커밋이 쌓여 만들어집니다.
텐서플로는 커밋이 10만개, 리눅스 운영체제는 100만개 이상이 모여 만들어집니다.
개발자로 일하게 되면 모든 프로젝트는 이렇게 수많은 커밋들이 쌓여 완성될 것입니다.
※ 커밋 해시 : 각 커밋에는 고유의 ID가 부여됩니다. 이를 커밋 해시라고 하며, 특정 변경 사항을 지칭할 때도 사용합니다.
5. 버전 비교하기
2번, 4번 커밋을 동시에 클릭하면 파일의 변경사항을 확인할 수 있습니다.
[Revert] 커밋을 되돌리게 되면, 이전 버전과 동일한 내용을 가진 Revert라는 새로운 버전이 만들어집니다.
[Reset] 되돌아갈 버전의 시점으로 완전하게 되돌아가는 방식으로 reset에는 크게 3종류가 있습니다.
- soft : 커밋했다는 사실만 되돌리는 reset을 soft reset이라고 합니다.
- mixed : 스테이지와 커밋을 되돌리는 reset을 mixed reset이라고 합니다.
- hard : 작업 디렉토리 내 변경 사항까지 되돌리는 reset을 hard reset이라고 합니다.
6. 스태시로 작업 임시 저장하기
깃은 스태시라는 임시 저장 기능을 지원합니다. 개발하는 과정에서 썩 마음에 들지 않지만 버리기 아까울 때가 있을텐데, 또는 다른 중요한 일을 처리해야 할 때가 있을 수 있습니다. 이 때 변경 내용을 임시로 저장해두는 것이 좋겠죠?
수정중인 파일을 스태시를 하게되면 작업 디렉토리는 수정되기 전의 상태로 돌아가고, 변경 내용은 임시 저장됩니다. 다만 스태시는 깃이 변경 사항을 추적하는 파일에만 사용할 수 있습니다. 다시 말해, 스테이지에 이미 올라와 있거나 한 번이라도 커밋한 적이 있는 파일에만 사용할 수 있습니다.
7. 브랜치로 나누어 관리하기
브랜치는 영어로 나뭇가지를 의미합니다. 마치 줄기에서 뻗어나오는 나뭇가지와 같이 버전을 여러 흐름으로 나누어 관리하는 방법 입니다. 브랜치를 생성하면 작업환경을 분리할 수 있습니다. 기존 master 브랜치에서 새로 생성한 foo 브랜치로 작업을 진행할 수 있습니다.
브랜치를 변경하려면 변경할 브랜치를 더블클릭하면 됩니다. 그러면 커밋 4, 5번의 변경 내용은 보이지 않게됩니다.
8. 브랜치 병합하기
브랜치를 하나로 통합하는 것을 병합, 영어로 merge라고 합니다. 브랜치를 사용하는 이유는 분업과 업데이트와 같은 이유가 있을텐데, 이를 하나로 통합하여 버전을 관리하려는 목적이 큽니다. 브랜치를 병합하기 위해서는 기존 병합 주체가 될 브랜치로 체크아웃하고 병합시킬 브랜치를 마우스 오른쪽 버튼을 클릭하여 [병합]을 클릭하면 됩니다.
9. 충돌 해결하기
브랜치를 병합하는 과정에서 충돌이 발생하면 충돌을 해결하고 커밋해야 올바르게 병합됩니다.
같은 내용을 다르게 수정한 브랜치 중 어떤 브랜치 내용을 최종적으로 반영할지를 직접 선택하는 것을 충돌을 해결한다고 합니다.
10. 브랜치 재배치하기
브랜치의 재배치는 rebase라고 합니다. 브랜치가 뻗어나온 기준점을 변경하는 것을 브랜치의 재배치, rebase라고 합니다.
우선 재배치하려는 대상의 브랜치로 체크아웃한 후, 재배치 지점에서 마우스 오른쪽 클릭 후 재배치를 클릭합니다.
11. Github
깃허브는 개발자간 협업을 가능하게 하고, 원격 저장소 호스팅 서비스를 제공합니다.
소스트리와 깃허브를 연동하여 안전하게 정보를 주고 받을 수 있도록 SSH 통신을 사용할 수 있고,
로컬 저장소와 원격 저장소를 연동하여, 개발 데이터를 주고받을 수 있습니다.
원격 저장소와의 상호 작용은 크게 4가지인데, 내용은 아래와 같습니다.
- 클론(clone) : 원격 저장소를 복제하기
- 푸시(push) : 원격 저장소를 밀어넣기
- 패치(fetch) : 원격 저장소를 일단 가져만 오기
- 풀(pull) : 원격 저장소를 가져와서 합치기
개발자와 협업을 할 때, 내가 소유하지 않은 저장소에도 push를 할 수 있지만, 일반적으로 그렇게 협업하지는 않습니다.
누구나 push를 하게되면 저장소가 삭제, 추가, 수정되면서 효율적인 협업이 이루어지기 어렵습니다.
그러므로 풀 리퀘스트(pull request) 방식을 주로 사용하는데, 말 그대로 원격 저장소가 내 변경 사항을 풀(pull)하도록 요청하는 방법입니다. 요청을 보내면 저장소의 유저가 요청사항을 검토하고 반영할지 말지를 결정하는 방식입니다.
풀 리퀘스트(pull request)는 다음과 같이 이루어집니다.
- 작업할 원격 저장소를 본인 계정으로 포크하기
- 포크한 저장소를 로컬 저장소로 클론하기
- 브랜치 생성 후, 생성한 브랜치에서 작업하기
- 작업한 브랜치 푸시하기
- 풀 리퀘스트 보내기