이번주 회고, git rebase 가 무엇인가

이번주 미흡했던 점

1) 클라이언트, 서버쪽까지는 금방 끝냈는데 콜봇에 프로세스 적용할 때 방향성을 잘못 잡았다. 생각했던 방향성에 대해 미리 여쭤보고 진행했으면 개발기간을 줄일 수 있었는데 굳이 안해도 되는 작업 방식을 고수해서 개발기간을 길게 가져갔다.

• curl을 사용했던 이유 : 기존에 작업한 프로세스를 활용해야 하지 않을까 라는 생각이었다. 활용해야겠다는 생각은 했으나, 단순히 require_once 만 해서 사용하면 된다는 생각까지는 하지 못했다. 그래서 curl 을 사용해서 api를 호출해야 겠다는 판단을 했고, 그렇게 작업했다. 하지만 서버단에서 같은 서버의 api 를 굳이 호출할 필요는 없다. 그냥 그 프로세스를 require 해서 활용하기만 하면 되는데 짧은 생각이었다.

-> 앞으로 조금 더 적극적인 소통을 할 수 있도록 노력해야 한다. 내가 하려는 방향성에 대해 미리 컨펌을 받자. 컨펌을 받으면 잘못된 생각을 작업 전에 고칠 수 있고, 올바른 방향으로의 개발을 진행 할 수 있다. 또한 모르겠으면 잡고 고민하기보단 바로 여쭤보고 피드백을 받자


2) 과장님께서 방향성을 제시해주셨으나, 그게 아닌 다른 방법으로 진행했다. 내 나름대로의 생각은 그 방법보다 내가 작업한 방법이 금방 끝낼 수 있다고 생각했다. 이미 해당 이슈로 워킹데이를 많이 소모했기 때문에 빠르게 끝내야 한다는 생각에 그렇게 작업했으나, 최적의 방법은 아니었다. 빠르게 끝내는 것도 중요하지만 나중에 추가 공수가 들어가지 않으려면 최적의 방법으로 진행하는 것도 중요하다.

-> 1 과 비슷한 개선사항. 주관을 가지는 것이 잘못된 것은 아니겠으나, 옳고 그름을 좀 더 명확히 판단할 수 있도록 하자.


3) 실서버에 굳이 테스트해보지 않아도 되는 것을 반영했다. 로컬서버에서는 확인이 잘 됐지만, 실서버(콜봇 프로세스)에서 여전히 에러가 발생하는 것을 확인하기 위해 실서버에 업로드를 했다. 이로 인해 서비스가 잠시 마비되는 경험을 했다. 이런 상황을 만들어서는 안된다.

-> 항상 실서버에 접근할 때는 최대한 보수적일 수 있도록 하자. 분기처리를 확실히 하고, 잠시 올렸다 롤백하는건 괜찮겠지 라는 안일한 생각은 버리자. 나에게는 잠시일 수 있으나 같은 부분을 보고 있는 타인에게는 영문 모를 버그일 수도 있다.


4) 게을렀다. 모르는 것에 대해 공부할 수 있었으나, 겉핥기 식으로만 봤고 해당 내용에 대한 개념을 제대로 숙지하지 못했다.
-> 모르는 내용에 대해서는 적극적으로 학습할 수 있도록 하고, 학습에 게으르지 말자. 그리고 뭔가 공부를 할 때 얕게 보지 말고 해당 내용에 대해 깊게 파고들 수 있도록 하자.

---

require과 include의 차이

require : 해당 파일을 찾지 못하거나 오류가 발생하면 fatal error를 발생시키고 스크립트 실행을 중단한다. 포함하려는 파일이 해당 프로세스(애플리케이션)실행에 필수적일 때 사용한다. 즉 좀 더 strict 한 방식이다.

include : 파일을 찾지 못하거나 오류가 발생하면 경고를 발생시키지만, 스크립트의 실행은 계속된다. 포함하는 파일이 필수적이지 않을때 사용한다. 즉 flexible 하기 때문에 사용을 지양하는 것이 좋다.

그렇다면 once는 뭐지?

• 동일한 파일이 여러 번 포함되지 않도록 한다. 동일한 파일이 여러 번 포함되어 발생할 수 있는 중복 정의 오류를 방지할 수 있다.

---

git rebase 는 무엇인가

• 브랜치를 병합하는 데 사용하는 명령어. 브랜치의 기반을 다른 커밋으로 이동시켜서 히스토리를 재작성하는 기능으로, 커밋 히스토리를 깔끔하게 유지할 수 있다. 이를 활용하면 프로젝트의 커밋 히스토리를 명확하고 가독성있게 유지할 수 있다.
  
  
  ex) A브랜치에서 B브랜치를 파서 작업을 하는 경우에, A브랜치에 타인이 커밋을 추가하는 경우
  
  이 때 merge를 시도하면 conflict이 나게 될 것이다.
  A브랜치에서는 추가 커밋이 올라간 상황인데 B브랜치에서는 추가된 커밋이 없이 B브랜치에서 쌓은 커밋만 존재하기 때문이다.
  이때 사용할 수 있는 것이 rebase.
  rebase 하면 A브랜치의 Head에 맞춰 B브랜치에서 쌓은 커밋들이 쌓이게 된다.

쉽게 생각하면 현재 브랜치는 rebase하려는 브랜치의 최상단 라인으로 맞춰진다

만약 feature 브랜치가 main 브랜치로부터 생성이 된 이후, main 브랜치에 변경사항이 추가된 경우에 feature 브랜치를 main 브랜치의 최신상태로 업데이트를 진행해야 할 때

git checkout feature
git rebase main

이렇게 하면 feature 브랜치는 main 브랜치의 최신 커밋(Head)로 이동된다. 여러 라인으로 작업되다가 하나의 라인으로 rebase 된다고 이해하면 된다.

• merge 와 rebase 의 차이점
  merge 나 rebase 는 브랜치간 내용을 합치기 위한 방법이고, 두 방법의 최종 내용 또한 같지만 히스토리의 차이가 있다.

  • merge : merge 는 브랜치를 통합하는 것이다. 두 브랜치를 병합할 때 새로운 병합 커밋을 생성한다.
    다른 브랜치에서 여태까지의 커밋 내용을 하나의 merge commit으로 합치기 때문에 히스토리를 추적하기에 어려움이 있어 히스토리가 복잡해질 수 있다.
  • rebase : 병합 커밋 없이 히스토리를 재작성하기 때문에 깔끔하고 선형적인 히스토리를 유지할 수 있다. 즉 과거 커밋 기록을 보기 쉽다.
    rebase 를 잘 활용하면 프로젝트의 커밋 히스토리를 명확하고 이해하기 쉽게 관리할 수 있다.
    다만 히스토리를 재작성하기 때문에 공유된 브랜치(main 등과 같은)에서는 rebase 하지 않아야 한다. 공유된 브랜치에서 rebase 할 시 히스토리가 바뀌면서 충돌이 발생할 수 있기 때문이다.

• rebase 주의 사항
  rebase 중 충돌이 발생시
  1) 충돌 파일을 수동으로 수정하고 git add 시켜서 수정 내용을 추가시킨다.
  2) git rebase --continue 명령어로 rebase를 계속해서 진행한다.

  충돌 해결이 복잡하거나 rebase를 중단하고 싶을 시 git rebase --abort 명령어를 사용해 rebase를 중단할 수 있다.