자바스크립트에서 얕은 복사(Shallow Copy)와 깊은 복사(Deep Copy)

얕은 복사

- 값이 저장된 메모리의 주소를 복사 한 것으로 참조만 한다고 보면 된다.

얕은 복사를 한 뒤에 변수를 재사용해서 수정하게 되면 원본값도 동시에 변경된다. 

깊은 복사

- 새로운 메모리 공간에 완전히 복사 한 것으로 내부 값이 그대로 복사된다.

값을 복사를 한 것이기 때문에 변수를 재사용하여 수정하여도 원본값에는 영향을 미치지 않는다. 

var, let, const 를 중복 선언 허용, 스코프, 호이스팅 관점에서 서로 비교

호이스팅은 끌어올리다 라는 뜻으로 자바스크립트에서의 선언이 상단으로 끌어 올려지는 것을 의미한다.

함수 호출 부분이 위에, 함수는 아래에 있어도 호이스팅으로 끌어올려서 실행이 된다.

var, let, const 모두 호이스팅이 되는 부분은 동일하다.

var는 선언과 동시에 undefuned로초기화가 되기 때문에, 선언보다 먼저 변수를 사용하더라도 오류가 발생되지 않는다.

let과 const는 호이스팅 특징에 영향을 받지 않기에 값이 초기화 되기 전에 먼저 사용이 불가하다.

호이스팅의 단점은 전역변수와 함수내 동일 변수가 존재하는 경우 예측이 어려워 오류를 발생시킬 가능성이 높아지기 때문에 var는 사용하지 않는 편이 좋다.

또한 스코프는 범위를 의미하는데, var는 전역번위와 함수 내에서도 사용할 수 있다. 

호이스팅이 되면서 자동으로 초기화가 되는 문제가 있다. 

var와 let은 재선언이 가능한 반면 let은 블록 범위내에서 접근이 가능하다.

const 역시 블록 범위 내에서만 접근이 되며, 재선언 및 업데이트가 불가하다. 

Git Flow 브랜치 전략이란?

브랜치 전략 중의 하나로 많은 회사와 팀에서 기본으로 사용하는 경우가 많다.

브랜치 전략은 뭐지?

여러 작업자가 하나의 레파지토리를 사용하는 환경인 경우

레파지토리를 효과적으로 활용하기 위한 규칙을 부여하는 것.

분기, 병합, 생성 등등 각 브랜치에 같은 규칙을 팀원들이 지키면서 진행하는 것.

Git Flow 브랜치 전략의 특징

1. 용도에 맞게 브랜치를 분리한다.

main : 운영에 배포 될 수 있는 코드를 모아둔 브랜치

develop : 다음 버전의 코드를 모아둔 브랜치. 운영환경에 업뎃시 main으로 merge함

feature : 새로운 기능을 위한 브랜치로 develop 브랜치에서 생성 후 완료되면 develop으로 merge

release : 새로운 버전 배포를 위한 브랜치. develop 브랜치에서 생성한다. 배포 전 버그 수정을 위해 사용되며, 배포 준비가 완료되면 main,develop에 모두 merge한다.

hotfix : 빠르게 수정해야 하는 경우 main을 빠르게 변경해야 할 때 사용. main브랜치에서 생성하고, 버그 수정 후 main과 develop에 merge한다. 

1-1. 브랜치 생성 : main > develop > feature1, featue2, release 

1-2. 작업 후 머지 : feature > develop > release > main

2. 배포주기가 잦지 않은, 명확한 릴리즈 기간, 주기적인 버전이 있는 경우 적합

3. release브랜치를 따로 관리함으로 인해, 각 버전별을 동시에 관리 및 유지보수 하기에 편리함

4. 규모가 있는 팀 또는 롤백이나 다양한 버전을 필요호 하는 팀에서 유리

-> 보통 모바일 앱에서 적합하다고 하나, 서비스 운영을 통해 버그관리를 할 때도 사용. 

GitHub Flow는 뭐지?

