6. Git & Github

목차*****************************

1. 용어 정리

2. 환경설정

3. SSH 등록

4. 기본 브랜치 이름 변경

5. Git의 영역과 기본 명령어

6. 혼자 작업 workflow

7. 함께 작업 workflow

8. 자가 점검 list

*********************************

[Git 용어 정리]

 

[스냅샷] : 특정 시점에 생성된 코드 변경 전 백업 복사본, 이를 통해 이전의 기록에 대해 추적이 가능함.

[Commit] : 스냅샷을 만들어주는 작업

[Git] : 소스 코드 기록의 변경을 버전 별로 관리하고 추적할 수 있는 버전 관리 시스템.

[1] 파일의 변경 사항을 추적, 각 파일의 버전을 관리

[2] 파일을 백업할 수 있게 한다.

[3] 협업자들과 함께 파일을 공유하고, 각자의 작업물을 취합할 수 있게 해준다.

[Github] : Git을 제공되는 Repository로 관리할 수 있는 클라우드 기반 서비스.

Git을 통해 버전을 관리하는 폴더를 Github를 통해 여러 사람들이 공유하고 접근할 수 있다..

<< Git은 로컬에서 버전을 관리해주는 프로그램이며, Github은 Git을 클라우드 방식으로 구현한 서비스입니다. >>

[Git Repository] : Github에서 제공되는 작업 공간으로 Git이 관리되는 폴더.

Git Repository는 Remote Repository와 Local Repository 두 종류의 저장소가 있다.

[Local Repository] : 유저가 작업하는 개인 저장소

[Remote Repository] : Local Repository에서 작업을 완료하고 작업한 코드를 공유하기 위해 업로드 하는 저장소.

[Fork] : 특정 코드에 contribute를 하기 위해 오픈 Remote Repository에 업로드 되어있는 코드를

나의 Remote Repository로 가지고 오는 것.

[Clone] : Fork 이후 나의 Remote Repository에 옮겨져 있는 해당 코드 자료를 나의 Local Repository로 가져오는 작업

[Push] : 내 Local Repository에서 작업 완료 후 변경내용을 commit을 통해 저장 후 Remote Repository에 올리는 작업

[Pull] : Remote Repository에서 변경 사항이 있을 때 Local Repository로 가져오는 작업

[Pull Request] : 상대방의 작업물에 나의 작업물을 취합 요청하는 것..

[Fetch] : Remote Repository에 변경 사항이 있는지 확인만 하고 병합을 하지는 않는다.

[branch] : 독립적인 작업 영역(저장소)안에서 소스 코드 작업을 진행하는 것.

각각의 브랜치는 다른 브랜치의 영향을 받지 않기 때문에, 여러 작업을 동시에 진행할 수 있다.

[Merge] : 브랜치를 다른 브랜치와 병합 함으로써, 작업한 내용을 다시 새로운 하나의 브랜치로 모은다.

 

[Git 환경설정]

 

[사용자 정보]

Git을 설치하면 가장 먼저, 사용자 이름, 이메일 주소를 설정한다. 기록된 정보를 앞으로 진행할 Git 커밋 내역에 기록.

 

[터미널을 실행 후]

git config –global user.name “David Han”

git config –global user.name han2041126@gmail.com

 

--global 옵션으로 설정시, 사용자 홈에 저장. 추후 Github 사용자 이름, 이메일 변경을 원하면 다시 입력해야함.

만일 여러 프로젝트를 진행하고 있고, 프로젝트마다 다른 사용자 이름, 이메일 주소를 사용하고 싶으면

--global 옵션을 빼고 명령을 실행할 수 있다.

 

[에디터]

Git에서 커밋 메시지를 기록할 때, 특히 merge commit 확인 메시지가 나올 떄 텍스트 에디터가 열린다.

기본값으로는 텍스트 에디터 vi가 열리는데, vi에 익숙치 않으면 nano로 변경하는 게 좋다.

 

