시간과 공간 그리고 진실의 방

Rebase 하기

Git에서 한 브랜치에서 다른 브랜치로 합치는 방법으로는 두 가지가 있다. 하나는 Merge 이고 다른 하나는 Rebase 다. 이 절에서는 Rebase가 무엇인지, 어떻게 사용하는지, 좋은 점은 뭐고, 어떤 상황에서 사용하고 어떤 상황에서 사용하지 말아야 하는지 알아 본다.

Rebase 의 기초

앞의 Merge 의 기초 절에서 살펴본 예제로 다시 돌아가 보자. 두 개의 나누어진 브랜치의 모습을 볼 수 있다.

Figure 35. 두 개의 브랜치로 나누어진 커밋 히스토리

이 두 브랜치를 합치는 가장 쉬운 방법은 앞에서 살펴본 대로 merge 명령을 사용하는 것이다. 두 브랜치의 마지막 커밋 두 개(C3, C4)와 공통 조상(C2)을 사용하는 3-way Merge로 새로운 커밋을 만들어 낸다.

Figure 36. 나뉜 브랜치를 Merge 하기

비슷한 결과를 만드는 다른 방식으로, C3 에서 변경된 사항을 Patch로 만들고 이를 다시 C4 에 적용시키는 방법이 있다. Git에서는 이런 방식을 Rebase 라고 한다. rebase 명령으로 한 브랜치에서 변경된 사항을 다른 브랜치에 적용할 수 있다.

위의 예제는 아래와 같은 명령으로 Rebase 한다.

$ git checkout experiment $ git rebase master First, rewinding head to replay your work on top of it... Applying: added staged command

실제로 일어나는 일을 설명하자면 일단 두 브랜치가 나뉘기 전인 공통 커밋으로 이동하고 나서 그 커밋부터 지금 Checkout 한 브랜치가 가리키는 커밋까지 diff를 차례로 만들어 어딘가에 임시로 저장해 놓는다. Rebase 할 브랜치(역주 - experiment)가 합칠 브랜치(역주 - master)가 가리키는 커밋을 가리키게 하고 아까 저장해 놓았던 변경사항을 차례대로 적용한다.

Figure 37. `C4`의 변경사항을 `C3`에 적용하는 Rebase 과정

그리고 나서 master 브랜치를 Fast-forward 시킨다.

$ git checkout master $ git merge experiment

Figure 38. master 브랜치를 Fast-forward시키기

C4' 로 표시된 커밋에서의 내용은 Merge 예제에서 살펴본 C5 커밋에서의 내용과 같을 것이다. Merge 이든 Rebase 든 둘 다 합치는 관점에서는 서로 다를 게 없다. 하지만, Rebase가 좀 더 깨끗한 히스토리를 만든다. Rebase 한 브랜치의 Log를 살펴보면 히스토리가 선형이다. 일을 병렬로 동시에 진행해도 Rebase 하고 나면 모든 작업이 차례대로 수행된 것처럼 보인다.

Rebase는 보통 리모트 브랜치에 커밋을 깔끔하게 적용하고 싶을 때 사용한다. 아마 이렇게 Rebase 하는 리모트 브랜치는 직접 관리하는 것이 아니라 그냥 참여하는 브랜치일 것이다. 메인 프로젝트에 Patch를 보낼 준비가 되면 하는 것이 Rebase 니까 브랜치에서 하던 일을 완전히 마치고 origin/master 로 Rebase 한다. 이렇게 Rebase 하고 나면 프로젝트 관리자는 어떠한 통합작업도 필요 없다. 그냥 master 브랜치를 Fast-forward 시키면 된다.

Rebase를 하든지, Merge를 하든지 최종 결과물은 같고 커밋 히스토리만 다르다는 것이 중요하다. Rebase 의 경우는 브랜치의 변경사항을 순서대로 다른 브랜치에 적용하면서 합치고 Merge 의 경우는 두 브랜치의 최종결과만을 가지고 합친다.

Rebase 활용

