이론공부/관련서적

Git 소스트리 (GUI) 사용법 - 자세한 기초 사용법 가이드

chobyeonggyu03 2024. 7. 15. 16:48
반응형

이번 글에서는 현업 네이버 개발자분이 사용하고 계셨던 Git 사용방법인 Git source tree 사용법에 대해 정리해보고자 한다.
 

Git source tree 다운로드

먼저 Git source tree를 사용하기 위해 아래 링크를 통해 source tree를 다운받아보도록 하겠다.
 
https://www.sourcetreeapp.com/

 

Sourcetree | Free Git GUI for Mac and Windows

A Git GUI that offers a visual representation of your repositories. Sourcetree is a free Git client for Windows and Mac.

www.sourcetreeapp.com

 
해당 링크로 들어가서 
 

파란 버튼을 눌러 설치파일을 다운받아 준 다음, exe설치파일을 열어 기본세팅으로 '다음' 버튼을 난사하여 다운 받아주면 된다. 
 
surce tree를 성공적으로 다운받았다면, 기본적인 사용법에 대해 알아보도록 하자.
 
 

source tree 사용법

 

1. 로컬 저장소 생성하기 (원격 저장소는 뒤에서 다룸)

 

 

1) 오른쪽 상단의 create 버튼을 눌러준다.

 
 

 
 

2) local로 선택하여 레포지토리를 만드는 경우엔 컴퓨터나 노트북 내부의 어디에 저장소를 만들지 경로를 지정해주면 된다.

 

 

 
 
 

3) 생성버튼을 눌러 저장소를 만들어주기

 
 

 
 

4) 혹시 모르니 해당 경로로 들어가서 .git파일이 제대로 생성됐는지 확인해주기

 
 
(작업 디렉토리란 테스트하거나 사소한 수정을 하는 경우와 같이 모든 수정 사항이 새로운 버전이 될 필요는 없기에 새로운 버전에 포함시킬 파일들을 선별하는 과정전에 이 후보군들을 저장하는 곳이다.(따로 commit하지 않고 수정하면 저장되는 장소) + 작업디렉토리에서 수정하거나 파일에 대해 변경사항이 있으면 스테이지라는 공간에서 새로운 버전으로 업로드할 파일들을 선별하여 최종적으로 저장소에 새로운 버전을 저장하는 역할하고,작업디렉토리와 스테이지를 거쳐 저장소에 새로운 버전을 만드는 것을 'commit한다'라고 한다.) 
 
작업 디렉토리를 만들었다면 이제 간단한 예제를 통해 실제 GitHub 저장소로 commit 해보도록 하자.
 
 
 
 

2. commit 하기

 
 

1) commit할 파일 작성하거나 수정하기

 
 
현재 새로 만든 작업 디렉토리에 아무런 파일이 없기에 해당 파일에 간단히 commit할 텍스트파일들을 생성해보도록 하자.
 
 

 
 
각각 다른 내용으로 아무말이나 작성해주었다. 
 
 

 
 
 
그러면 위와 같이 스테이지에 올라가지 않은 파일 목록에 해당 파일들이 뜨는 것을 확인할 수 있다.
 
 
 

 

 

2) commit할 파일 스테이지에 올리기

 
여기서 드래그를 통해 특정 파일만을 올리거나 '모두 스테이지에 올리기' 버튼을 눌러 스테이지에 해당 파일들을 올려보자.
그러면 오른쪽에 해당 파일들을 클릭했을 때 변경사항들이 초록색으로 표시되는 것을 알 수 있다.
 
(지금은 전에 커밋한 내용이 없기에 모든 내용들이 초록색으로 뜨는 걸 알 수 있다.)
 
 
 

 
 

 

3) 아래에 커밋내용을 입력해준뒤 커밋 버튼 누르기

 
그 다음 아래에 간단히 커밋 내용을 입력해준 다음 커밋 버튼을 누르면 아래 사진들처럼 첫번쨰 커밋 버전이 만들어지고 더이상 이전 커밋과 달라진게 없기에 '파일상태'버튼을 누르면 커밋할 내용이 없다고 뜨게 된다.
 
 
 

 
 
 
커밋한 이후에 c.txt파일의 기존 내용을 지우고 새로 작성하게 되면 아래와 같이 삭제한 내용은 빨간 배경으로. 추가되거나 변경된 내용은 초록색배경으로 표시되는 걸 알 수 있고 위와 같은 방법을 커밋 메세지와 커밋을 해주면 오른쪽 사진처럼 커밋이 쌓이는 것을 알 수 있다.

 
 

 
 
 

