[04.11/week05]TIL

물론이야! 마크다운 구조는 유지하면서, 전체적으로 가독성과 흐름을 정돈해봤어.

오늘 한줄 요약

pointer....

새롭게 배우게 된 것

• C언어 기초
• 컴퓨터 HW의 흐름
• Git Rebase로 Conflict 해결

C언어 기초 (Switch, Array, Pointer)

▸ Switch 문

JS에서도 종종 사용했던 구조라 쉽게 이해했다.

if (x == 1) { ... }
else if (x == 2) { ... }
else if (x == 3) { ... }
else { ... }

switch (x) {
	case 1: ... break;
	case 2: ... break;
    case 3: ... break;
    default: ...
}

• if-else는 조건을 순차적으로 검사하는 반면,
  switch는 점프 테이블을 사용해 바로 해당 case로 이동한다.
• 단, case 문은 컴파일 시점에 정적인 값이어야 하므로 변수는 쓸 수 없다.

▸ Array

배열은 같은 타입의 변수를 연속된 메모리 공간에 저장하는 방식이다.

int arr[] = {1, 2, 3, 4};        // 크기 4
int arr2[] = {1, 2, 3, 4, 5, 6}; // 크기 6

배열의 크기를 직접 지정할 수도 있지만, 위처럼 컴파일러에게 맡길 수도 있다.

▸ Pointer

포인터는 메모리 주소를 저장하는 변수다.
포인터의 자료형을 함께 쓰는 이유는, 해당 주소에서 몇 바이트를 읽을지 알려주기 위함이다.

• & 연산자: 주소값을 얻을 때 사용
• * 연산자: 주소에 저장된 실제 값을 참조할 때 사용

즉, 아래 개념이 성립한다.

GitHub Rebase로 Conflict 해결

* 660d259 folder
* b69bbb7 folder create
| * 4ccb6b1 (main) 4일차
|/
* eeb95ed Merge pull request #1 from ...
* d129f7b .
* f414185 clone git
* 6d73217 Initial commit

이건 내가 직접 겪은 건 아니고, 오전에 진행한 Git 강의 중에 누군가 충돌이 났다고 해서 도와주게 된 상황.

사실 개쫄렸지만... 해결은 했다!

▸ 문제 원인

• main 브랜치의 최신 커밋(4일차)을 반영하지 않은 채 feature 브랜치에서 커밋 2개를 진행
• 디렉토리 구조 변경 및 파일 삭제·생성 등으로 인해
  main에는 있는 파일이 feature에서는 untracked 상태가 되어 충돌 발생

▸ GitHub Web Editor도 GG

• 이전엔 단순한 파일 수정 충돌이라 GitHub에서 직접 해결 가능했지만,
  이번엔 구조 자체가 꼬여서 Web Editor에서 아래 메시지 출력됨:

"This file is too complex to resolve in the web editor."

▸ 해결 과정 요약

1. git checkout main
2. git pull origin main (로컬 main 최신화)
3. git checkout feature
4. git rebase main (main을 기준으로 rebase 시도)
5. 구조 변경된 파일을 추적하도록 git add -A
6. git rebase --continue
7. 충돌 해결된 feature 브랜치를 강제 푸시 git push -f origin feature

* a1b2c3d (HEAD -> main) folder
* a0a0a0a folder create
* 4ccb6b1 4일차
* eeb95ed Merge pull request #1 from ...
* d129f7b .
* f414185 clone git
* 6d73217 Initial commit

결과적으로 PR도 깔끔히 머지되었고,Log도 깔끔하게 일직선으로 예쁘게 나왔다.
도와드린 분께 감사하단 말도 들어서 괜히 뿌듯했다.

공부하면서 아쉬운 점

포인터... 아직 어렵다.
머리로 이해는 되는데 직접 써보려면 헷갈린다.
그래도 그림 그려가면서 계속 연습하면 괜찮아질 것 같다.