Git & Github

GIT이란?

git은 local에서 관리되는 버전 관리 시스템이며 소스코드 수정에 따른 버전 또한 관리를 해주는 도구다.

git은 형상 파일의 변화를 무엇이, 어디서, 누가, 몇번, 몇시에 변경 되는지 기록하고 같은 파일에 대한 각기 다른 버전을 보관하며 동시에 같은 파일을 가지고 여러명이서 작업 가능한 장점이 있다 [1].

내가 만든 파일을 바로 commit을 하게 될 경우 다음과 같은 Error 가 발생할 것이다.

commit할 파일을 미리 지정해줘야 한다.

따라서 아래 주의사항을 지키길 바란다.

commit에 관한 주의사항

commit을 하기 전 사용자의 이름과 이메일 주소를 설정한다. git config user.name "sangyunlee" git config user.email "yunpha123@gmail.com"
commit 메시지를 작성한다. (option -m) git commit -m "Create calculator.py and License"
commit 할 파일을 git add로 작성하기 git add calculator.py git add License.txt

Git 3가지 내부작업영역

각 작업 영역은 working directory, staging area, repository 순으로 동작을 진행한다.

working directory는 작업을 하는 프로젝트 디렉토리를 말한다. 다른말로 working tree라 불린다.

처음에 만든 레퍼지토리이며 개발자가 직접 코드를 수정하는 공간을 말하고 , .git을 제외한 모든 영역을 포함한다 .

ex) $mkdir 'oracle'

$cd oracle

2. staging area는 다른말로 index로 git add를 한 파일들이 존재하는 영역이다. Repository로 정보가 저장되기 전 준비 영역으로 .git/index 파일로 관리됩니다.

commit을 하게되면 staging area에 있는 파일들만 commit에 반영된다.

예를들어보자 .

calculator.py에 주석을 추가 후 git add calculator.py 명령어를 실행했다.

git status 명령어를 통해 보면 add 한 calculator 파일만 Change to committed에 보이고, 수정하지 않은 파일은 Change not staged for comit 리스트 에보인다. 즉 Change to committed에는 커밋에 반영될 변경 사항을보여주고, Change not staged for comit 에는 커밋에 반영되지 않은 변경사항을보여주고 있다.

그럼 파일들이여러개 수정될때 번거롭게 git add 명령어로 다 찾아 타이핑을해야될까?

git add .

이 명령어를이용하면 한꺼번에 적용이 된다. 즉 현재 프로젝트 디렉토리내에서 변경사항이 일어나 파일들을 모두 staging area 에 올리게 된다. 그러니 해당디렉토리 위치를 확인하고 명령어를 잘 사용하길 바란다.

3. repository는 working directory의 변경 이력들이 저장되어 있는 영역이다.

commit들이 저장되는 영역이다. 즉 파일이나 폴더를 변경 이력별로 저장해두는 곳으로 .git 디렉토리 내에 존재한다. 레퍼지토 리는 Local, Remote Repository로 구분된다.

제일 먼저 working directory에서 작업자가 작업을 진행 하고, 작업한 파일들을 git add 한 후 commit을 하면 staging area에 있던 파일들의 모습이 마치 영화의 한 장면, 스냅샷(snapshot)처럼 이 repository에 저장된다.

git commit -m "add title comment and Create meeting-log"

Git 파일의 4가지 상태

Git에서 파일들은 크게 2가지 상태를 가진다.

Untracked
Tracked

그리고 Tracked 상태는 다시 아래와 같이 3가지 상태로 나뉜다.

Staged 상태
Unmodified 상태
Modified 상태

Untracked

먼저 Untracked는 '추적되지 않고 있는'이라는 뜻한다.

이 상태는 파일이 Git에 의해 변동사항이 전혀 추적되고 있지 않는 상태를 말한다.

예를들면 파일을 새로 생성하고 그 파일을 한 번도 git add로 staging area 에올리지 않았다면 이 상태다.

Tracked

파일이 Git에 의해 그 변동사항이 추적되고 있는 상태다.

이 상태는 다시 그 특성에 따라 3가지 상태로 나다.

(1) Staged

파일의 내용이 수정되고나서, staging area에 올라와있는 상태를 stage area에 올려진 상태다.

새로 생성한 파일에 내용을 쓰고 git add를 해주거나 한 번이라도 커밋에 포함됐었던 파일이라도 내용을 수정하고 git add를 해주면 이 상태다.

(2) Unmodified

현재 파일의 내용이 최신 커밋의 모습과 비교했을 때 전혀 바뀐 게 없는 상태다. 즉 수정되지 않은 상태다. 커밋을 하고 난 직후에는 working directory 안의 모든 파일들이 이 상태가 된다.

(3) Modified

최신 커밋의 모습과 비교했을 때 조금이라도 바뀐 내용이 있는 상태면 그 파일은 Modified(수정된) 상태다.

어떤 경우에, 어떻게 상태 전환이 발생하는지 자세히 살펴보겠다.

Add the file : Untracked 상태의 파일을 처음으로 git add 해주면 Staged 상태가 된 다.
Edit the file : 최신 커밋과 비교했을 때 차이가 없는 Unmodified 상태의 파일의 내용을 수정하면 Modified 상태가 된다.
Stage the file: Modified 상태의 파일을 git add 해주면 Staged 상태다.
Remove the file : 파일을 삭제 후 Git에서 더이상 인식하지 못하는상태
Commit : 커밋을 하면 staging area에 있던 파일들이 커밋에 반영되고, 이제 모든 파일들은 최신 커밋과 차이가 없게 되니 Unmodified 상태가 된다.

