우테코 2주차 - Git & GitHub 기능 강의 수강

시험기간이라 우테코 프리코스 1주차 회고에

제대로 신경을 쓰지 못했다.

 

2주차부터는 정말 전력을 다하겠다고 결심한 만큼

먼저 1주차 공통 피드백에 나온

추가 학습자료를 차근차근 정리해보려한다.

 

프리코스를 하면서 자바 기초적인 부분은 물론이고

git & github에도 어색한 나의 모습을 발견할 수 있었다.

 

부족한 부분을 적나라하게 바라보니 갈증이 생겼고,

차근차근 하나씩 공부해나아갈 생각이다.

 

먼저 첨부해주신 git & github 기초 강의를 수강하고

내용을 정리해보겠다.

---

내용 정리

 

Git이란?

: 형상 관리 시스템의 한 종류

: 저장 시점으로 되돌아갈 수 있는 기능

 

Commit(커밋)

: 세이브에 해당하는 행동

: 언제든지 커밋한 시점으로 되돌아갈 수 있음

: 저장을 원하는 파일들을 묶어서 원하는 변경내역만 커밋 명령 수행

 

Add : 스테이지에 올리는 행위

: 저장을 원하는 파일들을 묶는 행위

: 스테에지에 파일을 올림== add

 

Push : github에 업로드

: 커밋  => 현재 작업 내용의 세이브 데이터가 내 컴퓨터에 저장됨

: github에 업로드하게 되면 원격저장이 되어 공유 및 복구가 가능

: github에 업로드 ==push

 

 

Clone : github의 파일을 로컬로 가져오기

-> Source Tree 프로그램에 url 등록을 통해 가능

커밋하기

: 원하는 파일을 스테이지에 올리기

: 원하는 변경내용을 골라 커밋

: 반드시 하나의 논리적인 작업만을 커밋

: 커밋 메시지를 잘 적어야 함

 

커밋메시지 작성법

: 첫줄에 간단하지만 명확하게 내용을 씀

: 한줄을 비우고

: 자세한 내용을 적음

---

checkout : 마지막 커밋으로 돌아가기

-sourceTree에서는 코드뭉치 버리기

=> 가장 마지막 commit 상태로 복구됨

---

 

브랜치

: 기존 내용을 유지한채 새로운 내용을 추가하고 싶을 때

: 체크아웃 - 특정 브랜치(혹은 커밋)으로 돌아가고 싶을 때 사용

: 소스트리의 체크아웃  - 브랜치 이름을 더블 클릭하는 것만으로 체크아웃

 

master 브랜치

: 디폴트로 생성된 브랜치

: 최종버전/ 마지막 최종본이 들어있는 것

: 다른 기능 구현은 주로 브랜치에서 구현

 

 

Merge : 브랜치 병합

: 하나의 브랜치를 현재 브랜치와 합치는 것

Merge1 : Fast-Foward : 헤드 브랜치에 변경상황이 없을 경우

- 합치려는 브랜치가 헤드 브랜치로부터 파생

- 그 사이 헤드 브랜치에는 갱신이 없는 경우

branch 상황	merge 된 상황

 

Merge2 : 가지가 생겨난 경우

- 과거의 커밋으로부터 브랜치를 생성해서 작업을 한 경우

- 브랜치 작업 이후에 헤드에 다른 새 커밋이 있는 경우

- 여러 브랜치를 동시에 작업하면서 병합을 시도할 경우

 

이전 상황	Merge 이후 상황

 

=> 충돌발생 가능성이 존재

 

: 최신 내용 하나만 선택

: 최신 내용은 타겟 브런치에 있는 경우가 많음

: 여러 파일에 변경사항이 혼재해 있는 경우도 크게 어렵지 않음

 

>>충돌 예시 : main - version2

=> head의 내용

=> version2의 내용 구분

 

=> 수동으로 선택후 저장 => 커밋

 

=> 충돌을 피하려면 ? : 다른 파일에서 작업하면 충돌이 안남

---

Pull : fetch + merge

- 서버의 내용이 최신일 경우 pull을 적용

 

충돌 피하기1. 에디터 사용

- 충돌이 난 변경사항을 표시

 

충돌 해결하기2. sourceTree 내부에서 해결

> 충돌이 난 파일 > 충돌해결 > 저장소 / 내것/ 병합

---

reset

: 소스트리 > 이 커밋까지 현재 브랜치를 초기화 

: 우선 여러 모드 중에 reset-hard만 기억하자

=> 원격저장소에 push를 해놓았으면 저장되어 있지만

=> 그것이 아니라면 되돌린 내용들은 날아갈 수 있음

 

-> 강제 푸시를 통해 해결이 가능하지만

-> 변경사항이 날아갈 수 있다는 점은 본연적으로 가진 reset의 한계임

---

브랜치를 활용한 커밋 되돌리기

1) 되돌릴 커밋 대상으로 브랜치 생성

2) 체크 아웃

3) 변경사항 수정 후 커밋

4) master에 merge

 

장점 : 쉽다

단점 : 트리가 조금 지저분해짐

 

=> reset보다 더 권장되는 방법

=> push를 할 때 문제가 생기지 않음

 

---

revert : SourceTree -커밋 되돌리기

: 커밋을 남기되 작업내용을 되돌림

: 정석적이나 충돌 가능성은 여전히 존재

: reset과 달리 되돌린 변경내용이 그대로 존재

 

 

=> revert로 여러 커밋을 되돌리려면?

: 최신부터 순서대로 revert를 반복적용하면 됨

 

git revert HEAD : 가장 최근 커밋 되돌리기

git revert HEAD -1 : HEAD 부모 1번도 되돌리기

 

---

Commit -amend / Stash

 

브랜치 체크아웃시 주의사항

: 현재 작업디렉토리가 깨끗해야 함

== 변경사항이 있다면 checkout 할 수 없음

 

방법1. 작업 중인 내용의 임시저장

- 브랜치1에서 일단 임시 커밋을 한다.

- 브랜치2로 체크아웃을 하고 할 일을 한다.

- 다시 브랜치 1로 돌아와 1의 작업을 마무리 짓는다.

- 커밋 덮어쓰기를 한다.

- 필요하다면 push --force를 한다

 

 

>> commit- amend : 마지막 커밋 내용을 덮어씀

 

 

>> Rebase :재배치

: 두 브랜치를 합칠 때 사용

: 장점 - 커밋 히스토리가 깔끔히 정리됨

: 단점 - 원격저장소가 올라간 경우 + 협업을 하고 있는 경우 특히 위험함

 

=> 로컬에서만 우선 사용

=> 원격에 올린 것을 재배치할 경우 꼬일 수 있음

 

 

---

>>느낀 점

 

우선 강의를 수강하며 느낀 점은

왜 협업 과정에서 git 과 github가 이렇게 강조되는지 

확연이 느낄 수 있었다는 것이다.

 

혼자 코드를 짤때도 버전관리가 얼마나 중요한지 체감한 순간이 많았고

Ctrl+Z를 연타해서 원하는 상태가 될 때까지 추적한 경우도 많았다.

 

버전 관리를 git을 통해 조금 더 유연하게 함으로써

기능을 분류하고, 실험하고, divde & conquer 할 수 있는

기본적인 스탠스를 갖출 수 있었던 것 같다.

 

매번 들어야지 들어야지 했는데

결국 꼭 사용해야할 상황이 오니 배우는 것 같다.

 

프리코스의 마일스톤으로 주어져

지금이라도 학습할 수 있어 참 다행이라는 생각이 들었다.