Git (18) 썸네일형 리스트형 [Git] 명령어 정리 $ git init : 현재 디렉터리를 워킹디렉터리로 지정, 레포지터리 생성 $ git config user.name '이름' : 맨 처음 커밋하기 전에 사용자 이름 설정 $ git config user.email '이메일' : 이메일 설정 $ git add 파일이름 : 특정 파일의 수정사항을 staging area로 옮김 $ git add . : 워킹 디렉터리 내의 수정사항이 있는 모든 파일들을 staging area로 옮김 $ git reset 파일이름 : staging area에 올렸던 파일 다시 내리기 $ git status : 깃이 현재 인식하고 있는 프로젝트 관련 내용들을 출력 $ git commit -m "커밋 메시지" : staging area에 있는 내용을 커밋 $ git push -u .. [Git] 작업 내용 임시 저장하기 - stash 마스터 브랜치에서 작업을 하다가 아직 커밋을 하지 않았는데 급하게 다른 브랜치로 가야할 일이 생길 수 있습니다. 물론 커밋을 하고 가면 되겠지만 작업이 끝나지도 않았는데 커밋을 하면 쓸모없겠죠? ' git stash ' 를 입력하면 최신 커밋 이후의 작업들을 저장할 수 있습니다. 마스터 브랜치에서 미완성된 팩토리얼 함수를 커밋하지 않고 highlevel 브랜치로 이동해보겠습니다. 저는 커밋을 하고 싶지 않은데 checkout 전에 커밋을 하라는 오류가 뜨네요? git stash 명령어를 입력하고 다시 이동해보겠습니다. 잘 되네요. highlevel 브랜치에서 작업이 다 끝나고 다시 마스터 브랜치로 돌아갔다고 가정하겠습니다. stash에 저장된 작업물을 다시 불러오려면 ' git stash apply ' .. [Git] remote repository에 올라간 커밋 취소하기 제목이 조금 이상하게 느껴지셨을 수도 있습니다. 커밋을 취소하려면 리셋을 쓰면 되지 않을까요? 반은 맞지만 반은 틀린 말입니다. 만약 로컬 레포지터리에서만 작업을 하는 상황이면 리셋을 사용하면 됩니다. 하지만 리모트 레포지터리에서 같이 작업을 할 때는 리셋을 쓸 수가 없습니다. 그 이유를 살펴보겠습니다. 아래 그림은 리모트 레포지터리에서 내용을 수정하고 커밋을 한 뒤에 로컬 레포지터리에 푸쉬를 한 상황입니다. 세 번째 커밋으로 reset을 하면 아래 그림과 같을 것입니다. 자 그런데 이 상태에서 푸시를 하면 어떻게 될까요? 당연히 오류가 나겠죠! 왜냐하면 리모트 레포지터리에 더 최신 커밋이 있기 때문입니다. 그럼....어떻게 하면 리모트 레포지터리에서 세 번째 커밋으로 돌아갈 수 있을까요? 우선 저희.. [Git] 누가 기록했는지 확인하기 이번 글은 아주 짧습니다. 협업을 하다가 특정 코드를 누가 작성했는지 알고싶을때가 있습니다. 이럴때 git blame 명령어를 사용하면 됩니다. print.py 코드로 한번 살펴보겠습니다. 가장 왼쪽에 커밋 아이디가 있습니다. 괄호 안에는 누가 언제 코드를 작성했는지 확인할 수 있습니다. 커밋 단위로 더 자세하게 보려면 show 명령어를 사용하면 됩니다. 커밋 아이디가 1216인 커밋을 한번 살펴보겠습니다. 이름과 이메일, 날짜, 시간, 코드 내용이 하나도 빠짐없이 나오네요. 실제로 협업할때는 커밋을 신중하게 해야겠네요! [Git] git pull시 주의점 만약에 로컬 레포지터리에서 푸시를 해주고 다음 푸시를 해주기 전에 리모트 레포지터리에 변화 생기면 어떡할까요? 한번 해보겠습니다. 먼저 깃허브로 가서 마스터 브랜치의 내용을 수정해보겠습니다. 연핀 모양의 기호를 클릭하면 수정할 수 있습니다. 나누기 함수를 추가해주고 커밋을 해보겠습니다. 이제 로컬 레포지터리에서 이름이 다른 나누기 함수를 추가해보겠습니다. 커밋을 한 뒤에 푸시를 해보겠습니다. 에러가 뜨네요.. 이처럼 리모트 레포지터리에 변화가 생긴 경우 push를 하게 되면 오류가 납니다. 이를 해결해주기 위해서는 pull을 먼저 해주고 내용을 고친 뒤에 다시 푸시를 해주면 됩니다. 풀을 해보겠습니다. 그런데 merge conflict가 발생했습니다! 그 이유는 리모트 레포지터리의 최신 커밋들을 .. [Git] merge 완전정복 이번 시간에는 머지(merge)를 자세히 다뤄보겠습니다. 두 브랜치를 머지하면 머지 커밋이 생성됩니다. 하지만 새로운 커밋이 생성되지 않는 머지도 있습니다. 이를 'fast-forward 머지'라고 합니다. 머지 커밋이 생성되는 머지는 '3-way 머지'라고 합니다. 하나씩 설명드리겠습니다. [1] fast forward merge 아래 그림과 같이 브랜치가 아직 분기되지 않은 상태에서 머지를 하면 새로운 커밋이 생성되지 않습니다. 마스터 브랜치를 하이레벨 브랜치와 머지해주면 마스터 브랜치가 이동만 하고 끝입니다. 그러니깐 위 상태에서 머지를 해주면 아래처럼 됩니다. 새로운 커밋이 생성되지 않았죠? 그러면 새로운 커밋이 생성되는 머지를 살펴보겠습니다. [2] 3-way merge 분기된 상태에서 브랜.. [Git] Reset vs Checkout 결론부터 말하자면 reset은 브랜치의 이동이고 checkout은 해드의 이동입니다. [1] reset reset은 브랜치의 이동입니다. 브랜치가 이동하면서 HEAD도 같이 이동하게 됩니다. 총 네 개의 커밋을 한 상황이라고 가정하겠습니다. 여기서 reset --[옵션] 해쉬아이디 명령어를 통해 이전 커밋으로 돌아갈 수 있습니다. ec3b로 돌아가면 아래와 같이 되겠죠. reset은 이게 끝입니다. 별거 없죠.. reset은 세 가지 옵션을 잘 이해하시는게 중요합니다. 참고로 reset을 한다고 이후의 커밋이 다 지워지지는 않습니다. 이전 커밋으로 리셋한 뒤에 이후 커밋으로 다시 리셋할 수 있습니다. 위 사진의 경우 asd8 커밋으로 다시 돌아갈 수 있습니다. 커밋 이력을 보고싶으면 ' git .. [Git] HEAD와 branch의 관계 사실 HEAD와 branch는 포인터입니다. 포인터는 무엇을 가리키는 것을 말합니다. 이전에 HEAD를 설명할 때 HEAD는 커밋을 가리킨다고 했었죠? 하지만 엄밀하게 말하면 HEAD는 브랜치를 통해 간접적으로 커밋을 가리키고 있습니다. 항상 그런건 아니지만 대부분 그렇습니다. 예외적인 부분은 checkout과 reset의 차이를 설명드릴 때 다시 다루겠습니다. 자, 그러면 HEAD와 branch는 어떻게 구성되어 있는지 그림으로 살펴보겠습니다. 이게 진짜 모습입니다. 커밋을 하면 HEAD가 가리키는 브랜치가 최신 커밋으로 이동하게 됩니다. 그럼 좀 더 나아가서 highlevel 브랜치를 만들면 어떻게 될까요? highlevel 브랜치를 만들면 아래 그림처럼 HEAD가 가리키던 커밋을 highlevel .. 이전 1 2 3 다음
