GIT

은 누가 만들었을까요? 바로 리누스 토발즈(Linus Torvalds)라는 사람이 만들었습니다.리누스 토발즈는 리눅스(Linux)라고 하는 운영 체제를 만든 사람인데요.혹시 운영 체제가 뭔지, 리눅스가 뭔지 모르는 분은 코드잇의 다음 레슨들을 참고하세요.애플리케이션을

이전 영상에서는 내용을 수정한 파일 중에서 커밋에 반영하고 싶은 파일은 git add를 해야한다고 했습니다. 그런데 사실 이것과 관련해서 꼭 알아야할 사실이 하나 있습니다. 이 사실을 확실히 이해하고 암기해야 앞으로 깃을 사용할 때 어려움이 없습니다. 자, 그럼 설명할

이전 노트에서 Git의 3가지 작업 영역을 배웠습니다.작업 영역과 관련해서 한 가지 더 알아두면 좋은 내용이 있는데요.그건 바로 Git으로 관리되는 파일은 일종의 '상태(status)'라는 걸 가진다는 사실입니다.일단 Git에서 파일들은 크게 다음 2가지 상태를 가집니

이번 챕터에서 배운 커맨드들을 정리해볼게요.현재 디렉토리를 Git이 관리하는 프로젝트 디렉토리(=working directory)로 설정하고 그 안에 레포지토리(.git 디렉토리) 생성현재 사용자의 아이디를 'codeit'으로 설정(커밋할 때 필요한 정보)git con

로컬 레포지토리(Local Repository)의 최신 내용을 리모트 레포지토리(Remote Repository)에도 반영하려면를 해야한다고 배웠습니다. 그런데 여기서 잠깐 궁금한 점이 하나 생깁니다.그렇다면 아무나 git push라고만 쓰면 자신이 작업한 내용을 저의