3. 작업 되돌리기

 

1) 스테이지에 이미 올린 파일을 되돌리고 싶을 때는 드래그를 통해 아래로 내리거나, '모두 스테이지에서 내리기' , '선택 내용 스테이지에서 내리기' 버튼을 활용해 스테이지에서 아래와 같이 내려준다.

 
 

 
 
 
 

2) 해당 파일의 작업상태를 되돌리고 싶을 때는 우클릭하여 '파일 변경사항 폐기' 버튼 눌러주기

 
 
 

 
 
 
 
폐기하는걸 확인하는 안내창에서 확인 버튼을 누르면 아래와 같이 해당 커밋 내용이 목록에서 사라지고, 텍스트 파일도 해당 내용이 사라져 있는 걸 볼 수 있다.
 
(커밋내용이 하나뿐이라 전체가 사라진것처럼 보이는 거예요)
 
 
 
 

 
 
 

 

3) 이미 커밋한 작업 내용을 되돌리고 싶을 때는 revert 또는 reset을 활용하기

 
(revert는 버전을  되돌리고 되돌린 상태의 새로운 커밋 버전이 만들어지는 방식이고, reset은 해당 시점이후의 커밋까지 삭제해서 해당 상태로 완전히 되돌리는 방식이다. 즉 돌아가고 싶은 커밋이후의 작업도 살리고 싶은 부분이 있을 때는 revert, 해당 시점이후의 작업에서 살리고 싶은 부분이 없다면 reset을 활용하는 것이 좋다.)
 
 

- revert 방법

 
 
1) 되돌리고 싶은 커밋상태에서 우클릭하여 '커밋 되돌리기' 버튼 클릭
 

 
 
커밋 되돌리기 버튼을 클릭하게 되면 아래와 같이 revert는 새로운 커밋에 되돌린 버전을 만들어 주는 것을 확인할 수 있다.
 
 
 
 

 
 

 

-  reset 방법

 
 
reset방법에는 작업 디렉토리의 작업 상태와 커밋상태를 모두 되돌리는 hard reset과 작업 디렉토리의 작업상태와 수정된 스테이지 상태는 그대로 두면서 커밋했다는 기록만 되돌리는 soft reset, 작업 디렉토리의 작업상태를 그대로 두고 스테이지와 커밋상태를 되돌리는 mixed reset이 있다.
 

(hard reset을 하는 것은 원격 디렉토리와 상관이 없기에 리셋후 다시 커밋하여 원격 저장소에 push해줘야 로컬 저장소와 동일해짐)
 
 
 

1) 아래와 같이 커밋상태에서 우클릭을 눌러 '이 커밋까지 브랜치를 초기화' 버튼을 눌러준다.

 
 
 

 
 
 
 
그러면 아래와 같이 sotf, mixed, hard 중 어떤 reset을 할건지 선택하는 창이 뜨고 원하는 reset버튼을 눌러주면 된다. 글쓴이는 hard reset을 테스트해보고 싶어 hard reset을 해보았다. 
 
 
 

 
 
 
 
실수로 3번쨰 커밋을 선택하고 되돌려야 하는걸 2번쨰 커밋을 선택하고 되돌려서 아래는 2번째까지 hard reset을 하고 다시 3번쨰까지 hard reset을 한 화면인데 텍스트 파일까지 완전하게 되돌아간 모습이다.
 
 
 

 
 
 
 

4. 스태시에 임시저장하기

 
 
 
작업 도중 마음에 들진 않지만 버리기는 아까울 때나 작업도중 더 중요한 작업을 하게 되었을 때 작업디렉토리에서 생성한 모든 변경사항을 스태시를 통해 아래와같이 임시저장을 해보자 (이미 커밋한 내용은 스태시에 포함안됨)
 
 

 

1) 상단의 스태시 버튼 클릭

 
 

 
 
 

2) 스테이지에 있는 변겨사항 유지버튼 해제 후 확인버튼누르기

 
스태시에 버튼을 누르고 임시저장을 완료하게 되면 작업디렉토리가 깔끔하게 비워지는 것을 아래 화면을 통해 알 수 있다.
 
 
 

 
 
 
왼쪽 목록에서 스태시를 눌렀을 때 아까추가해두었던 내용이 그대로 저장되어있고, 실제 파일은 해당 변경사항 전으로 되돌아 가 있는 것을 확인해볼 수 있다.
 
 
 
 

 
 
 
 
 

