Skip to content

Instantly share code, notes, and snippets.

@SeonghuiChoe
Last active June 25, 2017 23:12
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save SeonghuiChoe/c050db0db2fc5a68027b83fd154d3a28 to your computer and use it in GitHub Desktop.
Save SeonghuiChoe/c050db0db2fc5a68027b83fd154d3a28 to your computer and use it in GitHub Desktop.
tistory

API RULES

API parameter

사용하는 API에 비슷한 로직이 생기면서 중복을 없애기 위해 특정한 parameter를 넘겨주면서 같은 API가 다른 동작을 하도록 로직을 만든다.
예를들어 어떤 함수가 있는데 parameter를 이용해 게시글을 등록하거나 수정하는 일들을 구분해서 실행한다.
작업하던 코드에서 enum과 같이 숫자를 넘겨주던가 'Y', 'N'와 같은 문자를 넘겨주는 부분을 많이 봤는데, 이 방식이 옳은것인지 대해 고민을 하게 되었다.

GitHub API 방식

  • Edit an issue 부분에 'state'라는 parameter가 있는데, description에 State of the issue. Either open or closed.라고 적혀있다. 의미를 알 수 없는 숫자여서 그 숫자의 의미를 찾아야 되는 것 보다 open, closed 처럼 의미를 바로 알 수 있도록 값을 보내는 방식을 GitHub는 사용하고 있었다.

Parameters

Name Type Description
state string State of the issue. Either open or closed.
{
  "title": "Found a bug",
  "body": "I'm having a problem with this.",
  "assignee": "octocat",
  "assignees": [],
  "milestone": 1,
  "state": "open",
  "labels": [
    "bug"
  ]
}

Docker 환경 구성하기

Homebrew로 Docker를 설치해봅시다.

$ brew install docker

그리고 Host OS와 커뮤니케이션 할 인터페이스인 Docker-machine을 설치합니다.

$ brew install docker-machine

Docker-machine 만들기

Docker-machine을 올리기 위해서 virtualbox를 설치합니다.

$ brew cask install virtualbox

Docker-machine을 만들어 봅시다.

$ docker-machine create --driver virtualbox defaul

제대로 생성 되었는지 확인해 볼까요?

$ docker-machine ls
NAME      ACTIVE   DRIVER       STATE     URL   SWARM   DOCKER    ERRORS
default   -        virtualbox   Stopped                 Unknown   

Docker-machine을 실행시키고 활성화 시킵니다.

$ docker-machine start default
$ docker-machine env default
$ eval $(docker-machine env default)

Starting "default"...
(default) Check network to re-create if needed...
(default) Waiting for an IP...
Machine "default" was started.
Waiting for SSH to be available...
Detecting the provisioner...
Started machines may have new IP addresses. You may need to re-run the `docker-machine env` command.

export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://192.168.99.100:2376"
export DOCKER_CERT_PATH="/Users/choeseonghui/.docker/machine/machines/default"
export DOCKER_MACHINE_NAME="default"
# Run this command to configure your shell: 
# eval $(docker-machine env default)

활성화 되었는지 확인해 볼까요?

$ docker-machine ls
NAME      ACTIVE   DRIVER       STATE     URL                         SWARM   DOCKER        ERRORS
default   *        virtualbox   Running   tcp://192.168.99.100:2376           v17.03.0-ce   

ACTIVE의 *이 활성화 표시입니다.

Docker 컨테이너 생성하기

NodeJS 컨테이너를 생성하고 버전을 확인해 볼까요?

$ docker run -ti --name mycontainer node /bin/bash

Unable to find image 'node:latest' locally
latest: Pulling from library/node
6d827a3ef358: Pull complete 
2726297beaf1: Pull complete 
7d27bd3d7fec: Pull complete 
44ae682c18a3: Pull complete 
e8c647cd1137: Pull complete 
026a2f399da4: Pull complete 
c3af0fce5111: Pull complete 
ef826cc54042: Pull complete 
Digest: sha256:a72f8cd9aba12ea3a19ada91e077c4d8822d3bd7dc3c4707b16630e5c2477845
Status: Downloaded newer image for node:latest
root@d3652e91ed63:/# node --version
v7.8.0

By Hui

Command

