Merge (4) 썸네일형 리스트형 Git - 체리픽(Cherry-pick), 다른 브랜치 혹은 다른 레포지토리의 커밋 가져오기 오늘 다루어볼 내용은 git의 cherry-pick(체리픽)이다. 보통 체리픽을 사용하는 이유는 다른 브랜치의 커밋의 일부만 가져올때 많이 사용한다. 간단하게 예제를 다루어보자. > gb * [1] feature/add-function [2] feature/update-function 위처럼 두개의 브랜치가 존재하고 각 브랜치의 커밋로그는 아래와 같다. > feature/add-function * 13e321a - (HEAD -> feature/add-function) add c.txt (9 minutes ago) * f894b25 - add b.txt (9 minutes ago) * 35402a1 - add a.txt (9 minutes ago) > feature/update-function * cb6.. Git - git rebase란? Merge & Rebase 차이점 Git에서 한 브랜치에서 다른 브랜치로 합치는 방법은 두 가지다. 하나는 이전 포스팅에서 다룬 Merge이고 다른 하나는 Rebase이다. Rebase 상황을 이전 포스팅에서 다루어봤던 merge 상황이랑 비교해보자. Git - fast-forward merge 란? fast-forward & 3-way Merge의 차이점 1. fast-forward merge 아래와 같은 상황이 있다고 가정하자. issue 처리를 위해 master 브랜치에서 브랜치를 따서 작업을 하고 있었다. 갑자기 픽스해서 빠르게 릴리즈해야할 버그 사항이 있어 hotfix 브랜치를.. coding-start.tistory.com 아래와 같은 상황이 있다. 이 상황에서 3-way-merge를 하면 그래프상태는 아래와 같은 상태가 된다.. Git - fast-forward merge 란? fast-forward & 3-way Merge의 차이점 1. fast-forward merge 아래와 같은 상황이 있다고 가정하자. issue 처리를 위해 master 브랜치에서 브랜치를 따서 작업을 하고 있었다. 갑자기 픽스해서 빠르게 릴리즈해야할 버그 사항이 있어 hotfix 브랜치를 master 기준으로 따서 작업을 했다. 버그를 픽스하고 테스트를 통과해 이제 릴리스 해야하는 상황이다. 이제 master에 hotfix를 머지해야되는 상황이다. 그런데 hotfix는 master를 베이스로 하고 있는 브랜치, 즉 master의 upstream 브랜치이다. 이제 머지를 하면 fast-forward 머지가 되는 것인데, 이것은 단순히 master가 바라보고 있는 커밋을 앞으로 이동하는 것(hotfix 브랜치가 가르키는 커밋을 master가 바라본다.) 뿐이다... Lucene - 인메모리버퍼(In-Memory-Buffer) 역할, 세그먼트 병합(Merge) 루씬은 색인 요청이 올때마다 새로운 세그먼트가 추가된다. 그리고 일정한 주기로 세그먼트들을 병합하는 과정을 갖는다. 만약 이러한 루씬에 인메모리버퍼가 하는 역할은 무엇일까? 우선 인메모리버퍼가 없는 루씬을 가정한다면, 만약 순간적으로 대용량의 데이터의 색인요청이 많아질 경우 세그먼트(역색인 파일)의 개수가 너무 많아져서 문제가 될 수 있다. 파일이 갑자기 많아지고 이는 당연히 색인에 지연이 생길 것이고 최종적으로 서비스 장애로 이어질 것이다. 하지만 실제적으로 루씬은 색인 작업이 요청되면 전달된 데이터는 일단 인메모리버퍼에 순서대로 쌓이고 버퍼가 일정크기 이상의 데이터가 쌓였다면 그때 한번에 모아서 색인처리를 한다. 즉, 버퍼가 일종의 큐역할을 하는 것이다. 버퍼에 모여 한번에 처리된 데이터는 즉시 세그.. 이전 1 다음