git flow의 브랜치가 많다보니 자주 사용하지 않는 브랜치의 규칙을 학습해야 하기에

정말 필요한 경우가 아니라면 혼란을 가중시킬 수 있는데, 

이때 대안으로 사용하기 좋은 전략이다. 

1. main브랜치에만 엄격한 규칙이 적용되고, 그 외 브랜치는 규칙이 없음

main : 언제든 배포가 가능한 상태 유지. merge전 엄격한 테스트 필요

그외 브랜치 : main에서 생성하고 나머지 규칙은 없음. 단, 브랜치명, 커밋 메시지는 어떤 것을 담고 있는지 명확하게 작성. 작업 완료 후 main으로 PR작성. PR리뷰 완료 후 main으로 merge시 CI/CD를 거쳐 배포 진행

CI/CD 란? 자동화를 통합하는 앱 제공 방식으로 통합/지속적인 서비스(배포)를 뜻함.
CI : 지속적인 통합. 빌드/ 테스트를 자동화 과정
CD: 지속적인 서비스 제공. CI작업을 끝낸 뒤 실행. 지속적인 서비스(배포)

2. 잦은 배포가 필요할 때

3. 규칙이 간단해서 git에 익숙하지 않은 사람이 있을 때, 작은 프로젝트에 유리.

git merge <new branch>

Fast-forward merge

main과 새로운 브랜치의 형상이 동일한 경우.

main브랜치에서 새로 A라는 브랜치로 작업 후 commit을 하고,

main브랜치는 A브랜치를 분기한 곳에서 따로 commit을 한 게 없다면

merge를 할 때, A브랜치의 내용이 그대로 main브랜치로 흡수되며 추가 commit이 발생되지 않는다.

분기는 되었으나, main 브랜치가 변화가 없었기 때문에 분기점은 동일하기에,

추가로 작업한 신규 브랜치가 main이 되어도 문제가 없다.

Recursive Merge

main과 새로운 브랜치의 형상이 다른 경우

main브랜치와 새로운 브랜치가 각각 commit이 되어 있어 형상이 다를 때,

병합시에는 새로운 commit이 발생된다.

시간순서대로 두개의 브랜치가 합쳐지기 때문에 commit hash에 변함이 없다. 

Squash Merge

git merge --squash <new branch>

새로운 브랜치의 커밋들이 하나로 합쳐져서 병합이 된다.

이전 커밋 내용을 하나로 모아 병합이 되기 때문에

merge log가 깔끔한 장점이 있으나,

새로운 브랜치에서 커밋한 내용이 자세히 보기 힘든 점은 있다. 

Rebase Merge

# new
git rebase <new branch>
git checkout <main branch>
# main
git merge <new branch>

새로운 브랜치에서 commit한 게 main브랜치에 배치되고, 추가 커밋없이 병합이 된다.

이때, 두 브랜치 형상의 동일 여부에 따라 fast-forward 또는 recusive merge가 진행된다.

Git reset [옵션] 이전의 특정 커밋id

사용하면 해당 커밋으로 되돌리는 역할을 합니다.

리셋을 할 때에는 --soft --mixed --hard 세가지 옵션이 있는데요.

어떤 옵션을 선택하느냐에 따라 세가지의 작업영역.

working directory, staging area, repository 에

내가 현재까지 작업한 게 어디까지 남아있게 되는지가 달라지게 됩니다. 

우선 soft로 하게 되면, repository만 이전 커밋과 동일하게 바뀌기 때문에,

나머지 working directory, staging area에는

현재 작업이 그대로 남아있는 상태라고 보시면 됩니다.

mixed는 내 작업 공간인 working directory에만 현재 작업이 남아있고,

staging area와 repository는 이전 커밋과 동일하게 바뀝니다.

hard는 세 작업영역이 모두 이전 커밋과 동일하게 바뀝니다.

새로운 작업이 모두 제거 되기 때문에 커밋한 작업이 불필요할 때 외엔 권장되지 않습니다.