Git

gitworking directory | staging area | .git diretorygit폴더에 cmder을 통해 명령어 입력git 폴더에 a,b,c .txt파일 생성파일의 상태 확인현재 working directory에 위치staging area에 들어가기 (

추가하고 싶지 않은 파일들을.gitignore이라는 파일에 모아둔다.(git status help의 의미)(git status short의 의미\_간략하게 보여줌)A : staging area에 있음?? : working directoryAM c.txt - 로 뜬다.A

(working directory에 있는) workig directory에 잇는 것만 확인됨staging area에 있는 것 확인 가능vscode를 열고 vscode에 추가해야할 것vscode 열기추가하기다시 cmder에 돌아와서실행하면 vscode에 working d

workig directory | staging area | .git directory기본적인 템플릿 나옴Title과 Description 작성commit된 리스트들이 나옴수정하고workig directory에 있는 c.txt를staging area로 가지고 온다.

파일을 삭제하기git status로 확인해보기간편하게 바로 staging area에 자동으로 추가된다.파일 이름 변경git status 를 하면 git status에 포함이 되지 않는다.변경된 이름이 바로 staging area에 포함됨

commit된 로그들을 확인할 수 있다.수정된 파일의 내용들을 확인할 수 있다.간편하게 목록들을 볼 수 있다.commit을 해나가는 줄기 : master branch head : 지금 내가 현재 보고 있는 그 commit을 가리킴이제 막 commit된 d가 head라

목록들을 깔끔하게 볼 수 있다.사용가능한 포맷은 git 사이트에 reference->log에 들어가면 된다. branch는 checkout이라는 명령어로 이용 가능좀 더 시각적으로 깔끔하게 보여진다.설정하기설정하고난 후

최근 commit된 3개 보기 최근 commit된 3개를 간단하게 한줄로 보기누가 작성했는지 보기선택한 날짜 이전 것만 보기프로젝트가 포함된 commit들만 확인 가능 문자열을 가지고 있는 commit이 보여짐더 자세한 내용을 볼 수 있음 해당하는 파일별로 로그를 볼

태그 해놓으므로써 내가 원하는 부분으로 빠르게전환할 수 있는 큰 장점major minor fix ex) v2.0.0major : v2전체적인 업데이트가 발생했을 때 하나씩 올려감minor : 0그 커다란 기능 중에서 조금의 기능이 업데이트 되거나개선이 되었을 때 버전을

a <- b <- c <- d - master별도로 branch를 따로 주지 않으면 master 한 줄기에서 계속 commit이 발생된다.(내 컴퓨터 안에만)지금 현재 리파지토리에 있는 branch들을 확인 가능깃허브와 같은 서버와 연결된 리파지

master branch에서 새로운 branch가 생성된 이후에master branch에 변동사항이 없다면 merge를 할 때단순히 master branch가 가르키고 있는 포인터를 "d"가 아닌 "f"로 옮기기만 하면 된다. 그런 다음 feature-A를 branch

fast-forward가 가능한 경우라면merge commit을 만들지 않고 fast-forward를 진행fast-forward가 불가능한 상황이라면git merge (branch이름)를 해주면 merge commit이 만들어진다.

git merge할 때 무언가 문제가 생겨서 자동적으로 해결이 안된,충돌이 났을 때 발생<2가지의 branch에서 동일한 파일을 수정했을 떄>1\. 수동으로 해결하기동일한 파일을 수정을 하고 merge했을 떄동일한 파일이 수정되었다고 나타난다.파일 보기 cmder

여러 가지 branch를 만들고 branch 위에 또 branch를 만들어여러가지를 체이닝하는 경우에 사용한다.master branch에서 service branch를 만든 이후에service branch를 사용하면서 만들어야하는 ui가 있다면별도로 ui branch를

갑자기 test 해야할 일이 생길 때내가 잠시 작업하고 있는 내용들을 저장해두고branch 전환을 위해서 쓸 수 있다. 버그를 고치고 있는데 다른 시도를 해보고 싶은데여러 가지 시도들을 잠시 저장해두고 싶을 때준비되지 않은 파일들을 commit하기보다는stash 커멘드

commit을 너무 성급하게 해서 모든 수정사항을 함께 commit하지 못했을 떄commit의 메시지가 마음에 들지 않을 때commit을 너무 많이 해서 여러가지로 조금씩 잘라서 commit을 다시 하고 싶을 떄commit을 너무 조금씩해서 하나로 묶고 싶을 때실수로

새로운 파일을 만들고 staging area에 올리고 commit 했다.commit 메시지를 수정하고 싶을 떄 파일의 내용을 수정하고 싶을 때충분한수정을 하지 못했을 떄파일의 내용을 수정해도 commit의 메시지는 변하지 않는 것을 확인가능HEAD의 내용을 확인하면 수

