[TIL] 20210803

👩‍🏫 [특강] Git & Github @진유림님

• 실무에서 많이 쓰는 Git 명령어
  • amend : 커밋을 수정하고 싶을 때 사용
    • 커밋을 수정하고 force push를 하면 push한 커밋도 변경할 수 있지만 같이 쓰는 원격 브랜치에서는 사용하면 안된다. (혼자 작업하는 브랜치에서 사용해야 함)

      git commit --amend

       
  • stash : 작업 중인 파일이 있는데 다른 브랜치 코드를 급하게 확인/작업해야 할 때 현재 작업 중인 파일들을 stash에 저장했다가 다시 꺼내쓸 수 있다.
    

    git stash -m "message"

     
  • cherry-pick : 특정 커밋만 가져오고 싶을 때 사용
    • (예시) 이미 출시한 코드가 있는 latest 브랜치에 수정해야 할 버그가 있어서 급하게 main 브랜치에서 fix/bug 브랜치를 따서 버그를 고쳐서 main 브랜치에 병합시켜두었다. latest 브랜치에 이를 반영해야 하는데 main에는 다음에 출시할, 아직 공개하면 안되는 기능들의 커밋이 쌓여 있는 상황. 이때 latest 브랜치로 이동해 버그 고친 커밋만 체리픽 해오면 된다.

      git cherry-pick 가져오고싶은커밋아이디​

       
  • reset : 과거의 커밋으로 돌아가고 싶을 때 사용. 협업하는 원격 저장소에서는 절대 사용하면 안된다.
    • --soft : 특정 커밋으로 돌아가기 전까지 작업한 staging area, working directory 작업은 남김 -> reset한 커밋까지의 작업과 reset하기 전까지 한 작업을 합쳐 새로운 버전이나 브랜치를 만들고 싶을 때
    • --mixed(기본값) : 특정 커밋으로 돌아가기 전까지 작업한 working directory 작업은 남김 -> 특정 커밋 이후로 작업한 내용 중 stage에 add 할 내용을 추려야 할 때
    • --hard : 그냥 싹 다 사라짐. 아무 기록도 안 남음
    • reset과 revert의 차이

      git reset --mixed 지우고싶은커밋의이전커밋아이디

 

• 유용한 PR 양식
  • 주요 변경사항
  • 관련 이슈 내용을 알 수 있는 링크나 스크린샷 이미지
  • 시급한 정도
  • 중점적으로 봐주었으면 하는 부분
  • Tip : PR을 읽을 사람을 생각해 코드의 문맥을 이해할 수 있도록 적기, 비주얼적으로 바뀐 부분이 있다면 스크린샷 올리기

 

• commit 메시지 Tip
  • 선 커밋메시지 후 커밋하기
    
    • '카드 연결에서 Redux 제거'와 같은 커밋 메시지를 미리 입력해두고 그에 맞는 코드를 작성해서 커밋하면 깔끔하게 쪼개서 커밋할 수 있다.

 

• 브랜치 전략 Tip
  • feat/기능이름 : 각 개발자가 직접 커밋을 올리는 브랜치
    • 유니크하게 지어야 함
    • main이나 dev에 merge된 다음에는 지워줘야 함
  • main 혹은 dev : feat 브랜치에서 개발 완료된 코드를 합친 브랜치
    • merge만 해야 하고 직접 커밋을 올리면 안 된다
  • release 혹은 latest : 실제 출시할 코드(유저에게 공개할 코드)를 올리는 브랜치
  • hotfix : 빠르게 수정할 내용이 있을 때 사용하는 브랜치
    • 참고하면 좋은 아티클 : 우린 Git-flow를 사용하고 있어요 / [GitHub] Git 브랜치의 종류 및 사용법 (5가지) 

 

