우리는 이전 글을 통해

  1. 원격 저장소에 있는 리파지토리를 로컬 저장소로 가져오는 방법(clone, pull)
  2. 로컬 저장소와 원격 저장소를 연결하는 방법(remote) 

에 대해 알아보았습니다.


 그런데 git clonegit pull, 이 둘은 어떤 차이가 있고 언제 사용하는 걸까요? 결론부터 말씀드리겠습니다.

git clone은 로컬 히스토리를 유지하지 않고, git pull은 로컬 히스토리를 유지합니다.

 

  특징 기존추적기록 remote merge 사용시기
git clone 원격 리파지토리를 그대로 복붙한다(copy). X O X 프로젝트 시작 시
git pull 내 상태를 유지하면서 원격 리파지토리 내용을 내려받는다. O X O 프로젝트 진행 중(작업 전)

 

 

 다음과 같이 git clone은 원격 저장소의 내용을 로컬 저장소에 그대로 이전시켜 버립니다. 이 때, 자동으로 원격 저장소(remote)의 이름이 'origin'으로 저장됩니다. 따라서 나중에 git fetch origin을 한다면 clone 이후 수정된 사항에 대해 업데이트할 수 있습니다.

 

git clone했을 때, 원격저장소 이름은 origin이 됩니다.

 

 

 git pull은 git clone과 비슷하게 내용을 이전시키는 것은 맞지만, 나의 branch의 상태를 유지하면서 내용만 내려받습니다. 이 때, 내 로컬 히스토리가 유지되는 상태이기 때문에 히스토리 싱크가 맞지 않으면 오류가 발생합니다. (병합 충돌)

→ 이로 인해 초보자의 경우, branch가 꼬이는 경우가 많아 git pull보다 git clone을 해버리는 경우가 왕왕 있습니다.

 

▽ git pull의 형식은 다음과 같습니다.

$ git pull [remote] [branch]

▽ 그리고 git clone과 동일한 작업을 수행하려면 다음과 같습니다.

$ git pull origin master

: remote의 이름을 origin, branch 이름을 master로 하면, 로컬의 master가 원격의 master를 추적하는 git clone과 동일한 작업을 수행할 수 있습니다.

 


git fetch


 사실 git clone과 git pull을 비교하기보다 git fetch와 git pull를 비교하는 게 일반적입니다.

 

$ git fetch [remote]

 : 로컬에는 없지만 원격 저장소에 있는 모든 데이터를 가지고 옵니다. 하지만, 자동으로 로컬 branch에 merge시키는 git pull과는 달리, 내용만 가져오는 것이기 때문에 merge를 따로 수행해야 합니다.

 

$ git checkout [병합할 줄기 branch]
$ git merge [병합당하는 가지 branch]

: 가지 branch 줄기 branch로 병합됩니다.

 

 이전 글을 통해 우리는 git clone, git pull을 이용해 원격 저장소에 있는 프로젝트를 로컬 저장소인 내 컴퓨터로 옮겨보았습니다.

 

그러면 내가 로컬 저장소에서 작업한 내용은 원격저장소까지 어떤 방식으로 업로드할 수 있을까요?

 

제목에서 알 수 있듯, git add, git commit, git push를 통해 우린 로컬저장소 → 원격저장소로 작업 내용을 업로드할 수 있습니다.

 

  • Working Directory : 작업 공간. 파일의 생성/수정/삭제가 이루어지는 공간.
  • Staging Area : 버전이 될 후보들이 올라오는 공간. commit을 하기 전 임시 저장되는 세이브 포인트.
  • Local Repository : 로컬 저장소. 
  • Remote Repository : 원격 저장소.

 

위의 일련의 과정을 과일추수에 빗대어 설명하자면, 다음과 같습니다.

 

git add : 다 익은 과일만(저장하고자 하는 파일)을 선별해 상자(임시저장소)에 담음.

git commit : 상자에 담긴 과일들을 창고(로컬 저장소)에 쌓음.

