- REST(Representational State Transfer) 는 말하자면 "데이터의 표현된 상태"이다. REST방식으로 클라이언트가 요청하여 전달받은 데이터는 데이터 원본이 아니라 원본을 클라이언트의 요청에 따라 클라이언트가 원하는 형식으로 받은 원본 데이터의 상태이다. 통신을 통해 원본 파일을 주고 받지 않는 다는 의미이다.
REST는 클라이언트와 서버가 리소스의 타입이나 원하는 언어 등을 사용하여 자원을 자유롭고 명확하게 표현할 수 있는 것에 집중한다.
https://evan-moon.github.io/2020/04/07/about-restful-api/#patch는-왜-멱등성이-보장되지-않는다는걸까
기본 명령어
git log : commit한 내역과 commit ID를 볼 수 있다. 말그대로 git의 log
git remote -v : 현재 branch와 연결되어 있는 origin 및 upstream을 확인할 수 있다.
git branch : branch의 상태, 이름 갯수 등을 파악 가능
git checkout <branch name> : 으로 이동
git add . : 현 branch의 모든 파일을 staging
git commit -am <commit message> : stage의 모든 파일을 commit 하며 message 를 남김
git status : git 상태 보기
git push origin <branch name> : 해당 branch를 origin에 pull request하도록 push
git log --branches --decorate --graph : branch 간의 분기 병합과정을 보기 쉽게 시각적으로 보여줌^^
git remote -v : 연결되어 있는 github의 주소를 볼 수 있음
-u : push할 때 upstream 연결
-t : remote branch에 없는 나의 로컬 branch를 리모트와 트래킹
reset : commit 을 아예 없애버리는 명령어
git stash: 아직 commit 하기에는 이른, 마무리 되지 않은 작업을 하던 도중 잠시 저장 할 수 있는 명령어 (나의 작업을 멈추고 이전 작업이나 동료의 작업을 수정해야 할 때에 사용)
git stash list : stash한 리스트를 볼 수 있음.
git stash apply (stash이름) : 가장 최근에 stash 한 파일을 불러옴 (해당이름의 stash를 불러옴)
git stash drop (stash이름) : 가장 최근의 stash를 제거 (해당 이름의 stash를 제거)
git git stash show -p | git apply -R : 실수로 잘못 stash 적용한 것을 되돌릴 때
깃 배우기: https://learngitbranching.js.org/?locale=ko
출처: https://git-scm.com/book/ko/v2/Git의-기초-수정하고-저장소에-저장하기
git은 파일을 committed, modified, staged 3 상태로 관리한다
- Committed란 데이터가 로컬 데이터베이스에 안전하게 저장됐다는 것을 의미한다.
- Modified는 수정한 파일을 아직 로컬 데이터베이스에 커밋하지 않은 것을 말한다.
- Staged란 현재 수정한 파일을 곧 커밋할 것이라고 표시한 상태를 의미한다.
워킹 트리 (디렉토리) 는 프로젝트의 특정 버전을 checkout한 것.
staging area는 git 디렉토리에 있다. 단순한 파일이고 곧 커밋할 파일에 대한 정보를 저장
git 디렉토리에 있는 파일들은 committed 상태
staging area에 추가하지 않았으면 modified
git remote -v 를 통해 연결되어 있는 github의 주소를 볼 수 있는데 origin은 내가 포크하여 나의 github로 옮겨온 repository를 지칭하며 clone 으로 받는 순간 자동으로 origin은 정해진다. 또한 upstream은 fork를 받아온 원본 repository를 지칭한다. 이때 push를 하여 PR을 할 수 있는 것은 주로 origin 뿐이다. 무분별한 PR을 막기 위해 upstream의 게시자는 upstream으로의 직접적인 push를 비활성화 시켜둔다.
master에서 branch를 생성하고 그것을 merge할 때 충돌이 일어나기 위한 조건:
같은 파일의, 같은 부분을 동시에 수정하고 merge할 때. (서로 다른 파일을 수정하고 merge 하거나, 같은 파일이라고 할지라도 서로 다른 부분을 수정하고 merge 하면 자동으로 합쳐진다.)
→ 따라서 충돌을 예방하기 위해서는 맡은 부분을 철저하게 나눠서 하거나 충돌이 발생하더라도 빠르게 수동으로 설정할 수 있도록 update를 자주 해줘야.
