2024-02-16 AI 코딩 TIL

어제의 git을 마저 공부해보도록 하겠습니다.

 

 

로컬에 쌓인 커밋들

 -i 의 의미

 

대화형 (-i 옵션)

• git rebase -i
• git cherry-pick

이 두가지를 이용해서 버그를 발견하고 수정을 위해 사용이 되었던 불필요한 커밋들을 삭제를 시킬 수 있습니다.

 

 

직접 해보자

 

• git rebase -i 명령으로 우리가 바꿀 커밋을 가장 최근 순서로 바꾸어 놓습니다
• git commit --amend 명령으로 커밋 내용을 정정합니다
• 다시 git rebase -i 명령으로 이 전의 커밋 순서대로 되돌려 놓습니다
• 마지막으로, main을 지금 트리가 변경된 부분으로 이동합니다. (편하신 방법으로 하세요)

이용을 하다보니 새로 알게 되는 것들이 많은데 일단 처음 사용법을 깨달은 것은

git rebase는 이전의 커밋을 복사해서 내가 원하는 지점부터 다시 만들어 주는 것이라는 것과

branch는 커밋과는 다른 것이라는 거 일정에 지점표시??? 같은 거라 branch를 옮길 때에는 브랜치 명령어를 

사용하여서 옮겨주어야 한다

 

그리고  git cherry-pick을 사용하는 방법은 지금 내가 어디에 checkout이 되어 있는지가 중요하다.

내가 checkout을 한지점에서부터 원하는 commit들 중에서 필요한 commit만 가져올수 있기 때문이다.

그렇기에 다시 생각을 해보면

 

git rebase -i는 아래에서 시작해서 위로 내가 원하는 것을 집어서 지정된 지점에서 부터 만들어 주는 것이고

git cherry-pick은 내가 만들고 싶은 지점을 먼저 고르고 거기에서 필요한 commit을 가져와서 만들어주는 개념이다.

 

문제풀이를 완료한 나의 작품 해보니 점점 이해하는 게 쉬워지는 것 같다.

 

 

Git 태그

주요 릴리즈나 큰 브랜치 병합(merge)이 있을 때 ( 작업 이력)에서 중요한 지점들에 영구적으로 표시를 할 방법

Git 태그는 커밋들이 추가적으로 생성되어도 절대 움직이지 않는다는 것입니다

 

맨뒤에 위치를 넣어주지 않으면 지금 내가 있는 위치에 만들어준다는 것을 알아두자.

 

 

 

Git Describe

git에는 여러분이 가장 가까운 "닻(태그)"에 비해 상대적으로 어디에 위치해 있는지

*describe(묘사)*해주는 명령어가 있습니다

Git describe는 커밋 히스토리에서 앞 뒤로 여러 커밋을 이동하고 나서

커밋 트리에서 방향감각을 다시 찾는데 도움을 줍니다

 

이런 상황은 git bisect(문제가 되는 커밋을 찾는 명령어라고 간단히 생각하자)를 하고

나서라던가 휴가를 다녀온 동료의 컴퓨터에 앉는 경우가 있습니다

 

 

git rebase를 할 때 

git rebase <checkout 할 위치>  <가져올 위치 >를 입력하면 한 번에 옮겨 줄 수 있다는 것을 알았다.

 

부모를 선택하기

~ 수식처럼 ^ 수식 또한 뒤에 숫자를 추가할 수 있습니다

 

Git은 보통 병합된 커밋에서 "첫" 부모를 따라갑니다.

하지만 ^수식을 숫자와 함께 사용하면 앞의 디폴트 동작대로가 아닌 다른 결과가 나타납니다

 

 

 

main^2를 붙여준다면?

 

 

두 번째 경로에 있는 커밋으로 이동을 하게 된다.

 

 

예상해 보기

 

 

 

직접 위치를 선택을 해도 되지만 길을 따라 올라가는 방법도 있다.

 

 

 

한 번에도 사용이 가능하다는 

 

