[TIL] 23.03.30

오늘의 나는 무엇을 잘했을까?

Git을 어느 정도 이해한 것 같다. 사실 Git 굉장히 어렵다. 심오하고 파도 파도 끝이 없을 것 같은 느낌이다. 앞으로 Git을 사용해 보며 조금 더 공부해 봐야겠지만, 이 정도로 이해한 것만으로도 만족할 학습을 했다고 생각한다.

오늘의 나는 무엇을 배웠을까?

Git

1. Git 협업하기

1-1. git fetch

• 리모트 레포지토리의 커밋들을 로컬 레포지토리로 가져옴, merge X
• git fetch 커맨드 사용
• 리모트 레포지토리에서 가져온 브랜치 내용을 merge 하기 전에 점검해야 할 때
• 리모트 레포지토리에 있는 브랜치의 내용과 내가 작성한 코드를 비교해서 잘못된 부분이 없는지 검토해야할 때

1-2. git blame

• 어떤 파일의 특정 코드를 누가 작성했는지 찾아낼 수 있는 방법
• git blame [대상 파일] 커맨드 사용
• git show [commit 아이디] 커맨드와 같이 코드 작성자를 볼 수 있음

1-3. git revert

• 리모트 레포지토리에 이미 push 한 커밋을 수정하고 싶을 때
• 리모트 레포지토리에 커밋이 push 되었다면 로컬에서 reset 후 push가 불가능 (물론 --force 옵션으로 가능하지만,,, 하지 말자)
• 왜? 로컬에 origin에 있는 커밋을 삭제한 채로 origin에 덮어쓰려고 하는 것이니 에러가 날 수 밖에 없음
• git revert [commit 아이디] 커맨드 사용
• reset 과(커밋 폐기) 달리 변경 내용을 취소하는 새 커밋을 생성
• git revert [commit 아이디(포함X)..commit 아이디] : 특정 범위의 여러 커밋을 취소할 때 사용

2. git 심화

2-1. git reset 후 되돌아오기

• git reset 을 하면 지금까지 한 커밋들이 사라진 것일까?
  -> 아니다, HEAD가 가리키는 커밋이 변경되는 것일 뿐
• git reflog : reference log - HEAD가 지금까지 가리켜 온 커밋을 모두 보여줌
• reflog 로 커밋 아이디 확인 후 원하는 커밋으로 다시 reset

2-2. git rebase

• 어떤 브랜치가 다른 브랜치에서 파생되어 나온 경우, 다른 브랜치에서 진행된 커밋을 가져와 base를 재설정하는 것

rebase 전

rebase 후

• merge 와 rebase 의 차이
  1. rebase 는 새로운 커밋을 만들지 않음
  2. rebase 를 사용하면 커밋 히스토리가 시간 순서대로 반영되어 이력관리가 용이함
  3. 두 브랜치가 합쳐진 정보가 커밋 히스토리에 남아야 하는 경우면 merge 를 선택하자
  4. 그냥 단순히 설명해 보았을 때 현재 브랜치를 기준으로 merge는 대상을 끌고 와 새로운 커밋을 만들어 합치는 것, rebase는 분기된 이후의 커밋을 붙이는 것
• 파생된 브랜치를 여러 사람이 활용 & 활발히 커밋이 일어난다면 rebase가 위험할 수 있음
  -> 파생브랜치로 작업하던 작업자의 커밋 히스토리가 변경되기 때문에

merge

rebase

2-3. 작업 내용 임시 저장

• 내가 작업하던 내용을 마무리 하지 않았는데 다른 브랜치로 넘어가고 싶을 때
• git stash 커맨드 사용
• 임시 저장되는 공간 stash
  - Tracked & Modified 상태인 파일과
  - Staging Area에 있는 파일이 임시 저장 된다
• stack : 자료구조의 일종, 드럼통과 같이 먼저 넣은 자료가 가장 나중에 나온다 -> 후입선출, 선입후출
• stash에 임시 저장한 자료 불러올 때는
  git stash apply [stash 아이디]
옵션 --index : staging area에 있던 파일이 있으면 staged 상태 복원
  git stash list 로 stash 아이디 확인

2-4. 잘못된 브랜치에서 작업했을 때는

• git stash 사용해서 임시저장 한 후
• 올바른 브랜치로 넘어가 git stash apply 해주면 해결 가능함