5. 브랜치 관리하기

 
현업에선 작업할 때 해당 작업이 새로운 기능을 개발하기 위한 것인지 기존 기능이나 디자인을 수정하기 위한 것인지 구분하기 위해 브랜치를 'feature/<새기능>' 또는 'hotfix/<수정 사항>' 과 같은 식으로 브랜치를 나눠 작업한 이후 병합하는 형태가 많기에 이를 비롯한 전반적인 브랜치 관리하는 방법에 대해 정리 해보고자 한다.
 
 

- 새로운 작업 브랜치 생성

 


1) 상단 메뉴에서 브랜치 버튼을 클릭

 
 

 

 

2) 새 브랜치명을 작성하고 새 브랜치 체크아웃하여 생성하기

 
아래 화면과 같이 체크아웃하여 새로운 브랜치를 생성하게 되면 해당 브랜치명 왼쪽으로 작업환경을 나타내는 동그라미 표시가 이동하는 것을 볼 수 있다. 
 
(체크아웃이란 해당 브랜치로 작업 환경을 바꾸겠다는 것을 의미 (여기선 master -> 새로만든 브랜치)
 
 
 

 
 
 
 
해당 브랜치로 새롭게 커밋을 해보도록 하겠다.
 
 

 
 
 
위의 오른쪽 사진에 브랜치명이 다르게 뜨는 것을 알 수 있고, 계속 해서 바뀐 브랜치명으로 커밋할 떄마다 같은 브랜치의 커밋들중 최상단에 해당 브랜치명을 표시해주는 것을 알 수 있다.
 
 

- 작업 브랜치 병합하기 (merge)

 

1) 병합하고 싶은 메인 브랜치로 더블클릭하여 체크아웃 브랜지 바꿔주기

 
글쓴이는 master에 병합해보기로 함
 

 

 

 

2) 다른 브랜치들을 우클릭하여 '현재 브랜치로 병합' 버튼 눌러주기

 
 
 

 
 
 
아래는 병합후 변경된 브랜치 화면이다.
 
 
 

 
 
 

 

3) 병합완료된 브랜치 삭제하기 (선택사항)

 
 
 

 
 
 
아래는 제대로 병합되어 새로 추가했던 브랜치에 커밋했던 내용이 해당 브랜치가 삭제되었는데도 제대로 반영된 모습이다.
 
 

 
 
+@)

상단 메뉴의 브랜치버튼에서도 삭제할 수 있음

 
 
 
 

4) 병합시 충돌해결

 
위처럼 서로 겹치는 내용에 대해 수정하지 않았다면 순조롭게 병합할 수 있었을 것이다. 하지만 같은 부분에 대해 다르게 수정했을 결우 충돌이 발생한다면 깃은 이를 해결하지 못하고 충돌이 발생햇다는 사실을 알리며 병합을 중단할 것이다.
 
아래에서 임의로 충돌을 발생시켜 어떻게 대응해야하는지 살펴보도록 하자. (충돌 시키는 예제만드는 과정은 생략)
 
 
 

 
 
 
위의 화면은 master로 부터 test1과 test2 브랜치를 파생시켜 각각 a.txt의 파일 내용중 같은 부분을 수정하여 커밋한 상태이다. 그럼 이제 master브랜치로 merge를 시켜보도록 하겠다.
 
 
 
 

 
 
 
 
 
 
 

 
 
 
위의 화면처럼 test1까지는 병합이 잘 되었지만 test2와 병합하는 과정에서 충돌이 발생했다는 알림창과함께 밑에 충돌된 파일 2개를 띄워주고 있다.

 
 
충돌된 파일을 실행시켜보니 위와같이 구분지어준 모습이다. 참고록 위 화면에서 '충돌시켜보라네?' 는 test1에 입력햇던 내용이고, '이거 진짜 충돌되냐? 앙? \n test2로 커밋하나 더해봄~'은 test2에 입력했던 내용이고 현재 파일의 내용은 <<<<HEAD와 ======로 표시해주고 병합하려는 파일은 =========와 >>>>>>>>>(병합하려던 브랜치명) 으로 나타내주고 있다.
 
 
이 표시는 둘중 하나를 선택해달라는 표시인데 글쓴이는 후자를 살려보도록 하겠다.
 
 
 

 
 
 
위의 선택화면처럼 충돌화면을 우클릭 후 '충돌 해결' 버튼을 클릭후 '내것'과 '저장소'중에 선택하여 해결버튼을 눌러주면 된다 여기서 내것은 현재 체크아웃된 브랜치인 master이고, 저장소는 추가로 병합하려고 선택한 test2 브랜치이다.
 
 

 
 
 
저장소로 병합 버튼을 누르니 새로운 커밋에 test2의 텍스트로 바뀐 것이 새로 커밋된 모습이다.
 
 
 