Rebase는 단순히 브랜치를 합치는 것만 아니라 다른 용도로도 사용할 수 있다. 다른 토픽 브랜치에서 갈라져 나온 토픽 브랜치 같은 히스토리가 있다고 하자. server 브랜치를 만들어서 서버 기능을 추가하고 그 브랜치에서 다시 client 브랜치를 만들어 클라이언트 기능을 추가한다. 마지막으로 server 브랜치로 돌아가서 몇 가지 기능을 더 추가한다.

Figure 39. 다른 토픽 브랜치에서 갈라져 나온 토픽 브랜치

이때 테스트가 덜 된 server 브랜치는 그대로 두고 client 브랜치만 master 로 합치려는 상황을 생각해보자. server 와는 아무 관련이 없는 client 커밋은 C8, C9 이다. 이 두 커밋을 master 브랜치에 적용하기 위해서 --onto 옵션을 사용하여 아래와 같은 명령을 실행한다:

$ git rebase --onto master server client

이 명령은 master 브랜치부터 server 브랜치와 client 브랜치의 공통 조상까지의 커밋을 client 브랜치에서 없애고 싶을 때 사용한다. client 브랜치에서만 변경된 패치를 만들어 master 브랜치에서 client 브랜치를 기반으로 새로 만들어 적용한다. 조금 복잡하긴 해도 꽤 쓸모 있다.

Figure 40. 다른 토픽 브랜치에서 갈라져 나온 토픽 브랜치를 Rebase 하기

이제 master 브랜치로 돌아가서 Fast-forward 시킬 수 있다(master 브랜치를 client 브랜치 위치로 진행 시키기 참고).

$ git checkout master $ git merge client

Figure 41. master 브랜치를 client 브랜치 위치로 진행 시키기

server 브랜치의 일이 다 끝나면 git rebase <basebranch> <topicbranch> 라는 명령으로 Checkout 하지 않고 바로 server 브랜치를 master 브랜치로 Rebase 할 수 있다. 이 명령은 토픽(server) 브랜치를 Checkout 하고 베이스(master) 브랜치에 Rebase 한다.

$ git rebase master server

server 브랜치의 수정사항을 master 브랜치에 적용했다. 그 결과는 master 브랜치에 server 브랜치의 수정 사항을 적용 같다.

Figure 42. master 브랜치에 server 브랜치의 수정 사항을 적용

그리고 나서 master 브랜치를 Fast-forward 시킨다.

$ git checkout master $ git merge server

모든 것이 master 브랜치에 통합됐기 때문에 더 필요하지 않다면 client 나 server 브랜치는 삭제해도 된다. 브랜치를 삭제해도 커밋 히스토리는 최종 커밋 히스토리 같이 여전히 남아 있다.

$ git branch -d client $ git branch -d server

Figure 43. 최종 커밋 히스토리

Rebase 의 위험성

Rebase가 장점이 많은 기능이지만 단점이 없는 것은 아니니 조심해야 한다. 그 주의사항은 아래 한 문장으로 표현할 수 있다.

이미 공개 저장소에 Push 한 커밋을 Rebase 하지 마라

이 지침만 지키면 Rebase를 하는 데 문제 될 게 없다. 하지만, 이 주의사항을 지키지 않으면 사람들에게 욕을 먹을 것이다.

Rebase는 기존의 커밋을 그대로 사용하는 것이 아니라 내용은 같지만 다른 커밋을 새로 만든다. 새 커밋을 서버에 Push 하고 동료 중 누군가가 그 커밋을 Pull 해서 작업을 한다고 하자. 그런데 그 커밋을 git rebase 로 바꿔서 Push 해버리면 동료가 다시 Push 했을 때 동료는 다시 Merge 해야 한다. 그리고 동료가 다시 Merge 한 내용을 Pull 하면 내 코드는 정말 엉망이 된다.

이미 공개 저장소에 Push 한 커밋을 Rebase 하면 어떤 결과가 초래되는지 예제를 통해 알아보자. 중앙 저장소에서 Clone 하고 일부 수정을 하면 커밋 히스토리는 아래와 같아 진다.

Figure 44. 저장소를 Clone 하고 일부 수정함

이제 팀원 중 누군가 커밋, Merge 하고 나서 서버에 Push 한다. 이 리모트 브랜치를 Fetch, Merge 하면 히스토리는 아래와 같이 된다.

Figure 45. Fetch 한 후 Merge 함