2-5. stash에 쌓인 자료 지우기

• git stash 를 사용하면 자료들이 계속 켜켜이 쌓이고 있는 중
• git stash drop [지울 stash 아이디]
• ++ git stash pop [stash 아이디]
git apply 와 동시에 git stash drop 을 해준다
  즉, 적용과 동시에 stash에서 지워줌

2-6. git cherry-pick

• 필요한 작업이 들어있는 커밋들만 가져와서 현재 브랜치에 추가
• git cherry-pick [commit 아이디]

2-7. 여러 커밋을 하나의 커밋으로 만들기

다음과 같은 상황이 있다고 가정해 보자.
코드에 어떤 함수를 추가하고 커밋을 했다.
그 뒤에 그보다 더 효율적인 함수가 나와 수정 후 커밋을 하게 되었다.
아무리 봐도 이전 커밋은 쓸데가 없는 것 같아 없애고 싶은데 어떻게 할까?

1. git reset 을 활용해 보자
2. --soft --mixed 옵션은 워킹 디렉토리는 변경시키지 않는다
3. 두 옵션을 사용하여 처음 함수를 커밋하기 이전으로 reset 하고 현재 워킹 디렉토리의 코드로 다시 커밋을 해주면, 2개의 커밋이 하나의 커밋으로 만들어진 것과 같이 된다.

2-8. git이 무시하는 파일들

• .gitignore 파일에 적혀 있는 파일들
• 버전 관리의 필요성이 없는 파일들이 무시됨

JS

1. 제어문

1-1. if 문

기본 구조

if (조건부분) {
  동작부분;
} else {
  동작부분;
}

• 조건 부분이 충족 되면 동작 부분을 실행하는 제어문
• 조건 부분이 충족 되지 않으면 else의 동작부분 실행

1-2. else if 문

• if 문을 사용하고 싶은데 필요한 옵션이 2개보다 많을 때

기본 구조

if (조건부분) {
  동작부분;
} else if (조건부분) {
  동작부분;
} ... {
} else {
  동작부분;
}

1-3. switch 문

기본 구조

switch (비교할_값) {
  case 조건값_1:
    동작부분;
    break;
  case 조건값_2:
    동작부분;
    break;
   ...
   default:
   	동작부분;
}

• 비교할 값과 조건값을 비교하여 동작부분을 실행
• case 별로 break 를 써 주어야 해당 케이스 동작부분 실행 후 switch 문을 빠져 나올 수 있음
• default 는 상위의 어떤 조건값과도 일치하지 않을 경우 실행하게 될 코드를 작성해 주는 것, 생략 가능

1-4. 반복문 (loop statement)

for 문 기본 구조

for (초기화 부분; 조건부분; 추가동작 부분;) {
  동작부분;
}

• 초기화 부분 : for 문이 시작하고 한번만 실행
  이 때 선언한 변수는 for 문 안의 로컬변수
  e.g. let i = 0
• 조건부분 : 조건을 충족하면 계속하여 동작부분 실행
  e.g. i <= 10
• 추가동작 부분 : 동작부분을 실행 후 추가로 동작할 부분
  e.g. i++

while 문 기본 구조

while (조건부분) {
  동작부분;
}

• 동작부분 안에 추가동작 부분을 작성해 줘야 함
• global 변수를 조건 비교에 사용하고, 반복문 내부에서도 다루며, 반복문 종료 후에도 해당 변수를 사용해야 할 때 for 문보다 나음

1-5. break와 continue

• break : 현재 실행 중인 반복문을 완전히 종료
• continue : 실행 중인 반복문의 루프를 멈추고 다음 루프 실행
  for 문 : 추가동작 부분 실행
  while 문 : 조건부분 실행

오늘의 나는 어떤 어려움이 있었을까?

앞서 말했다시피 Git 정말 어려웠다... 동작을 이해하는 것이 어려워 팀원들과 30분 가까이 rebase, merge에 대해 이야기 했다. 앞으로 다른 것을 공부할 때도 이러한 어려움이 있을 것이라 예상하는데 포기하지 않고 끈기 있게 알아가는 자세가 중요할 것 같다.

내일의 나는 무엇을 해야할까?

• 프로그래밍과 데이터 in JS 수강
• Weekly Mission 시작
• CS 강의 듣기