git config –global core.editor notepad++

 

[SSH 등록]

SSH는 Secure Shell의 줄임말로 보안이 강화된 shell 접속을 뜻한다.

CLI환경에서 다른 PC에 접속하거나 요청할 때 사용되며, 비대칭키를 이용해 사용자 인증을 한다.

 

[SSH 키 생성]

SSH키는 비대칭키로 구성되며, 그 이름에서 유추할 수 있듯 두 개의 키가 서로 대칭이 되지 않는 형태로 존재.

 

프롬프트에 ssh-keygen 입력 후 엔터 3번.

 

ssh-keygen 명령어는 경로 ~/.ssh./에 두 파일 id_rsa와 id_rsa.pub를 생성한다.

이 두 파일은 ssh 키페어라고 하며 id_rsa.pub는 공개키 (Public Key)이고 id_rsa는 개인키(Private Key, Secret Key) 이다.

ssh키 페어를 생성하였으니 생성된 키 페어 중 공개키를 복사하여 Github에 등록한다.

[공개키 (Public Key) 복사]

1. cat ~/.ssh/id_rsa.pub 입력 후 나오는 내용을 마우스 드래그 후 복사.

2. Github 이동 Settings > SSH and GPG keys >SSH Keys 옆 new SSH Key 클릭 > title :맘대로, key 복붙. > Add SSH key

 

[기본 브랜치 이름 변경하기]

* 기본 브랜치가 생성되었고, master 라는 default 이름이 붙여졌다.

* 앞으로 git init 을 입력했을 때에 생성되는 기본 브랜치의 이름을 다른 것으로 바꾸려면 아래의 명령어.

git config –global init.defaultBranch 변경할_브랜치_이름

이 명령어를 입력하면 앞으로 gIt init을 입력했을 때 생성되는 기본 브랜치의 이름이 변경할_브랜치_이름 설정.

* 현재 위치하는 브랜치의 이름을 바꾸려면 아래의 명령어

git branch –m 변경할_브랜치_이름

 

git init을 입력하면 디렉토리 내에 .git 디렉토리가 생성됨. 하지만 ls –l 해도 조회가 되지 않는데 ls –a를 이용하여 확인.

기본적으로 .git 폴더에 Git이 파일 관리에 필요한 모든 정보를 보관하므로 실수로 삭제되지 않도록 숨김으로 생성함.

 

[Git의 영역과 기본 명령어] //

Git의 영역은 Git으로 관리하는 파일이 위치하는 영역을 의미하며 크게 Online / Local 의 영역으로 나뉜다.

* Online : Remote Repository (원격 저장소)

* Local: Work Space(작업 공간), Staging area (스테이징 영역), Local repository(지역 저장소)

 

1. [파일들의 상태를 확인하기] : git status

Git으로 관리되고 있는 파일들의 상태는 git status 명령어로 확인할 수 있다. 즉 git init 이후부터 확인이 가능

 

[파일의 상태]

Git의 관리 하에 있는 파일들의 상태는 크게 아래로 나뉜다.

 

[A] Tracked : Git에 의해 파일의 상태가 추적되고 있는 상태 (반드시 Commit 이라는 과정이 필요)

[a] Unmodified : 파일의 수정이 Git에 의해 감지되지 않은 상태

[b] Modified : 파일의 수정이 Git에 의해 감지된 상태

[c] Staged : 파일이 Staging area에 존재하는 상태

* 기본적으로 Commit을 해야 Tracked 상태로 변경될 수 있지만, Commit 하지 않은 파일도 예외적으로 Staged 상태 가능.

 

[B] Untracked : Git에 의해 파일의 상태가 추적되고 있지 않은 상태.

 

2. [Git으로 파일 관리 시작하기 (Git 초기화)] : git init

Git이 관리하도록 하기 위해서는 먼저 해당 파일이 존재하는 directory 위치에서 git init 을 입력해줘야 한다.

