git

Git이란 버전 관리 시스템(version control system)입니다.여기서 이야기하는 버전은 무엇인가?게임을 하거나 앱을 쓰거나 할 때 보면 버전이란 게 있다. 명확하게 '버전은 무엇이다' 라고 말하기 어려워도버전이란 말은 우리에게 익숙합니다버전이란 쉽게 이야

Git에 대해 대충 알아봤으니 Git을 설치해봅시다.저는 windows 환경이라 git-for-windows에서 Git을 다운로드 하겠습니다.https://gitforwindows.org/여기서 다운로드 하실 수 있습니다.windows에서 설치하시면 알다시피

이전 포스팅과 이어집니다. 자, 이제 git repo도 만들어 봤으니 git이 어떻게 우리의 작업 내용을 관리해주는지 알아봅시다. ✔️git status, git add, git commit 현재 우리의 git repo에 아무것도 없습니다. 오늘 날짜로 일기를 한

이전 포스팅과 이어집니다.이전 포스팅에서는 git repo에서 파일을 만들어 작업하고, commit을 해보았습니다.또 파일을 수정하고 나서 commit도 해보았습니다.이 과정에서 working tree, untracked files 등등의 용어가 나왔는데 이에 대해 알

깃에서 브랜치는 특정 커밋을 가리키는 포인터입니다.git init 을 실행하여 현재 작업 공간을 git repo로 만들었다고 가정해봅시다.master 브랜치가 생성되었고 세 개의 커밋을 진행한 상태를 생각해봅시다.이 다음에 새로운 testing이라는 새로운 깃 브랜치를

https://www.udemy.com/course/git-and-github-bootcamp/ ✔️git merge 다른 브랜치를 현재 브랜치에 병합하는 것을 git merge 라고 합니다. 두 개의 브랜치가 존재합니다. bugfix 브랜치는 master 브랜

깃에서 병합시 충돌이 발생할 수 있습니다.A라는 브랜치가 있고 B라는 브랜치가 있다고 가정합시다.A 브랜치에 B 브랜치의 모든 커밋을 병합하려고 합니다.하지만 병합하려고 git merge B 를 실행했는데 A 브랜치에서 작업한 내용과 B 브랜치에서 작업한 내용에서 충돌

git diff 를 실행하여 변경 이전과 이후를 비교할 수 있습니다.git diff 는 발생한 변경사항 중 staging area에 올라가지 않은 변경사항들에 대해서 보여줍니다.git diff HEAD 는 마지막 커밋 이후 발생한 모든 변경사항을 보여줍니다.커밋 이후

git stash를 이용해서 변경 사항들을 임시 저장할 수 있습니다.master 브랜치에서 작업하다가 커밋을 하고, 새로운 브랜치를 만들어서 새로운 브랜치로 이동한 후 여러 변경사항들을 만들었다고 가정합시다.이 변경사항들을 아직 커밋하지 않았는데, 다시 master 브

우선 git repo를 만듭니다.diary.txt 파일을 만들고 내용을 작성합니다I love my boss해당 내용을 커밋합니다.the-truth라는 브랜치를 만들어 이동합니다.이제 diary.txt에 있던 내용을 지우고 진실을 작성하고 저장합니다.멀리서 대표님이 이쪽

git checkout으로 이전 커밋으로 돌아갈 수 있습니다.git log 를 실행하여 커밋 이력들을 확인할 수 있고 또한 커밋 해시까지 확인할 수 있습니다.커밋해시는 앞의 7자리만 복사해서 사용할 수도 있습니다.git log --oneline 으로 짧게 커밋 이력 확

HEAD는 브랜치를 가리키는 포인터라고 하였습니다.detached HEAD 상태라면 다른 커밋을 가리키기도 합니다.여기선 일단 브랜치를 가리킨다고 생각하고 진행합시다.git checkout HEAD현재 발생한 모든 변경사항을 취소합니다.HEAD가 마지막 커밋을 가리키니

만약 master 브랜치에서 작업하고 몇 개의 커밋을 했다고 가정합시다.그런데 이 작업을 master 브랜치에서 하면 안되는 상황인 걸 늦게 깨달았습니다.근데 이미 master 브랜치에서 커밋을 몇 번 진행했습니다.이 커밋들을 지워야하는데 그냥 지워버리면 너무 아깝습니

git reset, git revert 연습을 해봅시다.현재 lyrics.txt라는 파일이 존재하고 8개의 커밋 이력이 있습니다.여기서 첫 번째 커밋으로 돌아가보도록 하겠습니다.현재 'detached HEAD' 상태에 있다고 깃이 얘기해주고 있습니다.첫 번째 커밋의 내

깃허브는 깃 저장소를 위한 호스팅 플랫폼 웹 서비스입니다. 깃허브는 클라우드에 우리의 git repo를 저장해줍니다.그럼 깃은 무엇일까요? 깃은 로컬 컴퓨터에서 실행하는 version control system입니다.그럼 Github를 왜 사용할까요?백업이 가능합니다.

git clone은 내 컴퓨터에 없는 저장소를 복사해오는 명령어입니다.입력한 url에 있는 저장소의 내용을 다운로드 하는 것입니다.

이전 포스팅과 이어집니다.지금까지의 과정을 생각해봅시다.우선 깃허브에서 새로운 repository를 생성했습니다.그리고 이 repository를 우리의 local repo와 연결했습니다. (git remote add 를 이용해서 연결했습니다).이제 우리의 local r

git push git remote 등 깃허브 원격 저장소를 생성하고, 로컬 저장소와 원격 저장소의 연결과 변경사항 업로드 등의 깃허브 기초를 연습해보겠습니다.우선 local repo를 하나 생성해봅시다.Github repo도 하나 생성하고 local repo와 연결해

지금까지 원격 저장소를 clone하거나, 로컬 저장소의 변경 내용(커밋)을 원격 저장소로 업로드(push) 하는 것에 대해 알아봤고그 기본 workflow에 대해 연습도 해보았습니다.이번에 알아볼 내용은 원격 저장소 내용을 로컬 저장소로 내려받는 pull 과 fetch

삭제하고 싶은 브랜치 위에 있는 경우에 삭제가 되지 않는다. 다른 브랜치로 이동 후 삭제해야 한다.또한 브랜치 삭제는 완전히 병합된 브랜치만 삭제가 가능하다.브랜치 이름 변경은 이름을 바꾸고자 하는 브랜치 위에 있어야 변경이 가능하다.그렇지 않은 경우 변경할 브랜치를

✔️공개 공개 저장소는 인터넷의 모든 사람이 저장소를 볼 수 있고, clone 할 수 있습니다. 하지만 앞에서도 설명했듯이 누구나 clone 한 저장소에 push 할 수는 없습니다. 공동 작업자 권한이 있거나 허가 받은 사람만 push 가 가능합니다. ✔️비공개

git rebase는 꼭 알아야 하는 것은 아니지만 알아두면 매우 유용한 기능입니다.꼭 알아야 하는 것은 아니라고 말한 이유는 굳이 rebase를 몰라도 깃을 사용하는데 문제가 없기 때문입니다.git rebase 를 사용하는 이유는 크게 두 가지 입니다.git merg