[spring-sagan]스프링 홈페이지 UI 업데이트, 동기화 #fork

개요

하고 싶은 것은 많고, 해야할 일은 많습니다.

`sagan-client`, `sagan-renderer` 모듈에 대해서 리팩토링을 적용했고,

새로운 가이드 타입을 추가한 것에 대해서 테스트 코드를 작성해야합니다. 

그런데 쉽지 않네요. 작성하면서 많은 생각을 해보았는데, 지금 하는 것들에 대해

 "이런 기능이 필요할까?" 라는 생각부터, "오히려 더 안좋은 구조로 바꾼 것은 아닐까?" 라는 생각까지

그래서 잠깐 머리 좀 식힐겸 다른 곳에 집중하기로 했습니다.

다른 책도 읽어보고, 새로운 아이디어가 떠올라서 토이 프로젝트도 시작해보고,

 

그런데 오늘 스프링 홈페이지가 완전 새로워진 것을 보았습니다.

Github 저장소로 바로 들어가서 확인한 결과

기존에 있던 `refresh` 브랜치에서 작업중이던 것을 추가한 듯 보입니다.

 

수정 사항을 확인해본 결과

제가 따로 fork한 뒤에 건드린 코드와는 연관이 없는 것으로 판단되었습니다.

(대부분 `sagan-client' 모듈과 프론트 엔드의 수정이었습니다.)

단 하나의 파일에서 변동이 있었는데, 쉽게 수정할 수 있는 부분이었습니다. 

(=충돌 파일) 템플린 엔진을 통해 새로운 가이드 타입에 대한 데이터를 뿌려주는 부분.

 

 

바로 제가 작업중인 저장소와 병합하였고

오늘은 그 과정에 대해서 포스팅합니다.

" Fork부터, synchronizing까지 "

 

결과

`http://localhost:8080`에 접속하면 새로운 스프링 홈페이지 UI와 같은 페이지를 확인할 수 있습니다.

 

http://localhost:8080

분위기가 많이 바뀌었네요.

 

 

과정

우선 `fork`에 대해서 다시 한 번 알아봅니다. 생각해보니, 실습을 통한 설명은 많이 접해보기도 했고,

그렇게 어려운 개념이 아니다보니, 공식 문서를 찾아볼 생각을 못했었습니다.

그래서 이번 기회에 한 번 읽어보았습니다.

 

 

Fork란?

Github은 `fork`에 대해서 다음과 같이 말하고 있습니다.

`fork`는 당신이 관리하는 복사본(저장소)입니다. 
해당 기술(forks)은 
원래 저장소(original repository)에 영향을 주지 않고 프로젝트를 변경할 수 있도록 합니다. 
1. 원래 저장소로부터 변경 사항(updates)을 받아오거나(fetch)
2. `pull request`로 변경 사항(changes)을 제안(submit)할 수도 있습니다.

 

쭉 읽다보니, 제가 알고있지 못했던 용어가 있습니다.

`upstream repository`: 위 설명에서 언급되는 `original repository`를 지칭합니다.

 

그리고 대충 이해하고 넘어갔던 용어에 대한 설명도 있습니다.

`pull request` : "use a pull request"라는 표현을 보아, upstream에게 변경을 제안하는 하나의 기능입니다. 

 

또 지금 포스팅에서 제게 필요한 기능에 대한 설명도 있습니다.

`synchronizing with upstream` : upstream 저장소의 변경사항을 upstream 저장소의 fork 저장소로 가져옵니다.

 

그 아래에는 fork 기능의 삭제, 접근성, 범위 등에 관련한 정책 설명이 있습니다.

 

마지막으로 모르고 있던 기능에 대한 설명도 있습니다.

저장소의 복사(duplicate the repository)와, 템플릿 적용(use the repository as a template)입니다.

이에 대한 설명으로는 original 저장소로부터 fork 저장소를 원하지만, 

upstream(original) 저장소로 변경 사항을 제안할 생각이 없다면 사용할 수 있는 기능입니다.

 

 

Let's Bring Changes from origin repository

Github에서 제공하는 `fork` 기술에 대해서 알아보았습니다.

그리고 이제 fork의 기능 중 하나인 `synchronizing with upstream`를 활용해보려고 합니다.

아래 내용은 마찬가지로 공식 문서를 기반으로 작성한 글입니다.

 

 

1. fork 저장소 remote 설정하기 [글 원본]

remote 저장소에 관련된 설명은 이 글을 참고하세요.

 

처음 프로젝트를 fork 하게 되면, 아마 다음과 같이 origin URL만 설정되어있을 것입니다.

$ git remote -v
> origin  https://github.com/YOUR_USERNAME/YOUR_FORK.git (fetch)
> origin  https://github.com/YOUR_USERNAME/YOUR_FORK.git (push)

 

이제, upstream 저장소와 동기화하기 위해서 해당 URL과 명칭을 설정해야합니다.

URL은 upstream 저장소의 주소를, 명칭은 목적에 맞게 upstream으로 설정합니다.

$ git remote add upstream https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git

 

이후 다시 설정을 확인해보면 아래와 같은 화면을 볼 수 있습니다.

$ git remote -v
> origin    https://github.com/YOUR_USERNAME/YOUR_FORK.git (fetch)
> origin    https://github.com/YOUR_USERNAME/YOUR_FORK.git (push)
> upstream  https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git (fetch)
> upstream  https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git (push)

 

 

2. 동기화하기 [글 원본]

 

먼저 upstream 저장소에 대한 정보를 fetch 합니다.

$ git fetch upstream
remote: Enumerating objects: 453, done.
remote: Counting objects: 100% (453/453), done.
remote: Compressing objects: 100% (75/75), done.
remote: Total 1020 (delta 389), reused 439 (delta 378), pack-reused 567
오브젝트를 받는 중: 100% (1020/1020), 467.04 KiB | 667.00 KiB/s, 완료.
델타를 알아내는 중: 100% (593/593), 로컬 오브젝트 46개 마침.
https://github.com/spring-io/sagan URL에서
 * [새로운 브랜치]     jdk8-datetime -> upstream/jdk8-datetime
 * [새로운 브랜치]     master        -> upstream/master
 * [새로운 브랜치]     refresh       -> upstream/refresh

 

그리고 upstream 저장소의 변경사항을 적용할 branch로 checkout 합니다.

원본에서는 master 브랜치로 작업하지만, 저는 작업중인 것이 있어서 다른 브랜치를 임시로 두었습니다.

`checkout` 하기 전에는 `branch` 명령어를 통해 브랜치를 생성해야합니다. 혹은, `checkout -b NEW_BRANCH_NAME` 명령어를 사용합니다.

$ git checkout merge-spring-io
> Switched to branch 'merge-spring-io'

 

마지막으로 fetch 한 최신의 upstream 브랜치를 현재 브랜치와 merge하면 됩니다.

$ git merge upstream/master

콘솔 결과를 넣고 싶은데 Intellij 버전 관리 도구를 사용해서.. 😱

 

3. 충돌 해결

merge 결과

위 사진처럼 충돌(Conflict)이 하나의 파일에서 발생하였습니다. (커밋 메시지 참고)

해당 파일은 템플린 엔진을 사용하여 가이드 페이지를 보여주는 파일입니다.

이전보다 더욱 깔끔한 구조로 바뀐 것 같아서 수정하는데 어려움은 없었습니다.

upstream 변경 사항으로 덮어씌우고, 직접 수정하였습니다.

 

 

Local Spring io Test

이제 업데이트 된 UI가 로컬 환경에 잘 적용되었는지 확인합니다.

$ ./gradlew sagan-site:bootRun
$ ./gradlew sagan-renderer:bootRun

하지만 잘 돌아가지 않았습니다. (에러를 캡처해두었어야 했는데, 깜박했습니다.)

 

결론적으로 `sagan-client` 모듈에 존재하는 캐시 관련 폴더와 라이브러리 폴더가 원인입니다.

해당 3개의 폴더를 모두 깔끔하게 지운 후, 다시 실행하면 

약간의 시간 후, (라이브러리 설치) 정상적으로 작동하게 됩니다.

덕분에 약간의 삽질이 있었습니다.

 

마찬가지로 이전 버전으로 돌아가면 다시 3개의 폴더( `.gradle/`, `build/`, `node_modules`)를 지워야합니다.

... 귀찮네요

 

 

결론

아직 포스팅하지 않았지만, 현재 `Translated`라는 새로운 가이드 타입이 추가되었습니다.

해당 타입은 저의 Github 저장소로부터 `tl-` 접두어를 가진 프로젝트를 모두 fetch & download 합니다.

 

아래 사진은 이러한 변경사항과 새로운 UI 적용의 결과(좌)와 이전 홈페이지 UI(우)입니다.

http://localhost:8080/guides

깔끔하긴한데, 반대로 공백의 여운이 강한 느낌입니다.

시간이 나면 이제 프로젝트 번역도 해서 추가해야겠습니다.

 

http://localhost:8080/guides/translateds/testing-web/

아직 번역중인 가이드입니다.

제가 보기에 편한 대략적인 번역은 되어있지만, 막상 또 누군가가 볼 수 있을 내용으로 적용하자니,

시간이 조금 소요되는 것 같습니다.

 

그런데 보면 볼 수록 이전 UI가 더 보기 좋아보이는 것은 ... 착각인가요...

음... 너무 하얀 느낌..?디못알이라.. ㅠㅠ 

 

 

어쨌든 오늘 포스팅은 Fork 저장소와, 이후 upstream 저장소와의 동기화까지의 작업을

"스프링 홈페이지 따라하기" 프로젝트에 적용해보았습니다.

 

 

참고 자료

1. Github. "Working with forks". https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/working-with-forks

2. Git. "리모트 저장소". https://git-scm.com/book/ko/v2/Git%EC%9D%98-%EA%B8%B0%EC%B4%88-%EB%A6%AC%EB%AA%A8%ED%8A%B8-%EC%A0%80%EC%9E%A5%EC%86%8C