< git init 입력하여 Git에 등록 = Work Space 이동 = Local repository 생성 완료>

 

 

[1st Step [Git 초기화로 파일 > Work Space 이동시키기] : git init]

 

[작업 순서에 따른 공간 사용]

Work Space (Git을 활용한 일반적인 작업 사용) -> Staging area (단위 작업이 끝날 때 까지) -> Local Repository(그 후)

 

git init 명령어에 생성되는 3가지 공간

A. [Work space]

Work Space는 세 가지 영역(Work Space, Staging area, Local repository) 중 하나로,

Working tree 또는 Work Tree 라고도 하며, 터미널상 눈으로 볼 수 있는 디렉토리 자체를 의미.

Git은 Work Space를 자동으로 스캔한다(modified or Unmodified).

Git이 Work Space를 스캔하다가 무언가 변경된 사항을 발견하면, 사용자에게 해당 사항을 알려주고( as modified),

어떤 행위를 취해야 하는지 적절한 명령어 및 동작을 알려준다. ( add to staging area // restore to unstaged. )

 

즉 Work Space는 git init을 입력 후 어떤 Git 명령어도 입력하지 않은 상태의 파일들이 존재하는 영역.

 

 

 

git add 의 기능 : [Work Space -> Staging Area]

B. [Staging Area] : Local repository에 저장할 파일들이 임시적으로 대기하는 영역.

일반적으로 Git을 활용하여 작업할 때에는 Work Space에서 작업을 마친 파일을 Staging area로 옮겨서 모아두고

추후 어느 정도 단위 작업이 끝나면 파일들을 한번에 Local repository로 저장.

 

 [Work Space > Staging Area로 파일 이동시키기] : git add // git add .(현재 디렉토리 내 모든 파일 스테이징)

 

일반적으로 add 시킨 이후 git status 기능으로 이동이 되었는지 확인 하는 게 좋음

git rm --cached 파일_이름 : Staging area > Work Space

 

 

git commit의 기능 : [Staging Area -> Local Repository]

C. [파일을 Local Repository에 저장하고 버전을 기록하기] : git commit

Commit이란, Staging area에 보관중인 파일을 Local Repository에 저장함과 동시에 파일의 버전을 기록한다.

Commit을 할 때에는 각 버전을 쉽게 구분하기 위해 커밋 메시지를 입력한다.

Git commit을 입력하면 여러 줄의 커밋 메시지를 입력할 수 있는 텍스트 편집기 창이 뜨지만,

보통 여려 줄의 커밋 메시지 보다는 짧게 요약하여 한 줄만 작성한다. git commit 명령어 중 –m 을 사용한다.

Ex) git commit -m “First commit”

 

[Commit 내역 확인] : git log

Commit이 완료된 상태에서 git log 입력하면 터미널 내에 별도의 창이 열린다.

출력 내용 Ex)

Commit 커밋해시 (숫자+알파벳) (HEAD > main) : 브랜치 이름을 main으로 변경했고 이동하지 않았으므로 head : main)

Author

Date

             Commit message.

 

[ 커밋 이후 파일 상태 확인] : git status

Nothing to commit, working tree clean

>> Work Space 내의 파일이 모두 Unmodified 일 때 나타나는 메시지.

 

Nothing to commit : git init으로 Git Work space로 등록시켰던 파일이 Local Repository로 저장되었고

저장된 버전과 Work Space 내에 있는 파일간의 차이가 없기에 Commit할 것이 없다.

Working tree clean : Work Space 내의 파일의 상태가 모두 Unmodified.

Unmodified는 Tracked 상태라서 Git이 변화 추적을 계속하지만 현재 변화가 감지되지 않은 상태를 나타냄.

 

 

[ 커밋 이후 파일을 1차 수정할 경우 ]

1. 수정한 직후의 상태는 무엇 ?

> 1차 커밋 이후는 unmodified (tracked) 이지만 수정을 하고 나면 변화를 감지하므로

