Git

코딩을 배우고 초보자를 벗어날 즈음 이런 이야기를 한 번씩은 들으실 겁니다. 'Git 등을 이용한 버전 관리를 시작하라'라고요. 이 시리즈에서는 가장 많이 사용되고, 대표격의 역할을 하는 Git에 대해서 다뤄보도록하겠습니다.또한 Git을 온라인에서 저장하고, 관리할 수

Git Bash는 유닉스를 기반으로 이루어졌기 때문에, 유닉스 계열 명령어가 종종 등장합니다. 등장하는 경우 해당 명령어를 소개해드리고 넘어갈 예정이니 걱정없이 따라오셔도 됩니다.또한, Window 10 운영체제를 기준으로 포스트가 작성되었습니다.지난 포스트에서 Git

지난번은 Git을 시작하는 방법에 대해 알아봤었습니다. 이번에는 본격적으로 깃을 사용하기 앞서, 깃에서 사용되는 용어들에 대해 알아보고 넘어가도록 하겠습니다. 앞으로도 쭉 등장하는 용어이니만큼 이론이라고 넘기지 말고 같이 공부해봅시다.Version, 버전이라는 말은 프

응? 여기 Git을 소개하는 카테고리 아니었나요. 갑자기 Vim은 뭐죠???잘못 오신 것이 아닙니다. 사실 vim을 아시면 좋고, 아니면 기존 메모장 등을 이용하라고 하려고 했는데 작성하다보니 vim을 사용하는 것이 압도적으로 편하고, 커밋 과정에서 vim이 등장해서

스테이징은 작업 공간에서 작업을 하고 그 파일을 버전 관리를 위해 스테이지로 옮기는 것을 말합니다. 이 작업은 파일 관리의 첫 단계라고도 할 수 있습니다.먼저 vim으로 git Bash상에서 텍스트 파일을 만듭니다. 이때 파일의 내용은 저를 그대로 따라오셔도 좋고 본인

커밋(Commit)이란, Git에서 버전을 만드는 과정입니다. 커밋에서는 간단한 메세지를 달 수 있는데, 이 메세지를 통해 버전에서 어떤 수정사항이 있었는지를 간단히 적게 되어 본격적인 버전 관리를 하는 단계입니다.우선 커밋을 하기 위해서는 스테이징된 파일이 필요합니다

지난 포스트에서 커밋을 해 버전을 만드는 방법을 알아보았습니다. 우리가 버전 관리를 위해 깃을 사용하는 이유에서는 변경 내용을 확인하기 위해서라는 점이 있었습니다. 그래서 이번엔 커밋된 파일의 변경 사항을 확인하는 방법을 알아보려고 합니다.git diff는 변경된 파일

.gitignore 파일은 버전 관리를 할 필요가 없어서 원격 저장소에 업로드 하거나 스테이징/커밋할 필요가 없는 폴더 혹은 파일들을 추적에서 제외시키는 파일입니다. 대표적으로는 인텔리제이 계열 개발환경을 이용하신다면, 로컬 개발환경의 세팅을 담은 .idea 파일이라던

이번엔 커밋을 취소하는 방법에 대해서 알아보겠습니다.가장 최신 커밋만 취소하고 싶다면 git reset명령을 이용합니다.우선 vim으로 다음과 같이 한 줄을 추가 하고 'git commit -am'명령으로 커밋까지 완료 해보겠습니다.이렇게 커밋이 완료되고 방금한 커밋이

앞서 알아본 git log는 이전에 실시했던 모든 커밋 로그를 확인합니다. log가 너무 많아질 경우 보기에 불편하다는 점과 커밋 메세지, 작성자 정도만 표시해줍니다. 그렇다면 커밋 기록의 상세한 정보는 어떻게 확인할까요?커밋의 상세한 기록을 확인하기 위해서 git s

가장 최근의 커밋 메세지를 수정하는 방법은 git commit명령에 --amend옵션을 더합니다.이 명령을 이용하면 다음과 같이 vim창이 뜹니다. 이때 첫 번째 줄이 기존의 커밋 메세지 이므로 해당 부분을 수정하시면 됩니다.수정 후 git log 명령으로 변경된 커밋

