iOS) git과 github "잘" 사용하기(feat. Source tree)

iOS) git과 github "잘" 사용하기(feat. Source tree)

2022. 1. 20. 18:44ㆍiOS/iOS memo

728x90

인프런의 깃, 깃헙 강의를 보고 작성된 포스팅입니다.

git

형상관리 시스템의 한 종류로, 언제든지 저장 시점으로 돌아갈 수 있다는 장점이 있다

github저장소 이용시 가장 기본이 되는 개념 세가지

commit

게임 세이브에 해당하는 행동
언제든지 커밋한 시점으로 되돌아갈 수 있음
저장을 원하는 파일들을 묶어서 커밋 명령을 수행하면된다

add(스테이지에 올린다)

위에서 커밋전에 저장을 원하는 파일들을 묶어서 해야한다라고 표현했는데 이 작업을 스테이지에 파일을 올린다 라고 합니다.
(10개의 파일을 작업했는데 1번과 5번의 작업만 묶어서 커밋하고 싶다고 했을때, 1번과 5번을 스테이지에 올립니다. 그럼 이제 commit할 수 있는 상황이 됩니다-> stage에 파일을 올려야 그 파일들을 commit할 수 있다. 이걸 add라고 합니다.

push

작업했던 commit을 github에 업로드하는것
git에서 push라는 명령어를 내리면 내 commit들이 github사이트에 올라가서 다른 사람들과 공유가 가능해짐

저장소 만들기

clone을 통해서 주소를 복사한 다음 소스트리를 설치합니다.

주소 복사했던것을 Source URL에 넣고 clone

클론을 한 뒤, 작업 후 스테이지에 파일을 추가(add)

1. clone(초기에 한번만 하면된다)

2. add

test용으로 무의미한 md파일들을 추가해봤음

자동으로 sourcetree에 파일들이 생성된 모습

stage에 올라가지 않은 파일(물음표 표시가 되어있음) 두개가 생성되었습니다

3. commit

반드시 한 번에 하나의 논리적인 작업만을 커밋합니다.

4. push

맥북 기준) push할때 깃헙 비밀번호를 입력하면 에러가 뜨는데 실제 깃헙 비밀번호가 아닌, 깃헙 계정을 만들때 생성했던 토큰을 비밀번호에 입력해야한다.
~/Library/Application Support/SourceTree에서 깃헙아이디@~ 파일을 삭제해주고 다시 push하면 비밀번호 입력창이 다시 뜸

위에 내용 정리

clone: 원격 저장소(github)을 내 컴퓨터에 복사해온다(주소 copy)
add: 내 컴퓨터에서 작업한 파일들을 스테이지에 추가(staging)
commit: 스테이지에 올라온 파일들을 가지고 내 컴퓨터에 저장(세이브와 같다)
push: 커밋들을 원격 저장소에 업로드

핵심: stage에 올라간 파일을 commit으로 만들 수 있다

작업 되돌리기(staging 하지않은 마지막 commit으로 돌아가보기)

checkout이라는 명령어를 사용해서 마지막 commit으로 돌아갈 수 있다.(마지막 저장으로 돌아가기~)
sourcetree에서는 코드뭉치 버리기 기능(Discard hunk)을 사용하면 변경사항을 되돌릴 수 있다.
Discard hunk버튼을 이용하면 코드가 원상복구가 되는 모습을 확인할 수 있다.

브랜치(branch) 이용하기

작업을 나누고 싶은 commit에서 마우스 우클릭으로 브랜치 따기

생성해둔 md파일 내용을 확인해보면 이전 작업으로 돌아갔다가 이후 작업으로 자유자재로 돌아갈 수 있음.

git에서는 특정 branch로 돌아가는것을 checkout이라고 한다.

sourcetree에서는 더블클릭만으로도 이동이 가능하다

Merge(git 브랜치 병합하기)

최종 master로 각 브랜치들의 원하는 부분만 추려서 병합하는 작업을 merge라고 합니다.
하나의 브랜치를 현재 브랜치와 합치는것
현재 브랜치는 헤드(HEAD)브랜치인데, 예를들어 HEAD브랜치가 master이고 여기서 version2브랜치를 병합하면 version2의 내용이 master에 반영되게 됩니다.
https://learngitbranching.js.org/ 깃을 배울 수 있는 좋은 사이트

Learn Git Branching

An interactive Git visualization tool to educate and challenge!

learngitbranching.js.org

현재 HEAD가 main이고 나는 main에서 작업중이다

git checkout version2명령어를 적으면 *별표가 version2로 바뀌고 현재 version2에서 작업중임을 알 수 있음

source tree에서는 더블클릭만으로 이 checkout이 가능했었음

head가 main으로 바뀌고 그 이후에 merge를 했으니까 version2브랜치의 내용이 main에 병합된다는 의미!

아래와 같이 HEAD 브랜치에 변경사항이 없고, 병합 대상 브랜치가 HEAD로부터 시작된 경우