modified 상태만 되고 git add 를 해주지 않았으므로 unstaged 상태.

2. git add를 한 이후의 상태는 무엇 ?

> modified인 파일이 working space > Staging area로 이동한 상태.

3. 현재 파일의 상태는 무엇 ?

> 현재는 2차 커밋까지 완료한 상태.

4. git status > Working tree clean은 무슨 뜻 ?

> 커밋한 상태와 현재 work space 내에 파일의 버전이 차이가 없어 모두 unmodified 상태.

5. HEAD > main 무엇을 의미 ?

> 브랜치 이름이 main 이며 브랜치 이동을 하지 않았으므로 HEAD는 현재 브랜치 main을 의미

 ---------------------------------------------------------------------------------------------------------------------------------------------------

git push 의 기능 : [Local repository > Remote repository&nbsp; 업로드하기]

D. [작업물을 Remote Repository로 업로드하기] : git push

작업물을 Remote Repository로 업로드함은 온라인 저장소에 다른 사람과 공유할 수 있게 하는 것.

 

[D-1] : Remote repository 만들기

Github > profile > your repositories > New -> Owner / Repository name / > Public > Create repository

 

[D-2] : Local repository와 Remote repository 연결하기

git remote --v  : 명령어를 입력한 위치의 Local Repository와 연결된 Remote Repository 가 있는지 확인.

git remote add 원격_저장소_별칭 원격_저장소_URL : Local repository를 Remote Repository에 연결하라.

** 원격_저장소_별칭 : URL에 해당하는 Remote repository를 어떤 이름으로 로컬에서 사용할 것인지.

보통 origin 이라는 단어를 관례적으로 많이 사용함.

** 원격_저장소_URL : Github > your repositories > 연결하고자 하는 Repository > Code > HTTPS URL.

실제 명령어 예시 : git remote add 원격_저장소_별칭 URL.

>> git remote add orgin https://github.com/Dvdhan/git_practice.git

>> Remote repository 연결 해제시 : git remote rm 원격_저장소_별칭

 

Fetch : Remote repository로부터 파일을 내려받을 때 사용하는 별칭과 URL.

push : Remote repository로 업로드할 때 사용하는 별칭과 URL을 의미.

 

[D-3] : 업로드 하기 : git push

push : 나의 작업물을 Remote repository에 업로드.

>>  git push 원격_저장소_별칭 브랜치_이름

원격_저장소_별칭 : git remote add로 나의 Local Repository와 연결한 URL의 별칭.

브랜치_이름 : 지금까지 사용해오는 main 이라는 이름.

 

[Local repository > Remote repository 업로드하기] : git push

 

**오류 error**  git push 입력 시 username /password 입력하라고 뜰 경우.

git remote –v 입력 시 https://로 주소가 되어 있다면 Username과 Userpass를 물음.

Git remote 재설정하면 해결됨. (나의 Github 계정은 SSH 인증으로 했기에 http가 아닌 SSH URL 이용하기)

git remote set-url origin(원결_저장소_별칭) git@github.com:Dvdhan/git_practice.git (내 repo code > SSH)

 

[Remote Repository의 코드를 로컬로 복사해오기 : git clone target Remote Repository URL]

git clone은 Remote Repository의 코드를 로컬로 복사해오면서 해당 Remote repository와 자동 연결을 맺어주는 명령어

Remote repository의 모든 파일들이 Remote repository의 이름의 디렉토리에 담겨져 git clone을 선언한

디렉토리로 복제되는 것. 자연히 git init, git remote add를 할 필요가 없다.

 

[git reset : 커밋 취소하기]

Git reset --hard 현재 작업 위치인 HEAD의 포인터를 특정 위치로 변경.

 

[혼자 작업 workflow]

혼자 하는 작업 workflow

[1] 내가 작업할 시작 시 dir 만들고 깃 초기화 : git init  / 내 Local Repository와 Remote Repository를 연결

: git init 

[2] 내 Local Repository와 Remote Repository를 연결한다.

