필요한것 : GIT + SourceTree (유틸리티)
1. 깃허브 회원가입 + 인증까지 완료
2. 소스트리 설치
2023.05.24 - 1차 수정 / 설명 수정 및 추가
2023.07.12 - 2차 수정 / 병합 충돌 설명 수정
2023.10.19 - 3차 수정 / 설명 수정
2023.11.10 - 4차 수정 / 이미지 교체
2024.12.09 - FORK 추천글 추가
-> 소스트리 같은 git GUI 인 fork 도 한번 구경해보세요.
(https://seo-developer.tistory.com/95?category=1094813)
SourceTree 의 중요한 개념에 대해서 먼저 설명하자면
0. SourceTree 는 나무라고 생각하자.
- https://www.sourcetreeapp.com/
- 사용자와 컴퓨터의 소통(Interface)을 위한 대표적인 입력 방법은 CLI 와 GUI
- CLI 는 Command Line Interface, 터미널처럼 한 줄 한줄 직접 명령을 전달하는 방식
- GUI 는 Grapic USer Interface, 그래픽(버튼 등의 UI)을 통해 컴퓨터에 명령을 전달하는 방식
- 소스트리는 Git GUI 인터페이스 입니다.
(1). master
- 사용자가 보고있는 최종버전
- 실제로 서비스되고 있는 상태
- 개발시 배포 전까지 건들일 필요 없음 ★
(2). develop
- 개발자가 개발하고 있는 상태
- 기능이 추가되거나 수정되고있는 일종의 테스트서버
- 실제로 사용하고 있는 공간
(3). branch
- 각각의 개발이 진행되고 있는 ★가지, 정말 말 그대로 가지의 역할
- 개발중인 기능의 추가 및 수정등의 변경이 있을 경우. 가지에 작업물을 커밋(저장)하여 디벨롭에 전달
- 개념만 설명하고. 상세 설명은 하단에 이어서 하겠습니다.
1. master
- 딱 봤을때 보여지는 나무
- 게임으로 예를 들면, 실제로 서비스 하고있는 상태.
- 최종의 최종버전 이라고 생각하면 된다.
1-1. origin
- 현재 시점. 소스트리는 현재 어느 시점에 있는지가 중요하다.
- 시점을 엉망으로 만들면 파일을 올릴수도, 내려받을 수도 없다.
2. develop
- 실질적으로 개발자가 사용하고 있는 핵심. 나무의 줄기 (제일 굵은 메인)
- 사용자는 볼 수 없지만 개발자들은 이곳에서 개발을 진행한다.
- 여기에 잔가지(branch) 를 걸어서 사용함.
3. branch
- 개발중인 공간. 나무의 가지
- ★브런치를 사용해야 하는 이유★
1). 협업시 용이하게 사용됨
- 예를 들어 A와 B가 각각 사과와 귤을 5개씩 따와야 하는 상황
- ① A(사과: 0, 귤: 0), B(사과: 0, 귤: 0)
- A의 경우만 먼저 살펴보자면
- ① A(사과: 0, 귤: 0)
- ② A(사과: 3, 귤: 0)
- ③ A(사과: 5, 귤: 0) / 임무 완료
- ④ 완료된 임무 상태를 디벨롭에 전달 ~ 디벨롭(사과: 0, 귤: 0) -> (사과: 5 , 귤: 0)
- B의 경우를 살펴보면
- ① B(사과: 0, 귤: 0)
- ② B(사과: 0, 귤: 3)
- ③ B(사과: 0, 귤: 5) / 임무 완료
- ★ ⑤ ★ 완료된 임무 상태를 디벨롭에 전달,
- 나를 힘들게 하는 ★병합 충돌★의 큰 원인은
1). 한개의 파일로 두 사람 이상이 작업한 경우
- 위 브랜치에서 설명했던 사과의 예시에서, A 브랜치의 처음 시작 상태(①)는 사과:0, 귤:0 이다.
작업을 진행하여 A브랜치의 ③번처럼 사과: 5, 귤:0 개가 되어
푸쉬 및 디벨롭에 머지 요청까지 한 시점이라고 가정하자.
- 이 시점에서 B브랜치는 ②번 시점의 사과:0, 귤:3 일때.
④ 번의 디벨롭 최신 상태를 먼저 내려받아야 충돌이 발생하지 않음.
- 주의할 점은. 이미 B브랜치의 작업 상태가 사과:0, 귤:3 일 경우.
커밋 안하고 디벨롭의 최신 상태 사과: 5, 귤:0 를 받았다간 내 코드 사과:0, 귤:3 가 원귀됨/ 코드 날아감
내 작업물 백업용 가지를 따로 빼서 커밋을 꼮꼮꼮 먼저 합시다.
- 내가 사용하는 방법은...
- 다른 개발자의 작업 내용을 아는 경우엔 병합충돌 옵션에서 알아서 체크
- 다른 개발자의 작업 내용을 모르는는 경우엔 병합충돌 옵션에서
(1). 상대방 코드를 우선 수락
(2). 내 코드 중 수정된내용이 있는지 확인
(3). 햇갈리면 내 코드 따로 백업하고 다른 작업자와 대화 후 충돌 해결
0). 내 파일을 내 브랜치에 커밋 및 푸쉬
1). 디벨롭으로 체크아웃 (커밋 안하면 체크아웃 안됨)
2). 디벨롭 최신 상태 내려받기(pull)
3). 최신 상태의 파일에 백업된 내 코드를 붙여넣기
4). 커밋 및 푸쉬, 머지 요청
- 처음에 충돌 내도 괜찮으니까 꼭 물어보고 소통하기. 내 작업내용 공유하기. 버전 바꿔야 하면 꼭 상의하기.
- 요약하면. 브런치에 작업물을 커밋 및 푸쉬(원격 저장소로 전달)한 뒤,
디벨롭에 머지_병합(원격 저장소로 전달한 내 작업물을 디벨롭 상태의 작업물과 합치기)하는 방식으로 사용됨
- 여러명의 작업이 엉키지 않는다!
2). 또한 버전 관리에 용이한데,
②번의 경우 처럼 사과가 3개만 필요한 경우. 해당 시점으로 작업을 돌려서
커밋, 푸쉬, 머지 하면 작업했던 내용을 반복하지 않아도 된다!
- 따라서 브런치에서 작업이 완료될 때 마다 해당 가지에 커밋을 걸어야 한다.
3-1. commit
- 브랜치에 내 파일을 올리는 기능
- 커밋을 할 때 스테이지가 존재하는데. 내 PC, 로컬에만 존재할때는 스테이지 밖이고.
소스 트리에 올리면 스테이지 안에 넣은것(아직 로컬 안임)
- 만약 엉뚱한 것을 커밋했더라도, 아직 push 전이면 내 로컬에만 존재하므로 당황하지 말고 취소하면 된다.
4. push
- 커밋까지 진행된 시점을 기준으로, 업로드한 내 파일을 실질적으로 원격 저장소에 올리는 기능
- 위에 오리진 설명을 하면서. 시점이 엉망이 되면 push 시에 오류가 뜬다.
1). 오리진(현 시점) 문제
- 차라리 로컬에 저장된 폴더 째로 지우고(내 코드는 따로 백업) 새로 clone 받아서 최신 상태를 내려받은 뒤
디벨롭에서 새 브랜치를 뽑아서 사용하는걸 추천합니다.
5. merge
- push 된 내용이 담긴 브랜치와 디벨롭 가지를 합치는 기능
- 왜? 합쳐야 하냐면.... 내 작업물과 다른 사람의 작업물을.. 합쳐야 하니까... 그것이 협업이니까 ,.,.,ㅁ8
- 내 가지에서 디벨롭을 오른쪽 클릭하여 fetct develop (최신상태 업데이트)한 뒤 현재 브랜치로 develop 병합
- 병합 후 git 에서 머지 리퀘스트 날리면 git 관리자가 확인 후 병합을 수락하거나 거절 할 수 있다.
6. pull
- 내려 받는 기능.
정리
1), 마스터에서 디벨롭 가지를 따로 뽑는다.
2). 실질적으로 개발이 진행되는 공간
3). 필요한 기능에 맞춰 각각의 브런치를 뽑는다.
4, 5). 개발이 진행되면 내 브런치에 작업물을 커밋 및 push 하여 원격 저장소에 저장한다.
6). 디벨롭에 머지, 깃 관리자에게 머지 리퀘스트
7). 전체 개발이 끝나면 마스터에 배포
8). 배포된 최종상태
주의사항
0. 패치(최신화, 로컬이랑 동기화) 꾸준히 하기
1.develop 이랑 함부로 병합하지 말지
- 내 브랜치에 push 하고, 병합은 GIT LAP에 병합 요청을 넣는 방식으로 .. (뭔가 유실될수도 있다)
- 디벨롭에서 가져와서 내 로컬로 병합은 OK, 반대는 XX (위치: 내 브랜치 - 디벨롭을 오른쪽 클릭해서 병합)
2. 내 브랜치 계속 쓰기. 충돌나면 문제있는것
'Git' 카테고리의 다른 글
| Fork 포크 사용법 (0) | 2024.11.07 |
|---|---|
| GitLab, SourceTree 초기 세팅_(수정: 2023.07.12) (0) | 2023.03.20 |
