본문 바로가기

IT 이야기/Git, SourceTree, Slack

SourceTree

SourceTree 사용정리

해당 글은 생활코딩 https://opentutorials.org/course/1492/8037  을 보고 정리를 위해 남기는 글 입니다.

-----

설치는 sourcetree 검색 후 다운받으면 된다.

 1. Setting

 - 우선 범용성을 위해 source tree 언어를 한국어에서 영어로 바꾼다

 - tools에서 변경가능


 1-1로컬에 git 아이디 추가하기

  - Tools Options 에서 User information란을 채워 local 이용자를 설정함


 1-2 새 저장소 만들기

- clone/new에서 repository 추가가능.

- create new repository에서 어떤 프로젝트를 추가할지 path 설정


 1-3 용어 정리

- repository -> repository는 관리할 프로젝트의 디렉토리

- commit -> 버전 하나를 만드는 행위

- add -> git에 변경된 파일을 추가하는 행위

- index / staging area

Log / History에서 Unstaged files(working copy)상에 수정된 파일 존재


*add된 파일은 staged files에 올라간다. 해당 영역은 index 또는 staging area 라고 함

staging area에 있는 파일에 대해 commit하면 repository에 등록됨.


cf. 아이콘 상태

[?] :  아직 Git에 추적되기전 상태의 파일

[...] : Git에 의해서 추적되고 있는 파일. commit하여 저장소에 보관할 수 있는 파일

[+]  : 새롭게 Git이 추적하도록 추가되었다는 상태 표시

[!] : conflict 발생


2. 수정전 상태로 돌아가기

Discard 메뉴에서 지원

- commit 하기전의 내용을 discard를 통해 이전 상태로 돌아갈 수 있다

- 불필요한 수정을 줄이기 위해 **commit 하기 직전 리뷰하는 습관**을 기른다.

- 빨간 줄(삭제) / 초록 줄(수정)


2-1. Reset

 돌아가고 싶은 commit으로 간다면 커밋에서 우클릭 하여 Reset to commit으로 이동

 Using mode에 따라 다름

 *Hard - discard all working copy changes(매우 조심해서 사용)*

  - 선택 commit이 최신으로 되고 이전 최신사항이 **모두** 사라진다.

  - 프로젝트의 내용물도 같이 수정됨


*Mixed(Default) - keep working copy but reset index*

 - 선택 commit을 최신으로 바꾸면서 이전 최신 commit을 모두 삭제,

 - but, **working copy의 내용은 update하고 싶지 않을 때** 사용


 *Soft - keep all local changes*

 - pass


2-2. Revert

선택한 version을 취소하고 이전 version으로 돌아가는 것. Reset보다 자주 쓰인다.

왜냐하면 commit된 버전을 삭제하지 않으면서 이전 commit의 내용 돌아가기 때문

 - revert 실행시 돌아가고 싶은 version의 새로운 commit이 자동 생성되며 header 이동

 - Revert된 commit에서 다른 Revert를 설정하려면 역순으로 commit을 역전시켜 가야한다.

  - 역순으로 revert하지 않으면 충돌(conflict)이 발생할 수 있다.


3. Branch

 - 안정적인 작업과 불안정한 작업을 동시에 할 때 사용

 - branch를 이용해 불안정한 작업이 취소(drop)되면 해당 부분을 도려낼 수 있다.

 - 혹은 불안정한 작업을 안정적인 곳에 합칠 때(merge) 편리하게 합칠 수 있다.

3-1. branch 만들기

 New Branch로 생성할 수 있다.

 branch간 이동은 더블클릭(current branch)가 된다.


3-2. branch 합치기

 master와 example 브랜치가 있을 때, example의 내용을 마스터로 추가하는 상황

 

  1. 받는 쪽의 브랜치를 선택한 다음(master를 current branch로)

  2. 병합하고자 하는 branch(example)를 merge example into current branch로 선택.  

   이를 master 브랜치로 체크아웃 했다고 한다.


3-3. branch 충돌의 해결

 두 브랜치에서 서로 같은 라인을 수정하고 merge한 경우 conflict가 발생한다.

 발생한 지역에 대해 다음과 같은 형태로 발생한다.


  >>>>> HEAD

      master 브랜치에서 새롭게 수정한 내역

  ========

      example 브랜치에서 새롭게 수정한 내역

  <<<<< example


  git이 병합하지 않고 개발자에게 수정권한을 넘기는 형태이다.

  

해결방법

  1. master에서 코드에 있는 >>>> ==== <<<< 부분의 conflict를 수정

  2. sourcetree에서 [!]파일을 우클릭하여 resolve conflict -> mark resolved 클릭

  3. 다시 commit하여 수정적용

  4. 이 때에는 git에서 conflict를 수정한 상태로 인식하여 자동 commit 내역이 남아있다.

  5. 여기에 보충해 commit을 작성한다


3-4. branch 충돌 최소화

  

4. 원격 저장소

 로컬저장소가 아닌 클라우드에 소스를 보관하는 것