그런데 Push 했던 팀원은 Merge 한 일을 되돌리고 다시 Rebase 한다. 서버의 히스토리를 새로 덮어씌우려면 git push --force 명령을 사용해야 한다. 이후에 저장소에서 Fetch 하고 나면 아래 그림과 같은 상태가 된다.

Figure 46. 한 팀원이 다른 팀원이 의존하는 커밋을 없애고 Rebase 한 커밋을 다시 Push 함

자 이렇게 되면 짬뽕이 된다. git pull 로 서버의 내용을 가져와서 Merge 하면 같은 내용의 수정사항을 포함한 Merge 커밋이 아래와 같이 만들어진다.

Figure 47. 같은 Merge를 다시 한다

git log 로 히스토리를 확인해보면 저자, 커밋 날짜, 메시지가 같은 커밋이 두 개 있다(C4, C4'). 이렇게 되면 혼란스럽다. 게다가 이 히스토리를 서버에 Push 하면 같은 커밋이 두 개 있기 때문에 다른 사람들도 혼란스러워한다. `C4`와 `C6`는 포함되지 말았어야 할 커밋이다. 애초에 서버로 데이터를 보내기 전에 Rebase로 커밋을 정리했어야 했다.

Rebase 한 것을 다시 Rebase 하기

만약 이런 상황에 빠질 때 유용한 Git 기능이 하나 있다. 어떤 팀원이 강제로 내가 한일을 덮어썼다고 하자. 그러면 내가 했던 일이 무엇이고 덮어쓴 내용이 무엇인지 알아내야 한다.

커밋 SHA 체크섬 외에도 Git은 커밋에 Patch 할 내용으로 SHA-1 체크섬을 한번 더 구한다. 이 값은 “patch-id” 라고 한다.

덮어쓴 커밋을 받아서 그 커밋을 기준으로 Rebase 할 때 Git은 원래 누가 작성한 코드인지 잘 찾아 낸다. 그래서 Patch가 원래대로 잘 적용된다.

예를 들어 앞서 살펴본 예제를 보면 한 팀원이 다른 팀원이 의존하는 커밋을 없애고 Rebase 한 커밋을 다시 Push 함 상황에서 Merge 하는 대신 git rebase teamone/master 명령을 실행하면 Git은 아래와 같은 작업을 한다.

• 현재 브랜치에만 포함된 커밋을 찾는다. (C2, C3, C4, C6, C7)

• Merge 커밋을 가려낸다. (C2, C3, C4)

• 이 중 덮어쓰지 않은 커밋들만 골라낸다. (C2, C3. C4는 C4’와 동일한 Patch다)

• 남은 커밋들만 다시 teamone/master 바탕으로 커밋을 쌓는다.

결과를 확인해보면 같은 Merge를 다시 한다 같은 결과 대신 제대로 정리된 강제로 덮어쓴 브랜치에 Rebase 하기 같은 결과를 얻을 수 있다.

Figure 48. 강제로 덮어쓴 브랜치에 Rebase 하기

동료가 생성했던 C4와 C4' 커밋 내용이 완전히 같을 때만 이렇게 동작된다. 커밋 내용이 아예 다르거나 비슷하다면 커밋이 두 개 생긴다(같은 내용이 두 번 커밋될 수 있기 때문에 깔끔하지 않다).

git pull 명령을 실행할 때 옵션을 붙여서 git pull --rebase 로 Rebase 할 수도 있다. 물론 git fetch 와 git rebase teamone/master 이 두 명령을 직접 순서대로 실행해도 된다.

git pull 명령을 실행할 때 기본적으로 --rebase 옵션이 적용되도록 pull.rebase 설정을 추가할 수 있다. git config --global pull.rebase true 명령으로 추가한다.

Push 하기 전에 정리하려고 Rebase 하는 것은 괜찮다. 또 절대 공개하지 않고 혼자 Rebase 하는 경우도 괜찮다. 하지만, 이미 공개하여 사람들이 사용하는 커밋을 Rebase 하면 틀림없이 문제가 생긴다.

나중에 후회하지 말고 git pull --rebase 로 문제를 미리 방지할 수 있다는 것을 같이 작업하는 동료와 모두 함께 공유하기 바란다.

Rebase vs. Merge

Merge가 뭔지, Rebase가 뭔지 여러 예제를 통해 간단히 살펴보았다. 지금쯤 이런 의문이 들 거로 생각한다. 둘 중 무엇을 쓰는 게 좋지? 이 질문에 대한 답을 찾기 전에 히스토리의 의미에 대해서 잠깐 다시 생각해보자.

히스토리를 보는 관점 중에 하나는 작업한 내용의 기록으로 보는 것이 있다. 작업 내용을 기록한 문서이고, 각 기록은 각각 의미를 가지며, 변경할 수 없다. 이런 관점에서 커밋 히스토리를 변경한다는 것은 역사를 부정하는 꼴이 된다. 언제 무슨 일이 있었는지 기록에 대해 거짓말 을 하게 되는 것이다. 이렇게 했을 때 지저분하게 수많은 Merge 커밋이 히스토리에 남게 되면 문제가 없을까? 역사는 후세를 위해 기록하고 보존해야 한다.

히스토리를 프로젝트가 어떻게 진행되었나에 대한 이야기로도 볼 수 있다. 소프트웨어를 주의 깊게 편집하는 방법에 메뉴얼이나 세세한 작업내용을 초벌부터 공개하고 싶지 않을 수 있다. 나중에 다른 사람에게 들려주기 좋도록 Rebase 나 filter-branch 같은 도구로 프로젝트의 진행 이야기를 다듬으면 좋다.

Merge 나 Rebase 중 무엇이 나으냐는 질문은 다시 생각해봐도 답이 그리 간단치 않다. Git은 매우 강력한 도구고 기능이 많아서 히스토리를 잘 쌓을 수 있지만, 모든 팀과 모든 이가 처한 상황은 모두 다르다. 예제를 통해 Merge 나 Rebase가 무엇이고 어떤 의미인지 배웠다. 이 둘을 어떻게 쓸지는 각자의 상황과 각자의 판단에 달렸다.

일반적인 해답을 굳이 드리자면 로컬 브랜치에서 작업할 때는 히스토리를 정리하기 위해서 Rebase 할 수도 있지만, 리모트 등 어딘가에 Push로 내보낸 커밋에 대해서는 절대 Rebase 하지 말아야 한다

지금까지 Git 을 이용하여 로컬의 작업내용을 원격의 repository 에 보관하여 작업하는 방법을 알아보았다.

그런데 만약 멀티 유저환경이라면 그래서 누군가가 내가 마지막으로 보관했던 커밋이후에 신규커밋을 추가했다면 내 로컬 커밋들에 그 신규 커밋을 어떻게 반영해야할까?

이런 상황에 사용할 수 있는 명령이 git fetch 이다. fetch 명령은 타겟으로 지정한 리포지토리의 변경내역을 로컬로 가지고 와서 그 내역들을 HEAD라는 특수한 branch에 담는다.

이 정보를 이용해서 로컬의 작업내역들과 비교할 수 있고 만약 누군가가 생성한 신규 커밋들이 로컬에서 작업한 부분과 중복되는 부분이 있다면 이에 대한 정보를 제공해준다.

아래 예제를 참조

1. 현재 log 확인

* git ll 은 git log --oneline 을 이용한 alias 이다. 이와 관련한 정보는 'Git 간단한 사용법 - alias' 참조할 것.

[~/itips_2] (master) $ git ll
2afe186 26 minutes ago I Tips Merge branch 'master' of /home/itips/repo (HEAD -> master, origin/master, origin/HEAD) I Tips
f234ec6 27 minutes ago I Tips Add second.txt file I Tips
d7addb2 29 minutes ago I Tips Add new file I Tips
9875c2a 5 days ago I Tips I will make a commit only with first.txt I Tips

현재 HEAD-> master, origin/master, origin/HEAD 모두 commit 2afe186 을 가리키고 있다.

2. fetch를 한후 다시 로그를 확인해 보면 아래와 같다.

[~/itips_2] (master) $ git fetch
remote: Counting objects: 7, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 7 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (7/7), done.
From /home/itips/repo
   2afe186..d7c0da0  master     -> origin/master
[~/itips_2] (master) $ git ll
2afe186 26 minutes ago I Tips Merge branch 'master' of /home/itips/repo (HEAD -> master) I Tips
f234ec6 27 minutes ago I Tips Add second.txt file I Tips
d7addb2 29 minutes ago I Tips Add new file I Tips
9875c2a 5 days ago I Tips I will make a commit only with first.txt I Tips

로컬에 있는 가장 최근 커밋인 2afe186 은 변경없이 그대로 있지만 그 커밋을 가리키고 있던 origin/master 와 origin/HEAD 가 사라지고 HEAD-> master 만 남아 있다. 

fetch 실행 후 메세지에서 '2afe186..d7c0da0 master  -> origin/master' 이부분은 로컬의 마스터 브렌치에서 리포지토리 origin 에 있는 master 브렌치 사이에 커밋들이 있음을 알려주는 것이다. 

3. 이제 merge 를 실행

[~/itips_2] (master) $ git merge origin/master
Updating 2afe186..d7c0da0
Fast-forward
 second.txt | 1 +
 third.txt  | 1 +
 2 files changed, 2 insertions(+)
 create mode 100644 third.txt

커밋 2afe186에서 커밋 d7c0da0 로 업데이트가 진행 되었음을 보여준다.

4. 다시 커밋로그를 확인

[~/itips_2] (master) $ git ll
d7c0da0 2 minutes ago I Tips Merge remote-tracking branch 'origin/master' (HEAD -> master, origin/master, origin/HEAD) I Tips
8c07aa4 25 minutes ago I Tips Add third.txt I Tips
2afe186 27 minutes ago I Tips Merge branch 'master' of /home/itips/repo I Tips
f234ec6 28 minutes ago I Tips Add second.txt file I Tips
d7addb2 30 minutes ago I Tips Add new file I Tips
9875c2a 5 days ago I Tips I will make a commit only with first.txt I Tips

커밋 2afe186 이후로 2개의 커밋이 추가되었고 HEAD-> master, origin/master, origin/HEAD 가 예전처럼 가장 최근의 커밋을 가리키고 있다. 

정리하면, fetch 가 진행되기 전까지 로컬작업 환경은 리포지토리의 상황을 알지 못하며 fetch 를 통해 repository 의 정보를 가져오며 이때 로컬파일들에 어떠한 변경도 만들지 않는다. 

이렇게 업데이트 된 정보를 이용해서 merge, log 등의 작업을 진행한다. 따라서, 특히 리포지토리에 push 등의 작업을 할 경우 내 로컬 작업 환경에 리포지토리의 커밋내역을 정확히 가지고 있지 않으면 정상적으로 push 가 되지 않고 에러가 난다.

그래서 일반적(충돌- conflict 이 일어나지 않는 경우)으로 push 할 때 작업수행은 아래와 같이 진행한다. 

git add . && git commit -m 'message' && git fetch origin master && git merge origin/master && git push origin master

------------------------------------------------------------------------------------------------------------------------------

노마드코더의 강의를 다시 들으려고 하면서 repository를 새로 만들게 되었다.
공부한 내용을 올리려고 하고 최초 커밋을 했는데
yarn.lock 파일에 보안취약문제가 있다고 alert를 받았다.

serialize-javascript 파일을 수정하는 작업을 진행했다. version을 2.1.1로 수정하고 다시 git에 커밋/푸쉬를 진행했는데도 alert가 사라지지 않았다.
결국, 저 위에 초록색 버튼 Create automated security update 버튼을 누르니 해당 alert가 사라졌다.
아마도 자동으로 github 에서 문제를 해결해주는 무언가를 내가 켰겠지..

2020. 1.28 내용 수정

2020년 1월 28일 !
새로운 공부내용을 repository에 올려서 넣으니 또 똑같은 문제가 발생했다!!
이번에는 serialize-javascript 를 직접 업그레이드 해보기로했다.
아래 사이트를 참고해서,
2.1.1 버전이었던 걸 업그레이드해서 2.1.2로 업그레이드 했고 !
해당 alert가 바로 사라지진 않았지만, 깃에서 준 조언대로 내가 행했기때문에
이게 더 정확한 방법같다

npm i serialize-javascript

참고사이트 : https://www.npmjs.com/package/serialize-javascript

automated security update 란?

repository에 의존성 관리의 취약점에 대한 alert를 받게 됬을 때, 해당 repository에 security update를 able로 해두면, Github에서 자동으로 의존성 취약점을 가진 파일들을 업그레이드하는 PR을 repository에 생성한다. 만약 내가 선택해서 의존성 파일을 업그레이드하고, PR을 생성하려면 해당 기능을 disable하게 만들면 된다. Automated security request가 오면 빠르게 리뷰를 하고, merge를 해야한다.

이 문제를 해결하려고 하다가 serialize가 무엇인가에 대해서 문득 궁금해졌다.

serialize란 무엇인가?

서로 다른 언어나 형태를 가지고 있는 것들을 서로 이해할 수 있도록 형태를 잡아서 묶어주는 것을 Serialization이라고 함.(예를 들어, DB와 프로그래밍 언어형태가 다른데 서로 알아들을 수 있는 형태로 묶어주는 것을 말함)

• JS에서 JSON.stringify() 함수를 호출하는 것과 비슷한 역할을 함(객체를 json 으로 만드는 것과 비슷)
• serialization은 생각보다 많이 쓰인다.

위의 방법 외에 다른 해결방법을 찾다가, .gitignore에 yarn.lock 파일을 넣으면 해결이 된다는 글을 찾게 되었고, gitignore과 yarn.lock에 대해서 알아보았다.
결론을 말하자면 yarn.lock 파일은 gitignore에 넣지 않고, git에서 관리할 수 있게끔 commit을 하는 것이 좋다.

.gitignore 파일이란?

git 버전관리에서 제외(github에 업로드하지않을 파일 목록)할 파일 목록을 지정하는 파일
.gitignore이 파일명이며, 해당 파일 목록에 들어가는 대표적인 것은 node_modules 가 있음.
node_modules 정보는 이미 package.json에 명시가 되어있기때문에
언제든 쉽게 모듈을 설치할 수 있어서 github에 굳이 올리지않아도 되어, gitignore 파일에 넣는다.
그리고 node_modules는 크기가 크다! 그래서 git에 안올려도되면 안올리는 게 좋음!

.gitignore 파일 설정법

리액트 CRA를 하고 git을 연결하면 자연스럽게 .gitignore 파일이 생김
.gitignore 파일안에 무시할 대상 경로만 넣어주면 됨!
요렇게 파일 안에다가 경로표시하고, 이름을 적으면 된다!

yarn이란?

자바스크립트 패키지 매니저로서, npm과 가장 많이 쓰이는 manager.
yarn을 사용해서 프로젝트에 새로운 패키지를 설치하면, yarn.lock이 자동으로 생성된다.

Yarn.lock이란?

Yarn 패키지 매니저의 패키지 잠금파일!

잠금파일이 왜 필요할까?

설치가 필요한 패키지들이 package.json 파일에 등록되어있으면, 해당 파일을 통해 모두가 npm이나 yarn 설치 명령어로 모든 패키지를 버전에 맞게 설치할 수 있음.
그러나, 설치하는 시점에 따라 패키지버전이 달라짐
(왜? package.json에는 특정버전으로 지정되어있는 것이 아니라, SemVer 규칙에 따라 범위로 지정되어있음)
서로 다른 패키지를 설치해서 사용하면 개발자 간의 혼선이 생길 수 있기때문에, 패키지 잠금파일이 생김!
<yarn.lock>

# THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY. # yarn lockfile v1 "@babel/code-frame@7.5.5", "@babel/code-frame@^7.0.0", "@babel/code-frame@^7.5.5": version "7.5.5" resolved "https://registry.yarnpkg.com/@babel/code-frame/-/code-frame-7.5.5.tgz#bc0782f6d69f7b7d49531219699b988f669a8f9d" integrity sha512-27d4lZoomVyo51VegxI20xZPuSHusqbQag/ztrBC7wegWoQ1nLREPVSKSW8byhTlzTKyNE4ifaTA6lCp7JjpFw== dependencies: "@babel/highlight" "^7.0.0" "@babel/core@7.7.4", "@babel/core@^7.1.0", "@babel/core@^7.4.5": version "7.7.4" resolved "https://registry.yarnpkg.com/@babel/core/-/core-7.7.4.tgz#37e864532200cb6b50ee9a4045f5f817840166ab" integrity sha512-+bYbx56j4nYBmpsWtnPUsKW3NdnYxbqyfrP2w9wILBuHzdfIKz9prieZK0DFPyIzkjYVUe4QkusGL07r5pXznQ== dependencies: "@babel/code-frame" "^7.5.5" "@babel/generator" "^7.7.4" "@babel/helpers" "^7.7.4" "@babel/parser" "^7.7.4" "@babel/template" "^7.7.4" "@babel/traverse" "^7.7.4" "@babel/types" "^7.7.4" //일부만 발췌

• 참고 : NPM(Node Packaged Mananger의 약자)
  NPM을 실행하면, package-lock.json이 생성됨

<package-lock.json>

{ "name": "movie-app-2019", "version": "0.1.0", "lockfileVersion": 1, "requires": true, "dependencies": { "@babel/code-frame": { "version": "7.5.5", "resolved": "https://registry.npmjs.org/@babel/code-frame/-/code-frame-7.5.5.tgz", "integrity": "sha512-27d4lZoomVyo51VegxI20xZPuSHusqbQag/ztrBC7wegWoQ1nLREPVSKSW8byhTlzTKyNE4ifaTA6lCp7JjpFw==", "requires": { "@babel/highlight": "^7.0.0" } }, "@babel/core": { "version": "7.7.4", "resolved": "https://registry.npmjs.org/@babel/core/-/core-7.7.4.tgz", "integrity": "sha512-+bYbx56j4nYBmpsWtnPUsKW3NdnYxbqyfrP2w9wILBuHzdfIKz9prieZK0DFPyIzkjYVUe4QkusGL07r5pXznQ==", "requires": { "@babel/code-frame": "^7.5.5", "@babel/generator": "^7.7.4", "@babel/helpers": "^7.7.4", "@babel/parser": "^7.7.4", "@babel/template": "^7.7.4", "@babel/traverse": "^7.7.4", "@babel/types": "^7.7.4", "convert-source-map": "^1.7.0", "debug": "^4.1.0", "json5": "^2.1.0", "lodash": "^4.17.13", "resolve": "^1.3.2", "semver": "^5.4.1", "source-map": "^0.5.0" }, "dependencies": { "debug": { "version": "4.1.1", "resolved": "https://registry.npmjs.org/debug/-/debug-4.1.1.tgz", "integrity": "sha512-pYAIzeRo8J6KPEaJ0VWOh5Pzkbw/RetuzehGM7QRRX5he4fPHx2rdKMB256ehJCkX+XRQm16eZLqLNS8RSZXZw==", "requires": { "ms": "^2.1.1" } }, "semver": { "version": "5.7.1", "resolved": "https://registry.npmjs.org/semver/-/semver-5.7.1.tgz", "integrity": "sha512-sauaDf/PZdVgrLTNYHRtpXa1iRiKcaebiKQ1BJdpQlWH2lCvexQdX55snPFyK7QzpudqbCI0qXFfOasHdyNDGQ==" }, "source-map": { "version": "0.5.7", "resolved": "https://registry.npmjs.org/source-map/-/source-map-0.5.7.tgz", "integrity": "sha1-igOdLRAh0i0eoUyA2OpGi6LvP8w=" } } }, } //일부만 발췌

yarn.lock 파일을 gitignore에 넣어도될까?

답은 NO!

yarn.lock 파일은 설치시점이 달라도 일관된 패키지 버전을 유지할 수 있게 하기때문에 git 저장소에 올려서 관리되어야 함!!

다음번에는 npm에 대해서도 공부를 해보도록 해야겠다!

참고자료: git hub , 'https://www.daleseo.com/js-package-locks/'

--

yarn.lock 을 통해서 패키지 파일을 관리하게 되는데, yarn.lock 파일에서 core file 이 업데이트 된 경우에, 해당 파일의 내용을 바꾸지 않으면 Pull Request 시에 Version Collison 이 발생한다.

따라서 git fecth 를 통해 해당 내용을 업데이트 해줬다.