git 원복(git reset)

작업자가 파일을 수정하여 git add를 하여 staging area에올렸는데 다시 확인해보니 수정된 파일의코드가 잘못됬다.

아직 commit을 하지 않았으므로 git add를취소시키는명령어가 있다.

$ git reset '파일명'

$ git status

git reset은 staging area에서 파일을 제거하는명령어로 이 명령어를 이용하면 git add 명령어 staging area에 올렸던 파일을 취소 시킬 수 있다.

즉 수정된 파일이 다시 working 디렉토리로 돌아간 상태다.

그럼 잘못된 부분만 다시 지워 이전 상태와 동일하게 만든 후 git 상태를 확인해 보자.

working tree가 깨끗하다는말은 working 디렉토리가 이전과 같은 상태를 보여주고 있다.

다시말해 이전 commit 이후로 변경사항이 없다.

Github와 Connect

다음은 Github에 우리가 만든 code 파일을 업로드, 다운로드를 할 것이다.

먼저 Github에 가입한다.

그 다음 Github에서 레퍼지토리를 생성한다.

Github에있는 레퍼지토리를 원격레퍼지토리 혹은 리모트 레퍼지토리를 말한다.

그리고 내컴퓨터에 만든레퍼지토리를 로컬레퍼지토리라 한다.

레퍼지토리를 만드는 방법은 블로그를 참조하길 바란다.

레퍼지 토리를 잘생성했다면 다음과 같은화면이보일것이다.

위 그림의 대해 먼저 간략히 설명하면아래와같다.

…or create a new repository on the command line 부분 먼저 설명하겠다.

echo "# Codeit_Math_Box" >> README.md
git init
git add README.md
git commit -m "first commit"
git branch -M main
git remote add origin https://github.com/MustangYun/Codeit_Math_Box.git
git push -u origin main

이 부분은 로컬 레퍼지토리를만들고 commit을 한 후 업로드를하는 설명이다.

아래 '…or push an existing repository from the command line'은 이미 만든 로컬레퍼지토리를 깃허브에업로드를 하는설명이다.

git remote add origin https://github.com/MustangYun/Codeit_Math_Box.git
git branch -M main
git push -u origin main

위5-7번째 github코드와아래 1-3번째코드 가 동일한것을알수 있다.

이제 로컬 command 창에서 바로 위에 있는 1-3번째 명령어를 실행한다.

git push 명령어를 입력할때 아마 로그인 창이 뜰 것이다. 로그인을 하면 내가 만들었던 파일이 저절로 업로드가 될 것이다.성공했다면

성공했다면 아래와 같은 화면이보일 것이다.

gitpush

이제 Gitpush 명령어를 이용해 새로운파일을 github(리모트 레퍼지토리)에 업로드해보겠다.

이때 사용하는 명령어는 다음과 같다.

$git push

이 명령어는 로컬 레포지토리(Local Repository)의 최신 내용을 리모트 레포지토리(Remote Repository)에도 반영할때사용한다.

간단하게 README.md 파일을 Github에 업로드해보자.

순서는 다음과 같다.

로컬 메모를 만들고 내용을 입력 후 저장한다.
로컬 command 창에서 git add . 한다.
git commit
gitpush를 하면 Github창에 업로드가 될 것이다.

gitpush를 했을때 이상없다면무엇인가 %가 올라가면서 위 화면되처럼될 것이다. 그럼성공한것이다.

그리고 다시 Github를 새로고침하면 업로드가 된 것을 확인할 수 있다.

git pull

GitHub 페이지에서 직접 내용을 수정하거나 다른 사람이 그 리모트 레포지토리를 자신의 컴퓨터로 가져가서 수정한 다음 다시 리모트 레포지토리에 git push한 경우 수정된 리모트 레포지토리의 내용을 본인의 로컬 레포지토리에도 반영하려면 어떻게 할까?

이때 로컬레퍼지 토리 git bash에서 사용하는 명령어는 다음과 같다.

$git pull

이 명령어는 pull 이라는 단어 그대로 잡아당기는 것인데, 리모트 레퍼지토리 내용을 로컬레퍼지토리로 내용을 반영하는것과 같다.

실행한 결과는 아래 그림과같다.

그렇다면 리모트 레퍼지토리에서 수정한파일이 로컬 레퍼지토리에서 제대로 반영되었는지 확인해보자.

로컬레퍼지토리에서 다음 명령어를 실행해보자.

$cat '파일명'

보시다시피 calcuc처음에 로컬레퍼지토리에서 리모트 레퍼지토리로 업로드를 했을때 calculator.py의 코드가 multiply 펑션만 있었는데, 리모트 레퍼지토리에서 divide 펑션을추가고 git pull로 내려 받았을 때 로컬레퍼지토리의 내용이 업데이트가 된것을 알 수 있다.

그럼 대체 리모트레퍼지토리를사용하는 이유는무엇일까?

안정성: 로컬환경에서 문제가 발생 시 백업용도로 리모트레퍼지토리에서 가져오기만 하면된다.
협업가능: 예를들어 A라는개발자가 code를작성하고 GITHUB에 업로드를했다. 그러면 다른 개발자들이 A가작성한 코드를 다운받고, 문제가 있을 시 직접수정하여 GITHUB에 다시 업로드를 했다. 이때 A개발자는 다시 그 GITHUB에 올라온 코드를 다운받으면 된다.