(+rebase를 활용해 브랜치가 뻗어나온 기준점을 변경하는 것인데 이건 나중에 필요할 때 추가로 다뤄보도록 하겠다.)
 
 
 
 

6. GitBub 연동하기 

 
(해당 파트는 사진을 첨부하며 작성하던 도중 화면이 멈춰 리셋되는 바람에 처음부터 다시 작성하게 되어 간략하게 정리된 느낌이 있더라도 양해부탁드립니다 ㅜ)
 
 
먼저 GItHub는 SSH통신을 지원해주는데, 이는 보안성 연결신뢰성, 접근제어성등이 우수하여 개발자들이 선호하는 원격 저장소로써 Github에 연동할 때 자주 쓰이기에, GitHub에 연동하기 위해서는 SSH 통신에 대해 어느정도의 이해는 필요하다고 생각되어 SSH에 대해 간단히 설명해보도록 하겠다.
 
SSH 통신이란, 암호화된 네트워크 프로토콜을 사용하여 두 컴퓨터 간의 안전한 채널을 생성하고 이 네트워크를 통해 다른 컴퓨터에 안전하게 접속하고 명령을 실행할 수 있도록 해주는 프로토콜이다. SSH 통신의 특징으로는 SSH Key 2개를 가지고 해당 네트워크 사용의 인증절차를 걸친다는 점이 있다. 그렇기에 SSH 통신을 통해 통신하게 된다면 사용자는 개인키와 공개키 2개를 먼저 발급 받아야하고, 서버에 SSH 공개키를 등록하고 로컬에는 공개키와 매치되는 개인키를 등록해두어 매치되는 캐인키를 통해 네트워크에 엑세스 하는 방법의 통신이다.
 
GitHub에서 개발자들은 주로 SSH 통신을 사용하고 우리는 해당 방법으로 GitHub의 원격 저장소를 연동할 것이기에 SSH통신에 필요한 개인키와 공개키를 먼저 발급받아보도록 하자.
 
 

해당 Key를 발급받기 위해 Git bash를 설치하여 해당 cmd창에 'ssh-keygen'이라고 입력해주도록 하자.