파일을 만들고 커밋하기까지의 과정에서 깃은 여러 파일 상태를 가지고 변화해나갑니다. 다양한 상태가 있지만 우선 가장 크게 나눌 수 있는 추적(tracked)과 미추적(untracked)파일에 대해서 설명하려고 합니다.버전 관리 과정에서 가장 크게 나눌 수 있는 상태입니

지난 포스트에서 untracked와 tracked 상태를 알아보았습니다. 그리고 tracked 상태는 커밋 진행과정에 따라 세부적인 상태로 나뉜다고 했었는데 이번 포스트에선 그 상태들에 대해서 알아보도록 하겠습니다.unmodified, 즉 수정되지 않은 상태를 의미합니

일반적으로 브랜치 라고 함은 '나뭇가지'를 떠올리게 됩니다. 하나의 나무 줄기에서 여러개의 가지로 뻗듯이 버전 관리 시스템에서 파일들의 갈래(흐름)을 의미하고 있습니다. 파일 시스템으로 이야기하자면 하나의 파일로 부터 여러개의 파일로 나누어 분산 작업을 진행하는 것 입

브랜치를 만드는 명령어는 다음과 같습니다.임의로 브랜치 이름을 지었습니다. 현재 리포지토리의 브랜치를 확인하기 위해서sms git branch명령을 이용합니다.확인해보면, 현재 기본 작업공간인 master 아래에 방금전에 새로 만든 spring이라는 이름의 브랜치가 생

어떤 파일을 수정하다가 현재 파일의 수정사항은 제외하고 다른 파일을 커밋하고 싶은 경우가 있습니다. 물론 명령어를 통해 다른 파일들만 커밋할 수는 있지만 그렇게 되면 계속 커밋 메세지가 날아와서 번거롭죠. 또는 뇌빼기 코딩하다 무지성으로 git commit -am 해버

기존의 git log명령은 단순히 git으로 작업했던 내용들을 보는 정도였습니다. 커밋 메세지나, 변경 시간, 수정한 사람 등에 대한 정보를 확인할 수 있었습니다. 이런 git log 명령에 옵션을 더하면 브랜치에 대한 정보를 쉽게 얻을 수 있습니다.우리가 사용하는 g

깃에서 병합(Merge)이란, 여러 갈래로 나눴던 브랜치들을 다시 하나로 합치는 것을 의미합니다.병합이라는 단어와 개념자체는 어렵지 않으나, 실제로 사용하는 것은 조금 어렵게 느껴집니다. 그럼 병합을 실습해보겠습니다.실습을 위해 이전 포스트에서 사용하던 파일 구조에 a

브랜치 삭제는 branch 명령의 옵션으로 할 수 있습니다. delete의 약자로 d를 사용해서 브랜치를 삭제하는 옵션을 켤 수 있습니다.위 사진에서 보이는 b1 브랜치를 삭제 명령으로 삭제 해보겠습니다.브랜치가 삭제되어도 같은 이름의 브랜치를 생성한다면 삭제 하기 이

그동안 git bash를 이용한 터미널 콘솔 상에서 명령어를 통해서 깃에 대한 기초를 알아보고 배웠었습니다. 그러다보니 깃의 명령어를 알아두고 외워야하며, 터미널에 익숙치 않은 경우에 어려움을 겪을 수 있습니다. 그래서 등장한 것이 GUI 툴 입니다. GUI를 이용하면