특정한 commit으로 초기화시켜주는 명령어HEAD에서 2번째에 있는 곳으로! 초기화된 commit은 history에서는 사라졌지만작업하고있던 내용들은 working directory에 남아있다.working directory에 남아있는 것을 확인할 수 있다.작업하고

git reflog ---reference log이전에 HEAD 가르키고 있었던 내용들을 다 기억하고 있음으로써내가 원하는 시점으로 다시 돌아갈 수 있다.다시 git reflog해보면 방금 한 기록들을 볼 수 있다. 주의!!아직 commit을 하지않은 경우에 git r

master branch에 나의 기능을 merge한 다음에제품에 release가 됐음에도 불구하고 뒤늦게 그 기능에 문제가생겼다던지 무언가 원치않는 문제가 생긴 경우에해당하는 commit을 완전히 제거해야하는 경우가 있다.이럴 경우 문제가 되는 commit을 rever

기존에 존재하는 history를 간편하게 history를 변경하는 기술WIP을 다른 commit 메시지로 변경하고 싶다면WIP이 가르키는 이전 해시코드부터 시작해야 함지정한 해시코드 그 다음에 이어지는 모든 commit등이 vscode에 나온다.여기서 commit은 그

표시한 저 부분을 삭제하고 싶다고 가정하자.삭제하고 싶은 commit의 이전의 commit부터 선택 commit을 완전히 제거하고 싶은 것이므로 drop을 선택하여 저장한다.여기서 conflict이 발생한다.. commit에 있던 payment-ui.txt파일이 Ad

여기서 Add payment library and Add payment service라는 commit을 2개로 나누기로 하였다고 가정하자.여기서 commit을 edit하고 싶은 것이므로edit으로 바꾸고 저장한다. 저장하고 git hist를 확인해보면 HEAD가 바뀌어

저 4개의 commit을 하나의 commit으로 합치고Add payment service라는 이름으로 하고 싶다고 가정하자.이전의 commit까지 선택을 하면서 rebase 총 4개를 하나로 묶는 것이다. 제일 위에 있는 commit은 pick하고나머지는 squash로

협업을 위해 remote라는 서버에 나의 git repository 업로드해두어서항상 다른 PC에서도 접근이 가능하고다른 개발자들과 함께 일을 하기위해 서버를 이용한다.서버에 업데이트된 내용을나의 서버에 업데이트하고 싶다면

github에서 test라는 파일에 add를 추가했다.clone을 하기위해 링크를 복사한다.server에 있는 파일을 내 로컬에 clone하기 위해내 로컬 터미널에 git clone 명령어를 입력한다. test라는 디렉토리가 있는 것을 확인할 수 있다.test-proj

test라는 폴더에 add.txt를 추가하고 commit하기 origin/main과 origin/HEAD가 가리키는 포인터는2번째 commit을 가리키고 있다.즉, github 서버에는 2번째 commit까지 올라가있다. 현재 로컬에 있는 HEAD는 3번째를 가리키고

server에 push를 할 때마다 아이디와 비밀번호를 치는 것은 번거롭다.간편하고 자동적이며 안전한 방법 : SSH Key(Secure Shell Protocol)원격 호스트에 접속하기위해 사용되는 보안 프로토콜우리가 사용하고있는 서버간에 안전하게 아이디와 비밀번호를

github 서버에서 add.txt에 연필모양을 눌러 수정하고 commit을 만든다. github의 commit을 확인하면 Edited by Github commit이 생성된 것을 확인할 수 있다. 내 로컬 터미널에서 git hist를 통해 확인해보면3개의 commit

fetch로 history를 업데이트하지만내가 현재 바라보고 있는 작업환경 HEAD는 그대로 유지된다.c라는 commit을 가지고 있지만 여전히 나의 로컬 master branch는b를 가리키고 있는 것을 확인할 수 있다. 서버에 있는 history를 가지고 오면서나의

서버에서 add.txt를 수정하고 새로운 commit을 만들었다. 서버에 있는 history를 가지고온다.현재 test 디렉토리 안에 내 로컬에는 새로운 commit이 보이지않는다. 서버에 있는 history를 가지고 오기 위해서 fetch 명령어를 사용한다. 새로운

만약 서버에 있는 내용을 받아와서나의 로컬버전도 서버와 함께 동일하게 만들고 싶다면 git pull 사용내 로컬에 있는 HEAD와 서버에 있는 HEAD들이동일한 commit을 가리키고 있기 때문에내 로컬과 서버는 동기화가 잘 된 것을 확인할 수 있다.로컬과 서버에서 각