• Q&A 중에서
  • 오픈소스는 주로 fork해서 PR을 보내는 방식으로, 팀 협업은 기능 브랜치를 분기해서 직접 커밋하고 PR을 통해 merge하는 방식으로 작업한다.
  • PR description은 너무 길어지면 안 보게 되니 요약해서 올리자. file change가 많으면 자기 코드에 코멘트를 다는 방식으로 설명을 다는 게 좋다.
  • 한 PR 당 file change는 5~7개가 적당하다.
  • 주로 vscode를 이용해 커밋하고 충돌 해결하신다고 함
  • 오픈소스 컨트리뷰션 경험을 꼭 쌓으면 좋다. 개발 씬을 사랑하게 되는 순간이 될 것이다.
  • 회복 탄력성이 좋은 사람, 넘어져도 금방 일어날 수 있는 사람과 함께 일하고 싶다.
  • 기술적으로 개발자는 두 부류로 나눌 수 있다.
    • 테크니컬 중심적 개발자 : 코드 퀄리티 중시 -> 플랫폼, 코어 코드, 라이브러리 개발, 배포 시스템 개선에 적합
    • 비즈니스 중심적 개발자 : 더러운 코드라도 빠르게 짜고 배포해서 사용자 경험을 확인하는 것을 우선시
    • 둘 중 내가 어느 성향인지 파악해서 강점을 개발하는 게 좋다.
  • 빠르게 변화하는 프론트엔드 개발 씬의 속도를 따라가기 위해 노력하는 것
    • 현업 개발자들이랑 얘기하다가 잘 모르는 키워드가 있으면 우선 inbox에 적어둠
    • https://kentcdodds.com/blog, https://ui.dev/ 뉴스레터 구독중
  • 오픈소스 컨트리뷰터가 되고 싶다면 플랫폼 개발에 대한 역량을 개발해야 한다. 여러 케이스를 고려할 수 있어야 하고 개발할 때 어떻게 하면 API를 쓰기 편하게 설계할 수 있을지 등 DX(developer experience)를 고민해보면 좋을듯.
  • 머지방식 3가지(merge, squash, rebase)에 대한 얘기 -> squash와 rebase는 잔커밋을 정리하고 깔끔하게 브랜치를 관리하고 싶을 때 사용하는 것 같다. (git rebase 하는 방법 참고)
  • 이슈 관리 툴은 JIRA와 Github issue, 이슈 하나에 PR 하나를 대응시키는 방식으로 작업(PR에 이슈 번호 적기)

---

🎯 오늘 공부한 것

• [JavaScript] 함수형 프로그래밍
• [JavaScript] 객체지향과 프로토타입
• [❓] stringNumber[i] - "0"의 의미 / JavaScript에서 "3" - "1"은 어떻게 2가 되는가?

---

📚 자료 저장소

• 웹 개발을 위해 꼭 알아야하는 보안 공격
• 정규표현식 실습
  • https://regexone.com/ 
  • https://regexr.com/

---

📮 Q-box

• SWR
• 서스펜스
• git flow

---

🎇 Reflection

• 아직도 github push 할 때마다 ssh agent 비밀번호를 입력하라는 문제를 해결 못했다. 소스트리를 오랜만에 켜봤는데 원격 저장소에 연결하려니까 putty 확장자로 된 ssh key를 요구해서 짜증이 팍 났다. 검색해보니 generator를 다운 받아서 만들어야 하던데... 다들 정말 그렇게까지 해서 쓰는 건지 궁금하다.
• 오늘 특강 참 알찼다. 질문 엄청 많았는데 10시 반이 되도록 유림님께서 답변해주셔서 감동적이었다. 궁금했던 내용들도 많이 해소됐다. 이제는 써보면서 익히는 일만 남은 것 같다.
• 처음 듣는 키워드를 inbox에 넣어 놓으신다고 한 게 인상적이라서 나도 TIL에 Q-box라는 카테고리를 추가했다. 그날 그날마다 오늘 처음 들은 키워드나 들어는 봤지만 아직 잘 모르는 키워드를 적을 예정이다.
• 어제 강의를 너무 후루룩 들은 것 같아서 오늘은 좀 곱씹어가며 강의를 들으려 했다. 그러자 stringNumber[i] - "0", 이 코드 한 줄이 무슨 의미인지 너무 궁금해져서 찾아보다가 강의를 별로 못 들었다. 마저 좀 듣고 자야할 것 같다.
• 프로그래머스 굿즈를 선물해준다는 기쁜 소식을 들었당! 와! 나도 이제 프로그래머스인!
• 유림님이 프로그래머스 데브코스의 가장 큰 장점은 매니저인 것 같다고 했는데 완전 공감이다. 나도 이 과정에서 뭐가 제일 좋았냐고 물어보면 매니저라고 답할 것 같다.
• 티스토리... 코드블럭.... 불렛 리스트 레이아웃.... 대체 무슨 일이야 ㅠ