그러면 괄호안에(/c/users/~~~~/.ssd/ id_#%@)의 형태로 개인 key번호가 뜰 것이다. 글쓴이도 개인키번호가 뜨기에 부분적으로 스크린샷을 한것을 양해바란다. 

 
 

(개인키는 유출되면 안되므로 양해 부탁드립니ㄷr,,,ㅜ)

 
 

그 후 비밀번호를 지정해야하는데 비밀번호를 입력하고 싶지 않다면 엔더를 2번 누르면 된다. (글쓴이는 지정안함) 

비밀번호 세팅을 맞췄다면 아래화면처럼 출력될 것이다. (개인키번호를 가리느라 스크린샷이 이상한거예요)

 
 

 
 

 

발급이 완료되었따면 키 발급시 출력해준 문구의 경로에 제대로 키가 등록되어있는지 확인해주자.

 

 
 
 

키를 제대로 발급해주었다면 이제 소스트리로 가서 개인키를 등록해보도록 하겠다. 소스트리의 상단 메뉴의 '도구 - 옵션'에 들어가 SSH 클라이언트 설정을 'OpenSSH'로 바꿔준 후, 다시 '도구 - SSH 키 추가' 버튼을 눌러 아까 확인했던 개인키 경로로들어가 개인키를 선택해주자 (pub안달린게 개인키)

 
 

 

 
 

그후 '도구 - 옵션'을 다시 열어 제대로 등록되었는지 확인해주자.

 
이제 개인키 등록은 모두 마쳤고, 공개키를 GitHub에 등록하러 가보도로독 하겠다.
 

아래화면과 같이 GitHub에 로그인하여 오른쪽 상단 프로필을 눌러 'settings' 버튼을 클릭한 후, 오른쪽화면 처럼 SSH and GPS keys에 들어가 New SSH key 버튼을 눌러보도록 하자.

(참고로 글쓴이는 이미 발급받았지만 블로그에 정리하던게 리셋되는 바람에 다시하는 중이라 이미 키가 등록되어 있ㄷr,,)
 
 

 
 
 
Title은 아래화면처럼 아무거나 입력해주고 'key'란에는 아까 발급받앗던 키중 pub이 붍은 키를 메모장이나 다른 프로그램으로 열어 내부 내용을 복붙해주면 된다. 그후 Add SSh key버튼을 눌러주면  위의 화면처럼 키가 등록될 것이다.
 
 
 

 
 
 
이제 개인키과 공유키를 발급받아 등록하는 것은 모두 마쳤고 이제 두 개의 키를 연동 시켜보도록 하겠다.
 
먼저 소스트리로 들어가준 다음, 계정 추가버튼을 눌러준다. ( 글쓴이는 아까 등록해버림,,) 
그 다음 오른쪽 화면처럼 호스팅 서비스는 GitHub으로, 선호 프로토콜은 SSH로 바꿔준후 'Oauth 토큰 새로고침' 버튼을 눌러 나오는 화면에선 스크롤을 내려 초록색 Authorize Atlassian을 버튼을 눌러주면 인증성공버튼이 체크되어 오른쪽 화면이 다시 뜰것이다. 마지막으로 '확인'버튼만 눌러주면 글쓴이 처럼 계정등록이 완료 되고 새로고침버튼을 누르면 기존 GitHub의 개인 레포지토리 목록들이 보일 것이다, (토큰 새로고침관련 화면은 스크린샷첨부못함)
 

 
 
이제 원격 저장소인 GitHub과의 연동을 마쳤으니 위에 간단히 정리해두었던 Git 문법을 소스트리로 사용해보도록하자
(소스트리를 사용하는 이유가 git 명령어를 쉽게 사용하기 위해서임을 잊지말자)
 
 
 

Clone 

clone이란 앞서 말했다시피 원격 저장소에서 로컬저장소로 레포지토리나 소스파일들을 복사하여 가져오는 명령어이다.
 
clone 해오는 방법에는 크게 2가지가 있는데 하나는 모르는 사람의 레포지토리도 클론해올 수 있는 방법으로 GitHub에서 해당 레포지포티를 클릭후 '<>code'의 초록색 버튼을 눌러 SSH링크를 받아와 소스트리에서 해당 링크를 입력하는 방법이고 다른 하나는 자기 자신의 레포지토리인 경우에 소스트리 remote버튼을 눌렀을 떄 위의사진처럼 자신의 레포지토리들 목록이 나왔을 때 오른쪽에 있는 'clone'버튼을 누르는 것이다.
 
 
먼저 전자에 대해 스크린샷을 첨부하며 정리해보도록 하겠다. 
 

 
 
위와 같은 화면에서 GitHub에서 SSH 경로를 복사한 후, 받아오고싶은 로컬 경로를 지정해주면 된다. ( 이미 한번 불러왔기때문에 스크린샷에서는 경로에러가 나는 것 같다 - 정확한 이유는 모름)
 
 
후자는 아래화면에서 clone 버튼을 눌러주면 된다.
 
 

 

 

Push

 
push는 원격 저장소로 로컬저장소의 변경사항을 밀어넣는 명령어이다. 
 
아래에서 간단한 텍스트 파일을 추가하여 push해보록 하겠다.
 

 
 
 
 
위의 화면처럼 commit을 해주면 위의 상단에 push버튼에 '1'이 생긴걸 볼 수 있다. 여기서 push버튼을 눌러주면 아래와 같은 확인화면이 뜨게되고 다시 push를 눌러주면 오른쪽화면처럼 github에도 push가 된다.
 
 

 
 

Fetch

fetch는 원격저장소에서 로컬저장소로 일단 가져오는 명령어이다.
이는 로컬저장소에 원격저장소에서 가져오는 파일들을 merge하지않고 가져오기에 일단 로컬저장소에서 가져오기만 하고싶을 때 주로 사용된다.
 
 
fetch명령어를 소스트리에서 사용해보기 위해 깃헙에서 아까 push한 txt 파일을 수정해보도록 하겠다.
 
 

 
 
 
위의 사진처럼 패치해오게되면 브랜치가 병합되지 않고 새로 받아와 새로받아온 파일에만 수정한 내용이 적용되어 있는 것을 볼 수 있다.
 
 

Pull

 
pull은 fetch + 병합이라고 생각하면 편하다
 
아래에서 pull을 통해 새로 GitHub에서 수정한 내용을 불러와보도록 하겠다.
 
 

 
 
 
아래화면처럼 pull로 받아오면 저절로 병합되어지는 것을 확인할 수 있다.
 
 

 
 
 
 
 
이렇게 기본적인 Git 소스트리(GUI)의 사용법에 대해 정리해보았는데 자세히 정리해본 만큼 앞으로 git을 사용하는데 잇어 정말 유용하게 활용할 수 있을 것 같고 이 글을 참고하시는 미래의 개발자분들도 많은 도움이 되었길 바란다.





 

반응형