git push : 창고에 있는 과일상자들을 모두가 살 수 있는 마트(github-원격저장소)로 이동시킴.

 

(git pull은 과일 반품..?)

 

git status


 사실 git add, commit, push를 진행하기 전에 수행해야될 일들이 있습니다.

$ git status

: git status는 현재 git의 파일 관리상태를 알려줍니다.

 

▽ 현재 상태를 파악하게 해주는 3 문단.

 

  • 1문단 : 현재 당신의 branch는 origin/master입니다.
  • 2문단 : Staging Aread에 commit되지 않은 다음 파일(README.md)이 있습니다. 
  • 3문단 : Untracked files나 변경사항에 대해 알려줍니다. 또 이 파일들을 추가하기 위해 git add나 git commit -a를 이용하라고 설명합니다.

위 내용을 토대로 현재 나의 branch가 어떠한지, 어떤 파일이 commit되지 않았는지, 관리대상에 포함되지 않은 파일들은 없는지 확인이 가능합니다.

 

 

git add


 git add내가 추가하고자 하는 파일을 선택하는 과정으로 볼 수 있습니다.

 아직 관리 대상은 아니지만, 앞으로 관리할 대상을 선별하는 것이죠.

 

 

$ git add 파일경로

: 해당 경로에 있는 파일을 add합니다.

 

▽README.md를 수정한 뒤 status를 확인해보면, README.md가 Staged된 것을 볼 수 있습니다.

 

만약 잘못 add 했다면, 다음과 같은 명령어를 실행하면 됩니다.

$ git restore --staged 파일경로

: 해당 경로에 있는 파일의 staged 상태를 unstaged 상태로 변경합니다.

 

$ git add .

: 현재 디렉토리에 있는 모든 파일을 add합니다.

 

$ git add -A

: 프로젝트 내 모든 파일을 add합니다. (현재+상위 디렉토리)

 

 

 

git commit


 git add를 통해 선별된 파일들을 git commit을 이용하여 소스 관리 대상에 올립니다.(로컬 저장소에 저장됨)

commit에는 커밋 메세지가 들어갑니다. 이 메세지를 통해 팀원들이 해당 파일들이 어떤 기능 혹은 어떤 수정 등이 이루어졌는지 알 수 있습니다. 따라서 커밋 메세지는 현재 버전에 대한 내용을 명확하게 전달해야하기에 어느정도 정해진 형식을 지켜야 합니다.

 

$ git commit -m "커밋메세지"

: -m은 commit의 대표적인 옵션입니다. commit message가 중요한만큼 에디터를 통해 작성하는 경우가 있기 때문입니다.

  • -m : vim(에디터)에서 별도의 메세지를 작성할 필요없이 인라인 형식으로 바로 커밋 메세지 작성합니다.
  • -a : 수정된 파일에 대한 add와 commit을 한꺼번에 수행합니다. (한 번도 add되지 않은 파일은 add 후 -a 옵션적용이 가능합니다.)
  • -am : -m과 -a의 옵션을 합친 것입니다.

그러나 통상적으로 인라인(In-line)형식으로 작성하기 때문에 자세히 알 필요는 없습니다.

 

 

 

git push


git push를 통해 우리는 드디어 로컬 저장소에 저장된 파일을 원격 저장소(github, google drive 등)에 업로드할 수 있습니다. 

 

$ git push [remote] [branch]

: git push를 하는 경우 뒤에 현재 remote, branch 값을 적어주는데, 위 예제와 같이 origin/master라면 다음과 같이 명령하면 됩니다.

$ git push origin master

 

▽ README.md에 'this is hwonda' 문구를 넣고 add / commit / push 를 진행합니다.

 

▽ add / commit / push 하기 전.

 