소스트리에서 작업을 하기 위해서는 먼저 리포지토리를 가져와야합니다.리포지토리는 크게 두 가지가 있습니다. 리포지토리는 사용자의 컴퓨터 저장소에 저장되어있는 지역 저장소(local repository)와 깃 허브 등의 온라인 서비스에 저장되어 있는 원격 저장소(remot

앞에서 몇 개의 포스트들을 거치며 깃을 익히는 동안 저희는 사용자의 컴퓨터 내부 저장공간에 작업 파일을 만들고 작업했습니다. 이것을 지역 저장소(local repository)라고 불렀습니다. 우리가 작업을 하다가 지역 저장소가 담긴 저장장치가 고장이 난다거나, 삭제해

이 포스트를 시작하기 전에 GitHub 홈페이지에서 회원가입을 완료해 주세요.회원가입을 진행한 후 깃허브에 로그인을 하게되면, 상단에 +표시가 있습니다.+표시를 누르고 New repository를 선택합니다.선택하면 다음과 같은 입력란이 나오게 됩니다.저장소 이름: 저

우선 파일을 올리는 방법을 알아보도록 하겠습니다.지역 저장소의 파일들을 원격 저장소에 올리는 작업을 푸시(push)라고 부릅니다. 그래서 명령어에도 push가 들어가게 됩니다.push를 하기전에, 우리는 저장소를 처음 만들었으므로 추가작업을 한 가지 해주어야합니다.이

저도 이 포스트 시리즈를 작성하며 공부하고, 깃을 쓰다보니 어느순간 다음과 같은 문제점이 보입니다.자, 여기서 css, html, jasmine\~~, js, txt파일은 필요한 파일들 입니다. 그런데 .idea는 필요가 없음에도 불구하고 올라갔습니다. .idea는 젯

깃과 원격 저장소는 단순히 클라우드로 사용할 수도 있지만, 그 진가는 협업에서 나타납니다. 여태까지는 혼자서 깃을 만들고 커밋하고 업로드했다면, 이번에는 많은 사람들과 원격 저장소를 이용할 수 있는 방법을 알아보겠습니다.사용법은 위와 같습니다. 이때 복사하고자 하는 위

예전 포스트에서 두 브랜치를 병합하는 방법을 간단하게만 다뤘습니다. 오늘 다룰 병합 방식은 Fast-Forward 병합 방식인데, 이 병합 방식이 무엇이고, 어떻게 이루어지는지 알아보도록하겠습니다.Fast-Forward는 가장 간단한 병합 방식입니다. 이 방식은 혼자

3-way 병합 지난 포스트에서 다룬 Fast-Forward 병합은 순차적으로 분기되어 작업된 브랜치를 병합하는데 사용한 병합 방식이었습니다. 작업이 순차적으로 진행되기 때문에 병합과정에서 따로 신경써야할 부분은 없었습니다. 오늘 다루는 3-way 병합은 좀 더 복잡

fetch는 git pull 명령처럼 원격 저장소로 부터 파일을 내려받는 명령입니다. pull은 내려받을 때 자동으로 병합을 해주었으나, fetch명령은 자동으로 병합이 되지 않습니다.fetch를 수행하게 되면 원격 저장소의 최신 커밋을 임시 브랜치로 내려받습니다. 그

충돌(conflict)는 병합 과정에서 일어나는 현상입니다. 깃으로 작업을 진행하면서 작업 파일의 같은 위치를 동시에 수정했을 경우 발생합니다. 혼자서 개발하는 경우 잘 일어나지 않지만, 여러명이서 개발하는 경우 제법 자주 볼 수 있습니다.충돌이 발생하는 경우 깃에서는

깃허브에 프로젝트를 만들고 결과물을 간단하게 보여주는 방법에는 글, 이미지, 움직이는 사진, 동영상 등이 있습니다. 이 중에서 저는 가장 효과적이면서도 편리하게 결과물을 보여주는 방법이 움직이는 사진(.gif, .webp 등)이라고 생각합니다.그래서 오늘은 깃허브 RE

깃허브의 리포토리를 만들면 상단에 다양한 탭들이 존재합니다.오늘은 이 탭들의 내용에 대해서 알아보도록 하겠습니다.Code 항목에는 프로젝트의 내용이 표시됩니다.소스 코드, 커밋 기록, 프로젝트의 세부 내용, README.md가 보여지게 됩니다.Issues탭에는 프로젝트

그동안 Git으로 버전 관리를 하거나 깃허브에 올릴만한 작업들이 아니어서 깃을 사용하지 않고 있다가 오랜만에 깃을 사용하려고 하니까 업데이트를 해보는게 어때?라고 깃이 물어보길래 업데이트를 하기로 했다.그리고 겸사겸사 업데이트 하는 방법도 메모해두기로 했다.우선 cmd