1. 기본 조작
가. 파일 아이콘
•
'...': 버전관리프로그램이 트랙킹 중인 파일
•
?: 트래킹을 못하고 있는 파일
나. Undo
1) Reset
•
Reset: 과거 버전(커밋)을 지워서 기존의 작업을 취소하는 것
•
로컬 커밋에만 사용 가능
•
--hard: 과거 커밋 기록과 파일 내 작업 내용 삭제
•
--mixed: 과거 커밋 기록은 삭제되지만 파일 내 작업 내용은 유지
•
상황: feat 4에 대한 작업을 취소 희망
•
Reset 작업: HEAD가 feat 4 커밋을 바라보고 있는 상황에서 돌아가려는 커밋을 선택하고 '커밋 초기화' 실행
2) Revert
•
Revert: 과거 버전을 유지한 상태로 취소작업 커밋을 쌓아서 기존의 작업을 취소하는 것
•
reverse commit(소스트리 용어) == revert(Git 용어)
•
HEAD~3까지의 커밋을 취소하고 싶으면 각각의 커밋에 대해 revert 작업 수행해야 함
•
상황: feat2-3, feat2-2, feat2-1 커밋 삭제에 따라 feat2에 대한 작업 초기화 희망
•
작업 전 파일
•
feat2-3, feat2-2, feat2-1 커밋의 생성 역순으로 reverse commit 생성 및 원격저장소에 push
→ staging(빨간색) 부분은 무시할 것
•
작업 후 파일
2. 응용
가. Git Flow Branch 전략
1) 작업 브랜치 생성(from develop 브랜치)
•
‘새 기능 시작’ 선택
참고) GitFlow 기능 선택 후 1
참고) GitFlow 기능 선택 후 2
2) 작업 완료 후 staging 병합
•
작업 브랜치에서 작업 완료 후, staging 브랜치에 병합하여 테스트
참고) staging 병합 후 Git History 이미지
3) staging 테스트 완료 후 develop 병합
•
staging 브랜치에서 테스트 후 이상 없으면 develop 브랜치에 병합
참고) GitFlow 기능 선택 후 3
참고) GitFlow 기능 선택 후 4
참고) develop 병합 후 Git History 이미지
4) release 브랜치 생성 후 로컬 테스트
•
develop 브랜치에서 release 브랜치 생성 후 로컬에서 테스트
•
만약 로컬 테스트 시 이상이 있다면 release 브랜치에서 추가 작업 진행
참고) GitFlow 기능 선택 후 5
참고) GitFlow 기능 선택 후 6
참고) release 브랜치 생성 후 Git History 이미지
5) release 브랜치를 master 및 develop 브랜치에 병합
•
release 브랜치에서 테스트 완료 후 이상 없으면 태그 생성 후 master 브랜치와 develop 브랜치에 병합
참고) GitFlow 기능 선택 후 7
참고) GitFlow 기능 선택 후 8
참고) master와 develop에 release 브랜치 병합 후 Git History 이미지
참고) master와 develop push 후 Git History 이미지
나. 원격 저장소에서 Pull 받을 때
1) Rebase 활용
Rebase 명령 시 분기점 이후의 커밋 버전 변경(내용 변경 X)
→ 분기점 커밋 이후 공동작업한 부분에 대해 이슈 발생
•
상황: 로컬에서의 작업 마치고 원격으로 Push하기 직전
→ 다른 사람의 최신 작업물이 원격 저장소에 올라와서 Pull을 받아야 하는 상황
•
fetch & rebase
→ 원격저장소의 작업을 로컬저장소로 가져옴(Fetch)
→ 원격저장소의 작업물(FIX 관련 커밋)을 기반으로 로컬의 작업을 쌓음(Rebase)
→ rebase 명령에 따라 로컬에 있던 FEATURE 관련 커밋의 해쉬값이 변경됨
•
push
→ 질문) 이 경우 staging 브랜치로 PR을 보낼 때, FEATURE에 대한 커밋만 담아서 보내는 방법은?
1. PR용 브랜치를 생성해서 cherry pick으로 로컬 커밋(FEATURE 부분)만 추가하여 PR을 보냄?
2. 로컬 커밋을 원격으로 push하기 전에 dev-api의 공동 작업자의 커밋(FIX 부분)이 staging으로 merge될때까지 기다렸다가 PR?
Python
복사
2) Merge
•
상황: 위의 Rebase 상황과 유사
•
fetch & merge: origin을 현재 브랜치로 설정하고 로컬 커밋을 병합
→ 로컬 커밋 위로 원격 커밋이 쌓임(Merge)
•
push
→ Merge 관련 커밋 생성
→ 질문) 이 경우 staging 브랜치로 PR을 보낼 때, FEATURE에 대한 커밋만 담아서 보내는 방법은?
1. PR용 브랜치를 생성해서 cherry pick으로 로컬 커밋(FEATURE 부분)만 추가하여 PR을 보냄?
2. push 하기 전에 공동작업자에게 노티하여 모든 커밋을 포함한 PR?
Python
복사
다. 로컬 커밋 중 중간 일부 커밋만 제거할 때
1) Cherry Pick 활용
•
원격 브랜치(로컬과 원격 브랜치의 분기점)에서 임시 브랜치 생성
•
포함할 커밋에 대해서만 임시 브랜치에 Cherry Pick
→ 제거할 커밋은 임시 브랜치에 담지 않는다
•
로컬 브랜치를 원격 브랜치 위치로 Reset —hard
•
로컬 브랜치에서 임시 브랜치에 담긴 커밋을 Cherry Pick
•
로컬 브랜치 내 커밋을 원격 브랜치로 Push
3. 이슈
가. 인증
1) Github Token 인증
•
원격저장소 경로의 URL 앞에 토큰을 명시해야함
•
이하 소스트리의 오른쪽 상단의 설정 → 팝업창의 원격 카테고리에서 설정 가능
•
URL / 경로란에 다음과 같은 형태로 수정
→ https://토큰@원격저장소 경로
Reference
•
personal token으로 sourcetree github 연동, https://pyoungt.tistory.com/172
github 연동, https://pyoungt.tistory.com/172