또한 브랜치를 만들어 주는 것에도 가능하다.

 

 

 

merge를 하면 기존에 있는 것과 내가 원하는 것을 선택하여서 두 개를 잊는 새로운 커밋을 하나 만든다는 것.

 

 

checkout 할 때 새로운 브랜치가 필요하다면 -b를 추가해 주면 브랜치를 바로 추가할 수 있다.

 

---

2시 강의필기

S.A. : 개발을 하기 전에 어떻게 만들 것인가 계획을 하는 과정을 정해두는 것 

오류를 많이 내보고 그것을 해결해보는 경험을 많이 가져 보는 것이 아주 중요하다는 것을 배웠습니다.

---

 

GIT 원격

 

 

 

GIT CLONE

 

 

Git 원격 브랜치

 

 

 

처음 생각으로는 이렇게 될 것이라고 생각했다.

 

 

하지만 실제 결과

 

 

클론으로 생성이 된 메인은 commit을 넣어도 클론으로 생성이된 곳에는 반영이 되지 않지만

 

기존에 있던 main은 클론과 함께 반영이 된다는 것을 볼 수 있다.

 

 

Git Fetch

 

 

git fetch를 사용하므로 써

서버에 있는 커밋을 그대로 복사를 해오고 서버에 있는 main위치에 맞추어 o/main의 위치도 변경을 해준다.

 

 

 

git fetch는 서버에서 자료를 다운로드하여서 반영을 하지만 내가 로컬에서 작업을 하던 것에는

영향을 주지 않지 때문에 변경되거나 하는 걱정은 없다.

 

 

Git Pull

 

 

 

git fetch를 하고 git merge를 하는 것을 한 번에 해주는 것이 git pull이다 

워낙 자주 사용하게 될 기능이라서 따로 만들어 두었나 보다.

 

협동 가장하기

 

 

 

 

 

 

 이걸 만들어 보자

 

오른쪽 C0는 원격 저장소니깐 현제 c3에 있는 상태이며 로컬에서도 C3에 있도록 해야 한다.

 

그러므로 git clone을 해서 복사를 만들고 git faketeamwork로 c3까지 만들어 준 다음에

 

C1에서 commit을 만들고 c3 pull을 하면 될 것이다.

 

 

짜잔 예상에 맞추어 만들 수 있었다.

 

Git Push

 

 

 

엇갈린 작업

 

 

---

 

KPT 회고에 대하여

 

 

ㅇ

 

공동 프로젝트를 만들면서 서로가 좋았던 점과 필요했던 점들을 나누면서 다음작업에 도움이 될 수 있도록 한다.

 

 

---

TIL 특강

 

TIL을 써야 하는 이유???

 

기록   성장   활용

 

이 3가지를 주점으로 사용하기 위해 만든다

 

취업을 위해서 남들보다 더 열심히 하고 잘한다는 것을 증명해야 한다.

 

내가 남들보다 회사에 도움이 될 사람이라는 것을 증명해야 한다 

 

면접관들은 우리들의 모든 것들 보기에는 시간이 부족하다.

 

TIL 작성법에는 정답이 없다. 완벽하지 않아도 되며 누군가를 따라갈 필요가 없다.

---

ROLE

1, 하루에 한 번 일단 작성하기

 

다듬어서 더 잘 써보기

 

꼼꼼히 작성하기

---

TIL 주제 정하기

 

오늘 보고 배우고 느낀 점을 작성

 

1. 강의 내용 정리하기 

- 오늘 배운 것 

- 개념 정리

-개념이 필요한 이유

-사용법

 

2. 개발 단계 정리

-설치 방법

-초기 세팅

-만들어야 할 것들

-등등 준비

 

3. 하루 회고

- 오늘 있었던 일 정리

- 그것에 대한 느낌

- 문제가 있었다면 개선 방안을 정리

 

4. 문제 해결 과정 (권장)

-  발생한 문제 작성

- 문제 코드 저장

- 원인 파악 내용

- 해결 방법

- 느낀 점, 개선방안