나의 계정에 project가 fork!!git clone 참여하고 싶은 프로벡트 복사한 주소cd 해당하는 프로젝트 폴더 안으로 들어가기git hist 오픈소스 프로젝트에서 진행중인 commit들을 확인할 수 있다 git switch -C fixfix라는 branch를

언제 누가 작업했는 지 기록들이 나온다.vscode 확장프로그램git lens 설치하면 더 편리하다. 문제의 원인을 빠르게 찾는법git bisect이전에는 잘 동작했는데 요즘들어 잘 동작하지 않는 것 같을 때다 찾고 확인했다면 git bisect reset하면 원래 b

프로젝트의 버전을 쉽게 관리하기위해서github와 같은 서버에 올려둠으로써 다른 사람들과 협업이 잘 될수있도록 이용

git init : 현재 디렉토리를 Git이 관리하는 프로젝트 디렉토리(=working directory)로 설정하고 그 안에 레포지토리(.git 디렉토리) 생성git config user.name 'codeit' : 현재 사용자의 아이디를 'codeit'으로 설정(커

git reset 옵션 커밋아이디git reset --hard 커밋아이디working directory : 커밋아이디 커밋처럼 바뀜staging area : 커밋아디이 커밋처럼 바뀜repository : HEAD가 커밋아이디 가리킴git reset --mixed 커밋아

git log : 커밋 히스토리를 출력git log --pretty=oneline :\--pretty 옵션을 사용하면 커밋 히스토리를 다양한 방식으로 출력할 수 있다.\--pretty 옵션에 oneline이라는 값을 주면 커밋 하나당 한 줄씩 출력해준다.git show

conflict도 파일 여러 개에서 나는 경우가 많다.이런 경우에는 파일 하나일 때와 같다.예)어떤 상품의 정보를 담기 위한 파일 3가지(price, after_service, size)를 만들었다.각 브랜치에서 서로 다르게 커밋을 한다.master 브랜치와 premi

HEAD가 가리키던 브랜치가 다른 커밋을 가리키도록 한다.HEAD도 결국 간접적으로 다른 커밋을 가리키게되는 효과가 생긴다.HEAD 자체가 다른 커밋이나 브랜치를 가리키도록 한다.브랜치를 통하지 않고, 커밋을 직접적으로 가리키는 HEAD를 Detached HEAD라고

git branch 새 브랜치 이름 : 새로운 브랜치를 생성git checkout -b 새 브랜치 이름 : 새로운 브랜치를 생성하고 그 브랜치로 바로 이동git branch -d 기존 브랜치 이름 : 브랜치 삭제git checkout 기존 브랜치 이름 : 그 브랜치로

리모트 레포지토리에서 가져온 브렌치의 내용을merge하기 전에 점검해야할 필요가 있을 때 사용리모트 레포지토리에 있는 브렌치의 내용과 내가 작성한 코드를 비교해서 잘못된 부분이 없는지 검토해야할 때git diff로 확인하면된다. git pull = git fetch +

git fetch : 로컬 레포지토리에서 현재 HEAD가 가리키는 브랜치의 업스트림(upstream) 브랜치로부터 최신 커밋들을 가져옴(가져오기만 한다는 점에서, 가져와서 머지까지 하는 git pull과는 차이가 있음)git blame : 특정 파일의 내용 한줄한줄이

rebase는 새로운 커밋을 만들지 않는다. rebase로 만들어진 커밋 히스토리는 merge로 만들어진 커밋 히스토리보다 좀 더 깔끔하다. rebase나 merge나 결과물은 똑같다.커밋 히스토리를 깔끔하게 만들려고 rebase를 사용한다. merge두 브랜치를 합쳤

어떤 브랜치에서 하던 작업을 아직 커밋하지 않았는데다른 브랜치로 가야하는 상황에서 작업 중이던 내용을 잠깐 저장하고 싶을 때최근 커밋 이후로 작업했던 내용은 모두 스택에 옮겨지고working directory 내부는 다시 최근 커밋의 상태로 초기화스택에 있는 내용을 다

cherry-pick : 좋은 것만 골라먹다. cherry-picker : 본인에게 유리한 것만 선택하는 사람자신이 원하는 작업이 들어있는 커밋들만 가져와서 현재 브랜치에 추가git cherry-pick 가져오고싶은 커밋 아이디

git init : 현재 디렉토리를 Git이 관리하는 프로젝트 디렉토리(=working directory)로 설정하고 그 안에 레포지토리(.git 디렉토리) 생성git config user.name 'song' : 현재 사용자의 아이디를 'song'으로 설정(커밋할 때