▽ push 이후에 원격 저장소에 변경 사항이 적용됩니다.

 

 

 깃허브에 있는 코드를 내 컴퓨터로 가져오고 싶으신가요? 그렇다면 아래 내용을 잘 읽어보시기 바랍니다.

 

 깃허브(github.com) 사이트 내에 있는 레파지토리는 이전 글에 설명한 바와 같이 원격저장소에 저장됩니다. 내 PC에서 작업하는 내용은 로컬저장소에 저장됩니다. 원격저장소 -> 로컬저장소로 파일을 이동하고 싶으면, git clone 혹은 git pull을 하면 됩니다. 이 둘은 비슷하지만 약간의 차이점이 있습니다. git pull은 merge를 자동진행하는 특징을 가지는데, 이 것은 다음 글에 설명하도록 하겠습니다.

 

 먼저, 다음과 같이 로컬저장소(내 PC)에 폴더를 3개 만들어 진행해보겠습니다.

  • helloworld_01 : Terminal을 이용하여 git clone
  • helloworld_02 : VScode를 이용하여 git clone
  • helloworld_03 : Terminal을 이용하여 git pull

 

 

Terminal로 git clone


 

△ 1. github에서 복제하고싶은 레파지토리의 주소를 복사합니다. 긴 네모상자의 주소를 드래그해서 복사하거나, 화살표 부분의 버튼을 누르면 자동 복사됩니다.

 

 

△ 2. helloworld_01 폴더를 열고 들어가 Terminal을 엽니다. 그리고 다음과 같은 명령을 입력합니다.

$ git clone [복사한 레파지토리 주소]

그러면 원격저장소에 있는 README.md 파일이 내 PC로 들어온 것을 알 수 있습니다.

 

 

 

VScode로 git clone


 

△ 1. VScode 홈화면의 Clone Git Repository를 누릅니다.

 

 

△ 2. 활성화된 상단 바에 복제할 리포지토리 URL을 복붙합니다.

 

 

△ 3. 복제를 진행할(리포지토리 대상으로 선택할) 폴더를 선택합니다.

 

 

△ 4. 요렇게 신뢰하십니까? 나오면 Yes 누르시면 됩니다.

 

 

△ 5. 그러면 내가 고른 파일에 해당 리포지토리가 복제된 것을 확인할 수 있습니다.

 

 

 

Terminal로 git pull


 git clone은 원격저장소의 리파지토리를 일방적으로 로컬저장소 폴더로 옮기는 명령입니다. git clone만을 위해서는 두 저장소를 연결(remote)하지 않아도 됩니다.

 반면, git pull을 하기 위해서는 로컬저장소를 원격저장소와 연결(remote)해줘야 합니다. (remote : 로컬저장소 <-> 원격저장소)

 

$ git remote -v
// 현재 연결된 원격저장소를 알려줌. (아무 것도 안 뜨면, 연결되지 않은 것.)

$ git remote add origin [리파지토리 URL]
// 원격저장소 리파지토리와 연결.

$ git remote rm origin
// 연결된 원격저장소 연결 해제.

 

△ 1. git pull할 폴더를 엽니다.

 

 

△ 2. git remote 후 git pull 해줍니다.

 

 맨 처음 git remote 가 안된 이유는 초기화가 안됐기 때문입니다(.git 폴더 없음) git init을 해줍시다!

그 뒤 해당 리포지토리 URL로 remote하고 다음 명령어를 쳐주면

$ git pull origin master

 해당 리포지토리의 파일이 로컬저장소로 들어옴을 확인할 수 있습니다.

 

※ git clone 또한 나중에 로컬저장소 -> 원격저장소로 파일을 이동하기 위해서는 remote가 필요합니다.

 

 

이번 시간은 깃의 가장 기초적인 부분으로 Repository 생성/삭제에 대해 알아보겠습니다.

 

 

Repository


Repository(리파지토리/레파지토리) : 파일이나 폴더를 저장하는 저장소

 

git에서는 두 가지 저장소를 제공합니다.

  • 원격 저장소(Remote Repository) : 서버에 저장되어 여러 사람이 함께 볼 수 있는 저장소
  • 로컬 저장소(Local Repository) : 내 PC에 저장되는 개인 저장소

우리는 로컬 저장소에서 원격 저장소로 Push해서 여러 사람에게 원하는 파일을 보여줄 수 있고,