아래 사이트들은 Markdown을 실시간으로 사용해볼 수 있는 온라인 서비스입니다.Dillinger링크텍스트Stackedit링크텍스트(https://stackedit.io/app하나씩 배울 때마다 직접 연습해 보세요.이것은 일반 글입니다.아래처럼 적으면 번호가

커밋(commit)은 Git에서 가장 핵심적인 개념입니다. 커밋은 staging area의 현 상태를 그대로 하나의 버전으로 남기는 작업, 또는 그 결과물을 가리키는 말이라고 했는데요.커밋에는 크게 다음과 같은 3가지 정보가 있습니다.(1) 커밋을 한 사용자 아이디(2

자, 이제부터는 git reset 커맨드에 대해서 좀더 깊게 배워볼 건데요. 그 전에 꼭 확실하게 알고 넘어가야할 사실 2가지를 말씀드리겠습니다.이전 영상에서 git reset을 했더니HEAD가 과거의 커밋을 가리키게 되었고working directory의 내부도 그

git reset을 할 때는 보통 아래와 같은 형식으로 쓰는데요.git reset 옵션그런데 이렇게 커밋 아이디를 쓰려면 매번 커밋 아이디를 찾아야한다는 불편함이 조금 있습니다. 사실 커밋 아이디 자리에 다른 걸 써줘도 되는데요.예를 들어 이런 커밋 히스토리가 있다고

우리는 커밋을 할 때 해당 커밋에 관한 정보를 커밋 메시지로 남기는데요. 그런데 커밋 중에서는 다른 것들보다 좀더 중요한 의미가 있는 커밋들도 있습니다. 이런 중요한 커밋에는 커밋 메시지뿐만 아니라 태그(tag)라는 것을 추가적으로 달기도 합니다.보통 프로젝트에서 주요

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

이전 영상에서는 premium 브랜치에서 master 브랜치를 머지(merge)하다가 Conflict가 발생했고, 저는 그것을 해결하고 머지에 성공했습니다.하지만 꼭 이렇게 Conflict를 해결하지 않고, 일단 merge 자체를 취소하는 방법도 있습니다.이전 영상에서

이전 영상에서는 파일 하나에서 conflict가 발생하는 상황을 봤습니다. 하지만 개발 실무에서는 파일 여러 개를 수정하는 경우가 많다보니 머지할 때 conflict도 파일 여러 개에서 나는 경우가 많습니다. 이럴 땐 어떻게 해야할까요? 원리는 파일 하나일 때와 같습니

이번에는 브랜치(branch)에 대해 좀더 많은 것들을 배워보겠습니다.여러분, 혹시 3. GitHub 시작하기 챕터의 '02. Local Repository의 내용을 Remote Repository로 보내기' 레슨에서 했던 작업, 기억나시나요?저는 그때GitHub에서

이전 영상에서는사실 브랜치(branch)는 커밋을 가리키는 존재(포인터)이고,HEAD는 이런 브랜치를 통해 커밋을 간접적으로 가리키는 존재(포인터)라고 배웠습니다.자, 이제 이 사실을 안다면 우리가 이전에 배운git reset커맨드의 동작 원리를 더욱 정확하게 알 수

이전 노트에서는 아래 그림과 같은 상태에서git reset 9033를 실행하면이 그림과 같은 결과가 된다고 했습니다. 이렇게 HEAD는 보통 본인이 직접 커밋을 가리키는 게 아니라 브랜치를 통해서 간접적으로 커밋을 가리킵니다.하지만 HEAD 자체가 가리키던 것을 바꿀

머지(merge)에 관한 좀더 깊은 이야기를 해볼게요. 머지를 하면 새로운 커밋이 생긴다고 했습니다.그리고 머지를 통해서 생겨난 커밋을 머지 커밋(merge commit)이라고 부른다고 했는데요.이 그림을 보면 지금 master 브랜치에서 premium 브랜치를 머지해

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

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

우리는 이때까지 CLI(Command Line Interface) 환경에서 Git을 사용해왔습니다.하지만 GUI(Graphic User Interface) 환경에서 Git을 사용하도록 도와주는 프로그램도 있는데요. GitKraken, Sourcetree 등 다양한 프로

이전 영상에서 배웠던 커맨드들을 잠깐 정리해볼게요.작업 내용 저장git stash2\. 작업 내용 조회(=스택 살펴보기)git stash list3\. 작업 내용 적용git stash apply 작업 내용의 아이디작업 내용의 아이디를 생략하면 가장 최근의 작업 내용이

우리는 working directory에 있는 파일들을git addgit commit하면서 프로젝트를 버전 관리합니다. 그런데 working directory 안에 있음에도 불구하고 Git에 의해 그 존재 자체가 무시되는 파일들이 있습니다.잠깐 아래 그림을 볼까요?지금

자, 이제 마지막 챕터까지 모든 내용을 마쳤습니다. 이때까지 배운 Git 커맨드를 챕터별로 한눈에 살펴볼까요?git init : 현재 디렉토리를 Git이 관리하는 프로젝트 디렉토리(=working directory)로 설정하고 그 안에 레포지토리(.git 디렉토리) 생

소프트웨어 프로젝트가 성장함에 따라 프로젝트 참여자들은 종종 예상치 못한 문제에 직면하게 됩니다. 특히 협업 과정은 프로젝트 규모가 작을 때는 문제없이 진행되는데, 규모가 커지게 되면 여러 문제들이 터져 나옵니다. 협업을 통해 이 문제들을 원활하게 해결하면 다행이지만,

이 토픽을 수강하고 계신 수강생분들이라면, 어느 정도 Git에 대해서 알고 계실 텐데요. 이 레슨에서는 Git에 대해 전반적인 개념을 정리하고, 앞선 지식들을 되짚어 보는 시간을 가져보도록 하겠습니다.Git에는 여러 가지 중요한 개념들이 있습니다. 그중에서도 Git을

GitHub는 개발자들에게 널리 알려진 원격 저장소 서비스입니다. 이전 토픽에서 이미 GitHub의 원격 저장소로서의 역할을 다룬 바 있죠. 이번 레슨에서는 GitHub의 다양한 기능들을 살펴보고자 합니다. GitHub는 단순히 코드를 저장하는 공간을 넘어, 개발자들의

여러분이 새로운 회사에 합류했다고 가정해 봅시다. 이미 엄청난 양의 코드가 존재하는 프로젝트에 첫발을 내딛게 되었습니다. 아무래도 처음이다 보니, 작성한 코드가 완벽하게 동작할지 확신하기 어려운데요. 과연 내가 작성한 코드에 버그는 없을까요? 운이 좋다면 한 번에 잘

이전 레슨에서는 Pull Request란 무엇이고, 어떤 장단점이 있는지 알아봤습니다. 또한 어떻게 Pull Request를 생성하는지도 알아봤습니다. 이전 레슨의 마지막 과정에서 merge pull request 라는 녹색 버튼을 확인할 수 있습니다.Merge Pul

여러분은 지금까지 레슨에서 PR을 만들고, 머지하는 방법까지 익혔습니다. 그 과정에서 머지의 다양한 방법도 배우고, 각각의 장단점도 함께 익히셨을 텐데요.이번 레슨에서는 Fork라는 새로운 개념을 익혀볼게요. Fork는 Git의 기능이 아니라 Git을 호스팅 하는 서비

지금까지 브랜치와 Fork로 Pull Request를 생성하고, 이를 머지하는 다양한 방법들에 대해서 다뤘습니다. 이 레슨에서는 머지시 충돌이 발생했을 때 해결하는 방법에 대해서 다루도록 하겠습니다.충돌이란?Git에서 충돌은 머지하는 과정에서 발생하는 현상입니다. 충돌