본문 바로가기

전체 글

 (183)
rebase, pull --rebase [branch1] $ git rebase master 를 하게되면, 우리의 branch1 브랜치 앞과 공통조상 사이에 master 를 끼워넣는 rebase 를 하게 된다. 그러면 pull --rebase 옵션은 뭘까.. pull 은 fetch + merge 이다. 따라서 pull --rebase 는 fetch + rebase 이다. git pull --rebase 는 결국 git fetch 와 git rebase teamone/master 이 두 명령을 순서대로 실행하는 것과 같다.
squash 머지 한 브랜치에서 계속 작업할 경우 이 글의 작업 환경은 아래와 같이 되어 있다고 가정한다. Upstream : 원본 저장소 Origin : 원본 저장소를 내 레포에 Fetch 한 저장소 로컬 저장소 Remote(Upstream) 저장소에서 로컬로 가져와서 C1, C2, C3 를 작업했다. 이제 Origin 에 push 후, Squash merge 를 통해 Remote 저장소에 반영했다. 스쿼시 머지를 한 후, 이후 작업을 진행한다. $ git remote add upstream [원본 저장소 URL] // 로컬환경에 upstream 저장소 정보 추가 $ git fetch upstream [브랜치이름] // upstream 저장소의 브랜치 변경정보 가져옴 /* 작업 */ $ git add . $ git commit -m "C4" 이제 Re..
upstream vs origin 깃을 공부하던 중 upstream 과 origin 리모트 브랜치에 혼란이 생겨 기록한다. origin 브랜치는 우리가 git clone 을 하면 자동으로 origin/master 브랜치가 생기는 것에서 익숙한 이름이다. origin Git 서버의 리포지토리를 Clone 하면 Git은 자동으로 origin 이라는 이름을 붙인다. origin 으로부터 저장소 데이터를 모두 내려받고 master 브랜치를 가리키는 포인터를 만든다. 이 포인터는 origin/master 이라는 이름이며, 수정이 불가능하다. 그리고 Git은 로컬의 master 브랜치가 origin/master 를 가리키게 한다. 이제 이 master 브랜치에서 작업을 시작할 수 있다. upstream, downstream upstream 이란 상..
Rebase 한 브랜치에 다른 브랜치의 내용을 적용시키려면 흔히들 쓰는, 그리고 내가 지금까지 쓰던 명령어는 Merge 이다. Master 브랜치에 내 작업내용 PR 을 적용시키려면, Merge 명령어를 썼다. 그리고 Master 의 변경내용을 내 작업브랜치에 적용시킬때는 pull ( 원격 저장소의 내용을 가져오는 Fetch + Merge) 를 썼다. 오늘은 코드를 깔끔하게 병합할 때 쓰는 Rebase 라는 명령을 알아보도록 한다. 내가 깃을 이용한 협업과 gitflow라는 개념을 처음 알게 되었던 글은 우아한 형제들의 블로그였는데, https://techblog.woowahan.com/2553/ 우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그 {{item.name}} 안녕하세요. 우아한형제들 배민..
코틀린과 Hibernate, CGLIB, Proxy 오해와 재대로된 사용법 - (6) 5장에서 Kotlin 에서 @RequsetBody 에 기본 생성자가 필요없다라는 것에 대해 알아봤습니다. 이 과정에서 찜찜한 상태로 넘어갔었습니다. 이번에 새롭게 알게된 것으로 이를 해결했기에 기록해봅니다. 1. Jackson-Module-Kotlin https://proandroiddev.com/parsing-optional-values-with-jackson-and-kotlin-36f6f63868ef Parsing Optional Values with Jackson and Kotlin A quick introduction to Jackson Kotlin module for parsing data with missing values proandroiddev.com 이전 글에서, Json 을 @Reque..
코틀린과 Hibernate, CGLIB, Proxy 오해와 재대로된 사용법 - (5) 이번에는 전 글에서 언급했듯이, Kotlin + @RequestBody 에서 기본생성자가 필요할까? 에 대해 알아보도록 하겠습니다. 1. Converter @RequestBody 로 객체를 맵핑하는 방법은, 적절한 컨버터를 찾아 read() 하는 것입니다. AbstractMessageConverterMethodArgumentResolver 클래스를 봅시다. 그 중 readWithMessageConverters 를 봅시다. 적절한 post 요청으로 디버그를 해봤습니다. messageConverters 에 10개의 컨버터가 대기중이군요. 예상컨데, 우리는 Json 요청을 보낼 것이니 MappingJackson2HttpMessageConverter 를 쓸 것입니다. 위의 루프문을 돌면서, MappingJack..
코틀린과 Hibernate, CGLIB, Proxy 오해와 재대로된 사용법 - (4) 앞선 글에서 proxy 객체를 사용하기 위해 allOpen 플러그인을 사용하였습니다. 이 allOpen 을 조금 더 알아봅시다. 0. allOpen vs 그냥 open class 발단은 이거였습니다. 제가 이 주제로 글을 적기 전, 메모해놨던 것이 있는데 아래와 같이 적혀 있었습니다. allOpen 플러그인을 적용하면서 기존 코드의 private set 을 사용하지 못함 -> protected set 을 고려해보자. 이를 시연해보기 위해 다음과 같이 생각했죠. allOpen 이 open 클래스라고 했으니 그냥 open class 만들어서 재현해볼까? open class User( @Id @GeneratedValue(strategy = GenerationType.IDENTITY) val id: Long =..
코틀린과 Hibernate, CGLIB, Proxy 오해와 재대로된 사용법 - (3) 1. 코틀린의 생성자 코틀린을 사용하면 보통 primary constructor 를 사용합니다. 그리고 자바를 배웠다면, 다른 생성자가 정의되어 있으면 기본 생성자가 자동으로 생성되지 않음을 알고 있을 것입니다. 그러면, 기본 생성자 없이 entity 코드가 잘 돌아가는가? 가 이번 글의 주제입니다. 2. 기본 생성자가 필요할 것 같은데? 제가 의심한 상황은 두가지 였습니다. java + hibernate 사용할 때 entity 객체에 기본 생성자는 필수였다. proxy 객체를 만들 때 기본 생성자가 필요하지 않을까 ? 두번째 의심은 첫번째 글에서 봤듯이, CGLIB 에서 objenesis 라이브러리를 사용함으로서 해결. 그러면 첫번째 의심인 java + hibernate 처럼 kotlin + hiber..

티스토리툴바