다양한 command 명령어가 있지만 개인적으로 자주 쓰는 명령어가 있고 사용을 전혀 하지 않은 명령어도 있습니다.

사용빈도 Command
프로젝트 시작시 clone / init
자주 pull / commit / add / push / remote / branch / checkout / status
stash / merge / rebase / log / diff / revert / reset / fetch
가끔 tag
사용안함 mv / rm / bisect / grep / show

Stash

작업을 하고 있었는데 갑자기 급한 이슈가 생겼다면?
잠깐만 지금 상태를 저장해두고 싶을 때가 있나요? 그럴땐 stash를 사용해보세요.
git stash를 사용한다면 작업했던 내용을 잠시 저장해 둘 수 있습니다. 이슈를 해결하고 다시 작업중인 상태로 돌아가고 싶으실때는 git apply를 통해 불러올 수 있죠. stash는 stack으로 이루어져 있기 때문에 맨 마지막 작업을 불러오게 됩니다. apply는 가져오기만하지 그대로 남겨져 있기 때문에 언제든 불러올 수 있죠. 가져오고나서 저장한 내용을 제거 하고 싶다면 pop을 사용하시면 됩니다.

git stash # 변경된 상태를 저장한다.
git stash apply | pop # 변경된 상태를 불러온다. | 불러오고 삭제한다.
git stash -a | # untracked file을 함께 저장
git stash list # 저장된 상태 목록을 본다.

Diff

상태를 비교하고 싶을때 diff를 사용합니다. 보통 지금 작업하는 unstage상태와 비교를 하게 되는데요. add를 통해 stage(index)되어있는 파일과 비교하고 싶을때는 --cached 옵션을 사용하면 편리합니다. 또는 커밋과 커밋을 비교할 수 있는데요. 중요한건 첫번째 인자는 과거라고 생각하시고 두번째 인자는 미래라고 생각하시고 쓰시면 될 것 같습니다.

git diff # HEAD와 지금 작업한 내용의 변화
git diff --cached # HEAD와 index에 있는 상태와의 비교
git diff HEAD~1 HEAD # 전커밋과 HEAD를 비교
git diff HEAD HEAD~1 # 위와 같지만 +, -가 반대로 되는 모양을 볼 수 있습니다. (관점 중요)

Add

unstage에 있는 파일을 stage로 옮길때 add를 사용하지만 만약 5개의 파일중 3개만 stage로 옮기고 싶을때는 각각의 필요한 파일들을 일일이 적어줘야 됩니다. git add filename 만약 10개중에 5개라면 또 5개의 이름을 적어야되죠. editor를 사용해서 쉽게 선택해서 stage로 옮길 수 있지만 terminal에서는 힘들죠 이럴때 옵션을 사용하면 편리합니다. 또한 한 파일 안에 chunk단위로 add 할 수 있는 옵션도 있습니다. y, n선택으로 필요한 부분만 stage에 올릴 수 있죠.

git add -i # 간편한 UI로 숫자로 선택할 수 있도록 되어있습니다.
git add -p # chunk단위로 선택해서 stage에 올릴 수 있습니다.

Checkout

checkout은 쓰는 방식에 따라 의미가 조금 다릅니다. checkout fileName으로 사용하신다면 수정하기 전으로 돌아가는 의미이지만 checkout hash, branchName, tag를 사용하신다면 HEAD를 해당 커밋으로 이동합니다.

Merge

다른 사람의 업데이트 이력을 내 저장소에도 갱신

file pull and merge origin/master 다른파일 같은파일
file만 수정 pull and merge 문제없이 pull Please commit your changes or stash them
before you can merge. Aborting
file을 수정하고
commit
pull and merge 바로 commit editor실행되며
merge기본 형식의 message가 미리 적힌 상태
CONFLICT (content): Merge conflictm
different commits each.
both modified: README.md

both modified

<<<<<<< HEAD (my local branch name)
=======
>>>>>>> 8c25ab8cf03ee6f86da9fcc1b9cdbc78e3f2f826 (commit hash)

로컬 저장소 파일과 원격 저장소 파일이 충돌이 났을 때 저 모양을 볼 수 있다.
===== 로 구분된 윗 부분이 로컬 저장소, 아랫 부분이 원격 저장소의 변경 내용이라는 점!