git의 원격 저장소 github.com : 프라이빗 프로젝트라면 유료 (자매품 gitlab.com도 있다)


4-1. 원격 저장소 만들기

- github에 로그인하여 new repository로 원격 저장소를 생성한다.

- public, check Readme에 대한 옵션을 선택하고 create repository 클릭

( 참고 repository 삭제는 해당 repository->setting으로 가 맨 아래에 있다)


 create repository를 하면 원격 저장소의 URL이 생성된다. SSH는 조금 복잡하므로 HTTP를 주소를 복사한다.

source로 돌아와서 Repositoy->Add Remote에서 복사한 주소를 path에 입력한다.

Remotes에 origin이 생성되는 것을 확인할 수 있다. (origin = HTTP의 별칭, 즉 원격 저장소)

push를 통해 로컬과 원격 저장소를 동기화할 수 있다. 어떤 branch를 원격에 올릴 건지 선택할 수 있음.


4-2. 원격 저장소로 업로드

원격 저장소에 연결된 상태에서 로컬의 작업 사항이 바뀌게 되면(commit하면) Push에 버튼에 변화가 생긴다.

1이 뜻하는 바는 원격 저장소와 1개의 버전 차이가 난다는 것을 말한다.


원격저장소의 branch를 눈으로 확인하려면 Show Remote Branch를 체크한다.



5. 협업하기         

5-1. 협업할 Repository를 로컬로 다운

 Clone / New 버튼으로 가져올 Repository의 URL 주소를 가져온다.

또한 로컬에서 어디에 clone할지에 대한 경로도 설정한다.


5-2. Push & Pull

   버전 관리 프로그램을 시작하기 전에 원격 저장소에 새로운 버전이 올라간 것이 있는지 확인한다.

 Pull을 통해 원격과 로컬의 동기화가 가능하다.

 pull을 먼저 해놓고 작업해야 충돌이 일어날 일을 미연에 방지할 수 있다.


만약 B에서 push해 원격의 버전이 바뀐상태에서 A가 push를 하면 원격은 A의 push를 거절한다.

-> 따라서 pull을 먼저 한 상태에서 진행해야한다.

-> 만약 A가 push전에 작업한 내용이 있다면, B가 작성한 내용에다 pull하면 자동으로 merge 된다.


정리하면 pull -> work -> commit -> pull(혹시 work동안 누가 올렸을지도 모르므로) -> push 순으로 진행한다.


5-3. 충돌의 해결

 서로 다른 브랜치에서 같은 부분을 수정한 경우 충돌이 발생한 것처럼,

서로 다른 협업자가 같은 부분을 수정하게 되면 충돌이 발생한다.

해결방법은 3-3과 동일하다.

cf. **나중에 push하려한 사람이 conflict를 해결할 책임이 주어진다.**

> 자주 자주 pull해서 작은 단위의 conflict를 만나도록 한다. 자주 pull 안 할 수록 큰 단위의 conflict를 만난다.

> 발생하면 끙끙 앓지말고 물어보도록하자


6. 고급주제(순서에 상관 x)

6-1. 비교, 병합 외부 도구 연결

 지금까지 충돌을 일일이 해왔다면 자동으로 해주는 도구들이 많은데 diff 라고 부른다.

외부 도구 연결은 tool->option->Diff->External Diff에서 선택 할 수 있다.

diff에서 사용하는 용어 정리

Local : 로컬에서 작업하는 브랜치

Base : 두 브랜치의 공통 부분   (조상)

Remote : 원격 저장소

.orig 파일 : 충돌을 해결하기 전의 버전(merge를 하면 생성된다.)


6-2. 버전관리에서 제외하기(.gitignore)

 프로젝트에 상관없는 파일이라도 .git이 있는 디렉토리에서 생기는 모든 파일이 자동으로 추가되기 때문에,

ignore할 파일을 설정할 필요가 있다.

Unstaged files에서 ignore할 파일을 선택하고 오른쪽 클릭으로 ignore 메뉴로 이동한다.


 ignore에서 무시할 pattern이나 파일 이름을 작성한다.

작성한 뒤에는 .gitignore 파일이 생성되며 어떤 것을 ignore할 지 적힌 파일이 생성된다.

.gitignore에 적는 패턴을 복잡하게 적어 specific하게 적용하려면 glob 이라는 언어의 문법을 적용해야한다.

쉽게는 www.gitignore.io 에서 IDE나 editor 종류를 검색창에 입력하면 리스트를 작성해준다


6-3. Contributors 초대하기

 contributor 초대는 다른 사람이 자신의 repository에 push할 수 있도록 승낙해주는 기능이다.

Settings에서 collaborators로 이동해 초대할 유저의 아이디나 메일을 적는다.

(메일보다는 아이디가 검색이 잘 되는 듯)

( conllaborators이동 화면 )


(아이디 or 이메일 입력)


 이 때 주의사항은, 초대받은 사람은 email에서 최종 승낙을 해야 해당 repository의 contributor가 될 수 있다.