Github과 SourceTree(2): Pull 부터 Push 까지

Git의 버전관리 과정은 이렇다 

1. 서버의 update 상황을 먼저 PULL 해온다

2. 관리대상 폴더 내의 파일을 변경한다

3. 적용할 변경사항을 STAGE 에 올린다

4. COMMIT 하여 로컬 저장소에 저장

5. PUSH: 로컬저장소에 저장된 변경사항을 서버에 업로드

→ 저장소 이중구조로 인해 중앙서버가 날아가더라도 push 를 통해 복원 가능하다

 

 

채근담 폴더에는 저장소 연결 후 아직 업데이트된 내용이 없으므로 Stage, Commit 부터 진행한다. 

하지만 첫 연결 이후부터는 작업하기전 무조건 Pull 을 실행하여

혹시라도 업데이트 되어있을지 모를 프로그램에 누가 되지 않도록 한다. (중요)

 

 

1) 파일 업데이트

채근담 폴더에 txt 파일을 하나 추가해 보았다

소스트리에 들어가면 잠깐의 로딩 후 아래처럼 커밋알람이 뜬다

변경사항을 감지한 것이다

 

'모두 스테이지에 올리기'한 상태

 

스테이지에 올린다는 것은 변경사항이 원격저장소에도 적용될 예정임을 뜻한다. 

변경된 사항중 커밋할 것들을 모두 스테이지에 올린다. 

 

2) 커밋 Commit

 

커밋한 내용은 master 브랜치에서 확인할 수 있다.

이 단계에서 변경사항은 로컬 저장소에만 저장되어있다.

깃헙 레퍼지토리를 확인하면 아무 내용도 업데이트 되어있지 않음.

 

 

3) 푸쉬 Push

Push 는 로컬에 적용된 변경사항을 서버에도 적용하는 행위이다.

중요한 단계이니 만큼, 커밋이 끝나면 친절하게 Push 버튼에 알람이 뜬다. 

 

Push 진행후 레퍼지토리를 확인하면 그때 비로소 gitHub이 업데이트 되었음을 알 수 있다.

커밋할 때 썼던 작업 내용과 누가 마지막으로 업데이트 했는지를 볼 수 있다. 

 

 

 

4) 커밋 되돌리기 작업

보통 바로 이전의 상태로 돌릴 때 사용하는 기능이다. 여러 단계를 거쳐온 커밋을 되돌리려고 하면 그 사이에 업데이트 된 내용을 정말 삭제할 건지 확인하는 중간 단계가 있다.

 

무시무시한 메세지

hard 속성을 선택하면 해당 커밋 당시로 돌아간다. 파괴적인 작업이기에 경고 단계가 많다.

이후 push 하지 않고 pull하면 아래처럼 다시 최신 원격저장소의 상태로 원상복귀된다. 

 

 

5) Pull 

커밋 내용이 '책 제목의 뜻과 ~' 였던 상태로 되돌아갔음을 확인할 수 있다.