아주 쉽게 병합이 가능한 상태를 -> Fast forward 라고 합니다.

다른 명령어 실습을 위해 reset 해줬다

main을 head로 바꾸고 version3를 main으로 병합시키겠다

여기에서 git merge version2를 통해서 main에 version2를 merge하게되면 아래와 같이 된다

그래서 배운대로 source tree에서 main을 클릭해서 main을 HEAD로 한 다음,

version2 내용을 우클릭해서 merge했는데 conflict가 났다.

문제의 파일을 열어보면, 내가 작성하지도 않았던 HEAD, ====라는 기호, version2라는 글씨가 보이는데 그 의미는 아래와 같다.

HEAD: 현재 변경사항(main)

=======: 그냥 구분 기호

version2: version2에서 수정했던 내용

합치려고 봤더니 현재 변경사항은 요렇고 version2브랜치에서는 요런걸 추가했었네..

그래서 너 이거 합칠거야? 라는 의미입니다.

결론.

수동으로 고쳐줘야 합니다.

저는 이렇게 수정해줬습니다. cmd + s를 통해서 저장해줬고요

다시 Source tree로 돌아가서 stage에 올려줬습니다.

stage는 commit을 하기전에 add를 하는 작업이라고 했습니다.

그렇다면 그 다음은 당연히 commit

이 과정까지 거치면, main이 version2와 기존의 main과 합쳐져서 merge가 됩니다. push를 해서 바로 반영해줍니다.

merge를 하고나서 필요 없어진 version2 브랜치는 삭제해주어도 됩니다. 그래도 내용은 그대로 남아있으니 걱정안해도 됩니다!

실험1

version3라는 브랜치를 새로 만들어서 내용을 추가해봅니다

그리고 Source tree에서 stage에 올렸고(add) commit을 합니다.

그다음 merge를 하면...

너무도 쉽게 conflict없이 main이 version3로 올라갑니다. (fast forward)

의문

main을 더블클릭해서 main을 HEAD로 만들고, version3 branch가 main에 병합되는건데

왜 main이 version3로 올라간다는 표현을 쓰는건지 모르겠음. version3가 main으로 올라간다는 표현이 더 맞지 않나..?

충돌 해결하기

선수개념

pull (fetch와 merge의 조합)

내 현재 컴퓨터보다 앞선 commit이 server에 저장되어있다.
깃허브의 master가 내 local의 master보다 더 앞서있다.
습관적으로 pull을 확인하자

conflict가 발생했을때 해결방법

* conflict발생시, 아래와 같이 커밋하지 않은 변경사항이 생기고 느낌표를 통해서 이 파일이 충돌이 난 파일이다. 하고 알려줍니다.

방법 1) 수동으로 직접 파일을 고쳐준다

그리고 stage에 올리고 커밋해주면 정상적으로 conflict가 해결된다

방법 2) 병합툴을 이용해서 해결한다

만일 이전 commit으로 돌아가고 싶다면 우클릭해서 Reset main to this commit으로 설정해주면 된다.(Soft, Max, Hard)

그럼 이전의 충돌이 났었던 상태로 돌아갈테고, stage에 올라가지 않은 파일(느낌표파일)을 우클릭해서 "충돌해결" 을 클릭한 뒤, "'저장소'것을 사용하여 해결"을 클릭해서 해결해주면된다

('내것'은 내가 master이고 현재 상대편이 conflict가 난 상황이라면 "'저장소'것을 사용하여 해결"을 클릭)

이전 커밋으로 되돌리기(reset, revert)

reset

돌아가고 싶은 commit을 우클릭한 후, Reset main to this commit을 클릭(soft, mix, hard가 있는데 되돌리기는 hard)

reset의 문제점

1) 커밋이 날아간다

지금은 원격에 push를 적용해둔 덕분에 날아가지 않았지만, 원격저장소에 없는 내용을 reset으로 되돌렸다면 날아간다.....(물론 살릴 수 있는 방법도 있지만 복잡해진다)

2) 강제 push가 필요하다 (강제 push 없이도 해결은 가능하지만 좀 복잡해진다.. 그 복잡한 것을 바로 밑에서 실험해볼까한다)

실험1

강제 push없이 reset 사용하기

reset으로 먼저 force 처리하여 과거시점으로 돌아간다음, 다시 내용을 추가하고 커밋.
여기서 Push하면 conflict 나기 아주 좋은 상황

이를 방지하기 위해선 아래의 그림에서 2번 Commit(현재 commit)을 과거 commit(1번)에 merge하고 사용하면 좋다
1번 commit 우클릭해서 merge
conflict가 나면 "커밋하지 않은 변경사항" 클릭한 뒤, 스테이지에 올라가지 않은 파일에 속해있는 느낌표 파일 우클릭하고 충돌해결 - '내것'을 이용해 해결 클릭

여기서 push하면 강제 push가 아니어도 push가 됩니다

revert