원격 저장소에서 로컬 저장소로 Pull해서 다른 사람이 만든 파일을 내 PC로 가져올 수 있습니다.

 

 

새 Repository 만들기


 

 ▽ 1. 깃허브 홈페이지에 접속해서 Sign in(로그인) 합니다. 아직 아이디가 없는 경우 Sign up(회원가입)을 진행합니다.

 

 ▽ 2. 로그인해서 들어가면 해당 화면이 나오는데, New 버튼을 클릭합니다.

 

▽ 3. Create a new repository 화면에서 내 레파지토리 이름을 적습니다. 처음 깃허브를 접해보신 분들은 Readme 파일을 생성하는 것을 추천드립니다. Readme파일을 만들면 조금 더 손쉽게 레파지토리를 관리할 수 있습니다.

 

 ▽ 4. Create repository 버튼을 누르면~

 

 ▽ 5. helloworld 레파지토리가 만들어졌습니다!

 

 

Repository 삭제하기


 

 ▽ 1. 상단 메뉴 가장 우측 Settings를 클릭합니다.

 

 ▽ 2. General 메뉴의 가장 아랫부분에 가면 Delete this repository 버튼이 있습니다. 클릭 해줍니다.

 

 ▽ 3. 레파지토리를 삭제할 것인지 되묻는 경고창이 뜨고, 입력창에 레파지토리 이름을 적어주면 아래 delete 버튼이 활성화됩니다. 눌러주면 해당 레파지토리는 삭제됩니다. (이 때, 깃허브 잔디도 함께 사라집니다..!)

 

 git을 사용하는 이유는 버젼관리, 협업, 백업 등에 용이하기 때문입니다.

 

 한편, 공개 레파지토리에 커밋한 파일은 팀원뿐 아니라 불특정 다수에게 공개되기 마련입니다.

버전관리에 필요없는 파일이나 보안상 문제가 되는 파일, 특히 로그파일 또는 빌드 시스템이 자동으로 만들어낸 파일은 git에서 관리할 필요가 없어집니다.

 

 필요한 파일들만 git add 하면 되지 않느냐? -> 프로젝트를 진행하다보면 파일의 양이 워낙 방대해져 관리하기 힘들어집니다.

이러한 문제를 해결하기 위해 .gitignore 을 활용할 수 있습니다.

.gitignore 파일을 만들고 그 안에 무시할 파일의 패턴을 적어 파일을 untracking할 수 있습니다.

 

 

 

주의할 점 : git add 전에 .gitignore을 포함할 것.

위 그림과 같이 일단 Staged 된 파일은 무시할 수 없으므로, 해당 파일을 삭제하고 다시 올려야 한다.

 

.gitignore 적용하기


특징

  • 프로젝트의 최상위에 위치해야 적용됩니다.
  • 표준 Glob 패턴을 사용합니다. (정규표현식과 모양은 비슷하지만 다른 패턴, 추후 정리 후 링크)
  • 파일 내 # (우물정)로 시작하는 코드라인은 무시합니다.
  • 파일 내 / (슬래쉬)로 시작하면 하위 디렉터리에 적용되지 않습니다.
  • 파앨 내 / (슬래쉬)로 끝나면 해당 디렉터리를 적용합니다.
  • 파일 내 ! (느낌표)로 시작하는 패턴의 파일은 무시하지 않습니다.

 

적용 (먼저 github에 remote 된 레파지토리가 있는 환경)

NPM TEST 폴더 현재 상황

 

1. .gitignore 파일을 해당 디렉토리 내에 생성하고, 무시할 파일 목록을 작성합니다.

(현재 node_modules 폴더와 DS_STORE 파일을 무시할 예정입니다.)

 

 

2. $ git add . 로 파일들을 추가합니다.

 

 

3. $ git commit, $ git push origin master를 통해 레파지토리에 파일을 스테이징 합니다.

 

 

4. 결과물을 즐긴다. (node_modules와 DS_STORE는 트래킹하지 않는 것을 볼 수 있습니다.)

+ Recent posts