: git remote add 저장소_별칭(origin) 내_Remote_Repository_URL

 

[1] code에 contribute 할 시 다른 이의 Remote Repository에서 나의 Remote Repository로 Fork 작업을 한다.

[2] forked 한 Remote Repository을 나의 Local Repository로 clone 작업을 한다

: git clone (forked Remote Repository URL)

 

[1] 생성된 dir 내 작업 공간에서 작업이 완료된 다음 git add로 스테이징 처리

: git add .

[2] Staging Area에서 작업 완료한 다음 나의 Local Repository로 commit 한다. :

: git commit or git commit –m “커밋_메시지”

[3] 나의 Local Repository에서 나의 Remote Repository로 push 작업을 한다.

: git push 저장소이름(a.k.a origin) 브랜치명(a.k.a main)

[4] 원래 있던 다른 이의 remote repo로 작업 변경 완료했으니 확인 후 merge하라고 pull request 한다.

 

[함께 작업 workflow]

함께 작업 workflow

A. 상대방 Remote Repository로부터 작업할 때.

[1] 작업할 sprint가 있는 Remote Repository를 내 Remote Repository로 fork 한다. : 화면 우측 상단 fork 클릭

[2] 생성된 내 forked Remote Repository의 SSH URL을 가지고 원하는 디렉토리에서 클론 작업 

: git clone forked URL.

 

B. 내 Local Repository에서 작업을 시작할 때.

[1] 내 컴퓨터에서 생성한 디렉토리를 Git의 관리에 들어가게 한다.

: git init (=Local repository 생성됨)

[2] 내 Local Repository를 원하는 내 Remote Repository와 연결

: git remote add 저장소이름(a.k.a origin) Remote_Repository_URL

 

C. 팀으로 작업 진행할 때

[1] 함께 작업할 사람의 Remote Repository와 내 Remote Repository와 연결 한다.

: git remote add (a.k.a pair) (연결하고자 하는 상대방의 Local repo URL)

[2] 연결 이후 git remote --v 로 나의 Local Repository와 연결된 Remote Repository 상태 확인하기.

[3] 내 작업 완료 시 PUSH to 내 Remote Repository, 상대방 완료 시 PULL from 상대방 Remote Repository.

Ø  PUSH : git push 저장소이름(origin) push할_브랜치명(a.k.a main)

Ø  PULL : git pull 저장소이름(origin) pull받아올_브랜치명(a.k.a main)

저장소명은 git remote --v 로 확인가능, 브랜치 명은 git status로 확인 가능.

[4] 만일 페어와 동일한 부분을 수정해서 pull > merge하려면 문제가 발생한다.

 git status를 통해 어떤 파일인지 확인. 아래 4가지 방법으로 해결 가능함.

 

1.     파일을 확인하여 충돌이 일어난 부분을 하나하나 수정하기.

2.     Accept Current Change : 클릭해서 내가 수정한 내용을 파일에 반영.

3.      Accept Incoming Change : 클릭해서 Remote Repo 내용을 반영.

4.      Accept Both Changes : 변경 사항 모두 반영

 

수정을 마치면 병합 커밋 (merge commit)을 생성하기 위해 파일을 staging area로 추가해야한다. By git add

병합 커밋은 자동으로 commit message가 생성된다. By git commit

그리고 나의 Local Repository에서 나의 Remote Repository로 Push하면 By git push 저장소_별칭 브랜치명

 

>>페어 협업 후 pull 작업 시 마주치는 conflict 예시

====를 중심으로 <<<<HEAD 랑, >>>>> 6f339 confilct가 나왔다.

both 적용 : <<<< HEAD, =======, >>>>> 6f339f0d 부분 지우기.

위에 적용 : , =======, >>>>> 6f339f0d 부분 지우기.

밑에 적용 : <<<< HEAD, ======= 부분 지우기.

저장 후 git commit –am “merge completed”.넣어주면됨.