프론트엔드 데브코스 5기 TIL 4 - git + 그래프

김영현·2023년 9월 23일
0

TIL

목록 보기
4/132

서론

9.23특강 git + 9.25강의 알고리즘의 그래프 정리했음.

git은 당연하게도 회사의 규모에 상관없이 거의 다 사용함.
git은 정확히 로컬환경에서 버전관리를 해주는 도구.
githubgit클라우드환경에 올려주는 도구 => 로컬 환경 백업or업로드 용
알아보자잉~

버전관리

깃이 없다면, 계속해서 복제본을 생성하고 백업본을 만들어야 한다.
또한 협업중 상대방이 작업중인 파일을 고치고 싶다면, 메일같은 기능으로 다시 받아와서 해야한다.
=> 혼자서라면 크게 상관 없을지 몰라도, 다수의 사람이 버전관리를 해야한다면...

  1. a사람의 수정본a 업로드
  2. b사람이 수정본a받아서 수정본b 작성중
  3. a사람은 수정본a를 더 작성해서 다시 업로드
  4. b사람이 수정본b 저장하려보니, 수정본a가 더 수정되어있음. diff를 보고 차이점 구별하여 업로드 가능

키워드 정리

vscode로 작성할때 꿀팁 => commit, push등 단축키로 지정가능.

한 폴더에 하나의 저장소만 유지(한 폴더당 한 번의 git init)
git add 파일명으로 원하는 파일만 버전관리 가능

커밋은 의미있는 변동사항만 올림. 5가지 파일을 수정했다면, 5가지를 묶어서 커밋.
커밋메시지는 최대한 잘 설명하자!

git clone = 원격저장소를 로컬저장소로 끌어옴(.git파일도 생김)
이미 한번 땡겨왔으니, 새로 업데이트 된 파일 끌어오는건 git pull.

협업자는 collaborator추가하면 push가능.(안해도 pullrequest신청해서 허락하면 가능)

stage = git add로 추가한 파일들(곧 커밋할 것임)
modified = 데이터가 수정됨
commited = 데이터가 로컬db에 저장됨

switchcheckout의 하위 기능. 브런치 바꾸는 기능만 있음.
=> checkout이 너무 많은 기능을 내포하고 있었음.

fetch는 원격저장소와 다른지 확인. pull이 끌어오기.

merge는 기준이 되는 브랜치base에 합칠 브랜치compare을 합치는 것
merge하다가 conflict나면 겹친 부분 수동으로 고쳐주면 된다.

오픈소스 기여는 어떻게 할까?
=> fork로 내 원격 저장소에 복제해옴. 자유롭게 내 원격 저장소에 커밋,푸시하고 내 저장소 브랜치와 오픈소스 저장소 브랜치 머지 요청. 직접머지는 피하고 pull reqeust로 보통 한다.

개발 브랜치

feat/기능이름 기능개발 브랜치
dev브랜치 개발중
release 배포용 브랜치

ammend, stash, reset, cherry-pick

git amend = 방금 만든 커밋에 더 추가해서 커밋
git stash = 변경사항 잠시 킵. 아직 커밋은 만들지 않음.=> 다른 브랜치가서 작업하다 돌아오기
reset = 하드리셋은 지금 브랜치를 전의 커밋으로 변경. 믹스드는 기존 브랜치 냅두고 전의 커밋으로 돌아감. 대신 기존 브랜치 커밋 없애줌
cherry-pick = 커밋 하나만 떼서 지금 브랜치에 붙이기

대기업 => 리액트 상태관리, 추상화, 코드깔끔


그래프

비선형 자료구조. one to one이 아닐수도 있음. 연결되어있지 않을 수 있다.
순환되는 부분을 cycle이라 함.
그래프를 표현하는 2가지 방법

  • 인접 행렬
  • 인접 리스트

장단점?

인접 행렬
matrix[i][j]처럼 i=>j간선 유무 파악 O(1)가능. 구현이 조금더 쉽다,
But, matrx[i]에 연결된 모든노드를 찾으려면, 모든 노드의 갯수(V)만큼의 시간이 걸림.

인접리스트
adj[i]노드 i에 연결된 모든 노드를 나타냄. => 따라서 모든 연결된 노드를 찾지 않아도 됨.
But, 노드 i => j연결관계 파악혀려면 모든 노드 갯수만큼 시간이 걸림.

profile
모르는 것을 모른다고 하기

0개의 댓글