2019/04

maven 외부 라이브러리 jar 추가 방법 (로컬 레파지토리 추가) => groboutils가 maven Repository에 존재하지 않아 프로젝트에 추가 후 사용 ConcurrentHashMap put, get 시 thread-safe 하지만, 로직이 들어간다면 thread-safe 보장을 할 수 가 없음. synchronized가 필요 lombok @Slf4j lombok @EqualsAndHashCode 위와 관련된 것들은 좀더 찾아 정리가 필요
문서정리의 중요성 내가안다고해서 모든 사람들이 아는 것은 아니다. 내가 있지않거나, 처음 업무를 하는 사람들을 위해 문서정리 및 공유는 필수라고 생각된다. 가끔은 개발보다 문서정리가 더 중요하다고 생각이 든다.
항상 읽어도 이해하기 힘들 부분이었으나, 이번 기회에 확실히 이해하고 정리를 하게 되었다. Java에서 String을 생성하는 방식은 두가지가 있다. new 연산자를 이용하는 방법 (String str = new String("Hello")); 리터럴을 이용하는 방법 (String str = "Hello"); new 연산자를 통해서 생성하게 되면 String은 Heap영역에 존재하게 된다. 하지만 리터럴을 이용할 경우 string contstant pool이라는 영역에 존재하게 된다. (constoanl pool은 PermGen영역에 존재하게 된다.) 차이점을 살펴보자. @org.junit.Test public void testStringEquality(){ final String literal = "H..
Git에서 작업 되돌리기 git reset git revert 두 가지 방법 존재 Git 리셋(reset) git reset 은 브랜치로 하여금 예전의 커밋을 가리키도록 이동시키는 방식으로 변경 내용을 되돌린다. ("히스토리"를 고쳐 쓴다.") git reset 은 마치 애초에 커밋하지 않은 것처럼 예전 커밋으로 브랜치를 옮기는 것 git reset HEAD~1 Git 리버트(revert) 로컬 브랜치의 경우 리셋(reset)을 잘 쓸 수 있지만, "히스토리를 고쳐쓴다"는 점 때문에 다른 사람이 작업하는 리모트 브랜치에는 쓸 수 없음. 변경분을 되돌리고 이 되돌린 내용을 다른 사람들과 공유하기 위해서는, git revert를 사용해야함 git revert HEAD 로컬 브랜치의 경우 리셋(reset)을 ..
브랜치 강제로 옮기기 -f 옵션을 이용해서 브랜치를 특정 커밋에 직접적으로 재지정 할 수 있음 git branch -f master HEAD~3 강제로 master 브랜치를 HEAD에서 세번 뒤로 옮겨라 => bugFix와 master가 같은 커밋을 바라보고 있었지만, master 브랜치가 HEAD에서 세번 뒤로 옮겨감
Git의 상대 참조 한번에 한 커밋 위로 움직이는 ^ 한번에 여러 커밋 위로 올라가는 ~ Git의 상대 참조 master^ ⇒ master 브랜치의 부모와 같은 의미 master^^ ⇒ master의 조부모(부모의 부모)를 의미 git checkout master^ 를 하면 위와 같은 상태가 된다.
Comparable 과 Comparator 인터페이스의 차이는 무엇인가? Comparable은 자연스러운 순서로 정렬할 때 사용. Comparator는 원하는 대로 정렬 순서를 지정하고 싶은 곳에 사용 배열을 정렬할 때는 일반적으로 Array 나 Collection 클래스의 내장된 라이브러리를 사용한다. Array와 Collection 클래스는 몇 가지 오버로딩된 정렬 메서드가 있다. 배열을 매개변수로 받는 메서드 Comparator 객체를 매개변수로 받는 메서드 @org.junit.Test public void sortInts(){ final int[] numbers = {-3, -5, 1, 7, 4, -2}; final int[] expected = {-5, -3, -2, 1, 4, 7}; Array..
프로젝트를 표현하는 커밋 트리(commit tree)에서 이동할 수 있는 여러가지 방법을 알아보자. 알아야할 용어 HEAD HEAD는 현재 체크아웃된 커밋을 가리킴 (현재 작업중인 커밋) HEAD는 항상 작업트리의 가장 최근 커밋을 가리키며, 작업트리에 변화를 주는 git 명령어들은 대부분 HEAD를 변경하는것으로 시작함 일반적으로 HEAD는 브랜치 이름을 가리키며, 커밋을 하게되면 bugFix의 상태가 바뀌고 이 변경은 HEAD를 통해서 확인이 가능함 HEAD 분리하기 HEAD를 분리한다는 것은 HEAD를 브랜치 대신 커밋에 붙이는 것을 의미 HEAD → master → C1 git checkout C1 HEAD → C1
브랜치끼리의 작업을 접목하는 두 번째 방법은 리베이스(rebase)이다. 리베이스는 기본적으로 커밋들을 모아서 복사한 뒤, 다른 곳에 떨궈 놓는 것이다. (리베이스를 하면 커밋들의 흐름을 보기 좋게 한 줄로 만들 수 있다는 장점이 있음) bugFix 브랜치에서 git rebase master 명령어 실행 후 C3 커밋은 어딘가에 남아있고(흐려진 영역), C3'는 master 위에 올려 놓은 복사본이다. git checkout master git rebase bugFix master 브랜치에서 bugFix쪽으로 리베이스를 하게 되면 아래와 같이 된다.
두 별도의 브랜치를 합치는 몇가지 방법을 알아볼 텐데, 처움으로 살펴볼 방법이 merge이다. Git의 합치기(merge)는 두 개의 부모(parent)를 가리키는 특별한 커밋을 만들어 낸다. 두 개의 부모가 있는 커밋이라는 것은 "한 부모의 모든 작업내역과 나머지 부모의 모든 작업, 그리고 그 두 부모의 모든 부모들의 작업내역을 포함한다"라는 의미가 있다. 만약에 bugFix란 브랜치가 C2를, master 브랜치가 C3를 가리키고 있는 상태에서 위 그림과같이 만드려면 아래와 같은 명령어가 필요하다. git checkout master // master 브랜치로 체크아웃 git merge bugFix // bugFix 브랜치와 병합(merge)
깡냉쓰
'2019/04 글 목록