여기서 직접 수정이 가능하지만 로컬 저장소의 변경사항 또는 원격 저장소의 변경사항을 선택 할 수 있다.

  • git checkout --theirs file: 로컬 저장소의 변경사항을 선택 (git checkout -3 file)
  • git checkout --ours file: 원격 저장소의 변경사항을 선택 (git checkout -2 file)

직접수정 or 로컬 저장소선택 or 원격 저장소선택 을 하게되면 git status를 쳤을때 아무 변화가 없다.
여기서 commit을 하고 merge작업을 계속하면 된다.

  • git commit: commit editor가 실행, Merge branch 'master' of ...이런 형식의 message가 미리 적힌 상태이다.
  • git commit -m "merge된 commit의 message" : 내가 적은 message로 merge commit이 생성

GIT 바로알기

여러분은 GIT 명령어들을 감으로 사용하고 계시지는 않으신가요?
HEAD, 인덱스, 워킹 디렉토리들을 설명하라고 하면 명쾌하게 말하기 어려워 하시는 분들이 계실텐데요. 자주 사용하지만 모르고 넘어갔던 개념들에 대해 다시한번 집고 넘어가는 시간을 가져보도록 합시다:)

HEAD

HEAD는 현재 브랜치를 가리키는 포인터이며, 브랜치는 브랜치에 담긴 커밋 중 가장 마지막 커밋을 가리키죠. 단순하게 HEAD는 마지막 커밋의 스냅샷이라고 생각하시면 됩니다:) 좀더 자세한 HEAD의 이동은 다른 명령어를 설명하면서 천천히 따라가보도록 합시다:)

INDEX

Index는 바로 다음에 커밋할 것들이며, git commit 명령을 실행했을 때 Git이 처리할 것들이 있는 대기실이라고 생각하세요:)
Index는 워킹 디렉토리에서 마지막으로 Checkout 한 브랜치의 파일 목록과 파일 내용으로 채워지고, 이후 파일 변경작업을 하고 변경한 내용으로 Index를 업데이트 할 수 있죠. 이렇게 업데이트 하고 git commit 명령을 실행하면 Index는 새 커밋으로 변환됩니다.

워킹 디렉토리

워킹 디렉토리는 샌드박스로 생각하세요:) 커밋하기 전에는 Index(Staging Area)에 올려놓고 얼마든지 변경할 수 있죠! 마음껏 수정하고 되돌릴 수 있다고 생각하시면 되요~!

명령어

RESET

[HEAD의 이동] HEAD는 계속 현재 브랜치를 가리키고 있고, 현재 브랜치가 가리키는 커밋을 바꿉니다. HEAD가 master 브랜치를 가리키고 있다면 git reset 9e5e6a4 명령은 master 브랜치가 9e5e6a4를 가리키게 합니다.

CHECKOUT

경로없이 쓰는 git checkout [branch] 명령은 git reset --hard [branch] 명령과 비슷하게 [branch] 스냅샷을 기준으로 작동합니다.

reset --hard 명령과는 달리 checkout 명령은 워킹 디렉토리를 안전하게 다룬다.
저장하지 않은 것이 있는지 확인해서 날려버리지 않는다는 것을 보장하죠! 사실 보기보다 좀 더 똑똑하게 동작한다는 것을 알고 계셨나요? 워킹 디렉토리에서 Merge 작업을 한번 시도해보고 변경하지 않은 파일만 업데이트한다. 반면 reset --hard 명령은 확인하지 않고 단순히 모든 것을 바꿔버리죠.. 조심해서 써야합니다..

RESET & CHECKOUT

중요한 차이점은 HEAD를 업데이트 여부! reset 명령은 HEAD가 가리키는 브랜치를 움직이지만(브랜치 Refs를 업데이트하지만), checkout 명령은 HEAD 자체를 다른 브랜치로 옮긴다.

예를 들어 각각 다른 커밋을 가리키는 masterdevelop 브랜치가 있고 현재 워킹 디렉토리는 develop 브랜치라고 가정해볼까요?(즉 HEAD는 develop 브랜치를 가리킴). git reset master 명령을 실행하면 develop 브랜치는 master 브랜치가 가리키는 커밋과 같은 커밋을 가리키게 된다. 반면 git checkout master 명령을 실행하면 develop 브랜치가 가리키는 커밋은 바뀌지 않고 HEAD가 master 브랜치를 가리키도록 업데이트됩니다:) 이제 HEAD는 master 브랜치를 가리키게 된다는것!

그래서 위 두 경우 모두 HEAD는 결과적으로 A 커밋을 가리키게 되지만 방식은 완전히 다르다. reset 명령은 HEAD가 가리키는 브랜치의 포인터를 옮겼고 checkout 명령은 HEAD 자체를 옮겼다.

Git

버전 관리를 위한 도구

Git and GitHub

  • Git : 버전 관리를 위한 도구로, 리눅스 커널의 창시자 리누스 토발즈가 BitKeeper라는 상용 도구를 무료로 사용하여 버전 관리를 했었는데 무료 사용을 할 수 없게 되어 직접 만들게 되었습니다.
  • GitHub: Git으로 만든 원격저장소 서비스이며 Git을 호스팅 해주는 웹 서비스이며 git저장소 서버를 대신 유지 및 관리해주는 서비스입니다. (좋은 UI, Wiki 제공, issues page 제공)
  • Git에서 우리가 흔히 말하는 폴더를 ‘작업트리(Work Tree)’라고 부릅니다. 그리고 커밋을 실행하기 전의 저장소와 작업 트리 사이에 존재하는 공간을 ‘인덱스’라고 하죠.

세 개의 트리

Git을 서로 다른 세 트리를 관리하는 컨텐츠 관리자로 생각하면 resetcheckout을 좀 더 쉽게 이해할 수 있다. 여기서 “트리” 란 실제로는 “파일의 묶음” 이다. 자료구조의 트리가 아니다 (세 트리 중 Index는 트리도 아니지만, 이해를 쉽게 하려고 일단 트리라고 한다).

Git은 일반적으로 세 가지 트리를 관리하는 시스템이다.

트리 역할
HEAD 마지막 커밋 스냅샷, 다음 커밋의 부모 커밋
Index 다음에 커밋할 스냅샷
워킹 디렉토리 샌드박스

HEAD

HEAD는 현재 브랜치를 가리키는 포인터이며, 브랜치는 브랜치에 담긴 커밋 중 가장 마지막 커밋을 가리킨다. 지금의 HEAD가 가리키는 커밋은 바로 다음 커밋의 부모가 된다. 단순하게 생각하면 HEAD는 마지막 커밋의 스냅샷이다.

RESET

reset 명령이 하는 첫 번째 일은 HEAD 브랜치를 이동시킨다. checkout 명령처럼 HEAD가 가리키는 브랜치를 바꾸지는 않는다. HEAD는 계속 현재 브랜치를 가리키고 있고, 현재 브랜치가 가리키는 커밋을 바꾼다. HEAD가 master 브랜치를 가리키고 있다면(즉 master 브랜치를 Checkout 하고 작업하고 있다면) git reset 9e5e6a4 명령은 master 브랜치가 9e5e6a4를 가리키게 한다.

CHECKOUT

git checkout [branch] 명령은 git reset --hard [branch] 명령과 비슷하게 [branch] 스냅샷을 기준으로 세 트리를 조작한다. 하지만, 두 가지 사항이 다르다.

첫 번째로 reset --hard 명령과는 달리 checkout 명령은 워킹 디렉토리를 안전하게 다룬다. 저장하지 않은 것이 있는지 확인해서 날려버리지 않는다는 것을 보장한다. 사실 보기보다 좀 더 똑똑하게 동작한다. 워킹 디렉토리에서 Merge 작업을 한번 시도해보고 변경하지 않은 파일만 업데이트한다. 반면 reset --hard 명령은 확인하지 않고 단순히 모든 것을 바꿔버린다.

두 번째 중요한 차이점은 HEAD를 업데이트 하는가이다. reset 명령은 HEAD가 가리키는 브랜치를 움직이지만(브랜치 Refs를 업데이트하지만), checkout 명령은 HEAD 자체를 다른 브랜치로 옮긴다.

reset 명령은 HEAD가 가리키는 브랜치의 포인터를 옮겼고 checkout 명령은 HEAD 자체를 옮겼다.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment