Git #1

<Velog에 있는 Git 관련 내용>

 

 

Git & GitHub 란?

 

Git (깃) : 버전관리 시스템 (형상관리)이며 Configuration Management Systems 또는 Version Control Systems 라 한다

 

Git Hub(깃허브) : Git 저장소를 호스팅 하는 웹 기반 플랫폼. 사용자는 레포지토리(Repository)를 생성하고, 이를 통해 협업하고 코드의 버전을 관리한다.

 

 

 

 

Version Control

 

• Local Version Control System
  • 내 컴퓨터에서 버전관리 하는 것. 다만, 내 컴퓨터(로컬)의 하드가 날아가면 전부 사라짐.
  • 버전은 관리되지만, 협업은 어려움
• Centralized Version Control System
  • 협업 가능
  • Commit 하는 순간 배포되어 다수에게 버그 유발 가능 (서버로 바로 commit)
  • 인터넷이 안되면 작업 불가
  • 자신만의 Version Histroy를 가질 수 없음
• Distributed Version Control System
  • 현재의 버전관리 형태 (가장 많이 사용)
  • Commit 하더라고 개인저장소 내에 적용됨
  • 원하는 순간에 배포(Push) 가능
  • 오프라인에서도 작업 가능
  • 자신만의 Version Histroy를 가짐

 

 

Git의 기본 용어

 

• Repository
  • 소스코드가 저장되어 있는 여러 개의 Branch가 모여있는 디스크상 물리적 공간
  • Local Repository 와 Remote Repository로 구분
• Checkout
  • 특정 시점이나 Branch의 소스코드로 이동하는 것을 의미
  • Checkout 대상 : Branch, Commit, Tag
  • Checkout을 통해 과거 여러 시점의 코드로 이동 가능
• Stage
  • 작업할 내용이 올라가는 임시저장영역
  • 이 영역을 이용하여 작업한 내용 중 commit 에 반영할 파일만 선별하여 commit을 수행할 수 있음
• Commit
  
  • 작업할 내용을 Local Repository에 저장하는 과정
  • 각각의 Commit 은 의미있는 변경단위이고, 변경에 대한 설명을 commit log 로 남김
  • commit log : 버전에 대한 설명, 변경사항에 대한 설명을 상세히 남겨야 추후 확인 등 가능
  • 권장 : commit 을 아낄 필요 없다.
  • 참고 : commit 단위나 commit log format 을 정해놓은 회사나 팀도 있음 (빌드 서버 사용하는 경우)
• Tag
  • 임의의 commit 위치에 쉽게 찾아갈 수 있도록 붙여놓은 이정표
  • Tag 가 붙은 commit 은 commit id (version) 대신 tag name 으로 쉽게 checkout 가능
• Push
  • Local Repository 의 내용 중, Remote Repository 에 반영되지 않은 commit 을 Remote Repository 로 보내는 과정
  • 권장 : Push 하는 순간 다른 개발자들도 영향을 받음. 검증되지 않은 코드는 Push 하지 않도록 함
• Pull
  • Remote Repository 에 있는 내용 중, Local Repository 에 반영되지 않은 내용을 가져와서 Local Repository 에 저장하는 과정
  • 다른 팀원이 변경하고 Push 한 내용을 Local Repository 에 가져올 수 있음.
  • 참고 : Push 과정에서 Conflict(충돌) 이 일어나서 Push 가 거절된 경우, Pull 을 통해 Remote Repository 의 변경내용을 Local Repository 에 반영하여 Conflict(충돌) 을 해결 한 뒤 다시 Push 를 시도해야 함.
• Branch
  • 특정 시점 ( commit 단위) 에서 분기하여 새로운 commit 을 쌓을 수 있는 가지를 만드는 것.
  • 개발이 주축이 되는 branch를 master branch 혹은 main branch 라고 함.
  • 모든 branch 는 최종적으로 다시 master branch 에 merge 되는 형식으로 진행됨.
• Merge
  • branch 의 반대개념으로 하나의 branch 를 다른 branch 와 합치는 과정
  • Merge 되는 두 branch 는 주종관계가 성립. 예) dev branch 를 main branch 에 merge
  • Merge 되는 과정에서 Conflict(충돌) 이 발생하는 경우 Diff 를 수정하여 Conflict(충돌) 을 해결한 뒤 Merge 를 진행할 수 있음.

 

 

 

 

Git 설치 및 실행

 

Git Bash 실행

 

Git 홈페이지에서 다운로드 진행.

 

 

바로 실행가능하나 관리자 권한 실행 추천. 실행 후 git version 입력 시 설치된 git의 version 정보가 출력되면 올바르게 설치된 것.

 

 

 

 

 

 

Git Global Configuration

 

GitHub에 가입한 Username & Email을 Git에 등록

CRLF Window 설정 진행 : 가져올 때는 LF 를 CRLF로 변경하고 보낼때는 CRLF를 LF로 변경

 

 

• LF ( Line Feed, 줄 바꿈 )
  • LF는 줄의 끝을 나타내는 문자로, Unix 또는 해당 계열 운영체제에서 사용됨
  • ASCII 코드 10 (또는 \n )
• CRLF ( Carriage Retrun + Line Feed, 캐리지 리턴 + 줄 바꿈 )
  • CRLF는 줄의 끝을 나타내는 두 문자로 구성됩니다. 주로 Window 운영체제에서 적용
  • ASCII 코드 13 (캐리지 리턴, \r)과 ASCII 10 (줄 바꿈, \n )

이는 운영체제 간의 차이로 발생되는 개념. Server에 저장할 때는 LF로 저장하는 것을 권장

 

 

 

 

Git Editor 설정 : 기본적으로는 Vim 에디터 설정 변경가능

config --list : 적용된 설정들 확인

 

 

 

 

각 설정들은 아래와 같이 확인 가능함.

git config user.name
>> GH_Ryan

 

 

 

 

Local Repository

 

Local Repository는 Git이 관리하는 3가지 단계로 구성되어 있음.

• Working Directory : 실제 소스파일, 생성한 파일들이 존재하는 공간
• Index (Stage) : Staging Area, 준비영역의 역할. Git add 한 파일들이 존재하는 공간
• Head : 최종 확정본. git commit한 파일들이 존재

Commit하는 순간 Version이 생성되고 Head에 올라가게 된다.

 

 

 

 

 

Local Repository 생성은 아래와 같은 순서로 진행된다.

 

 

1. Workspace로 사용할 폴더(Repository)를 생성하거나 이동한다.

 

 - CMD 또는 Git Bash를 이용할 수 있다.

 - cd는 경로, 이동을 의미한다.

 - mkdir는 폴더를 만든다.

 

 

 

2. Git init (초기화)

 

  - 해당 폴더에서 Git을 초기화하는 명령어를 사용하면, 해당 폴더를 Git이 관리하기 시작한다.

  - 해당 폴더 경로 옆에 Master 라는 표시가 생성된다.

 

 

 

3. Git 확인

 

  - git이 관리 시작한 폴더에 files 또는 directory를 조회해 보면, .git 파일이 생성된 것을 확인할 수 있다.

  - 조회는 ls -all 명령어로 할 수 있다.

 

 

 

4. 테스트 파일 생성 ( touch 명령 )

 

  - test 할 파일을 생성할 수 있다. 

  - touch test.txt 와 같은 형식으로 생성한다.

 

 

 

5. Git status 

 

  - git에 존재하는 파일 확인 및 상태 확인

  - add 해야 할 것이 있는지 혹은 commit 해야할 것이 있는지 확인

아까 생성한 txt 파일에 대해 add 하라고 되어있다.

 

 

 

6. git add

 

  - Working Directory에서 변경된 파일을 Index(stage)에 추가하는 작업

add 진행 후 status 확인 시, commit 할 파일이 있는것을 알려준다.

 

 

7. git commit

 

  - Index(stage)에 추가된 변경사항을 HEAD에 반영 (확정)

 

 

 

 

 

 

Remote Repository

 

이제는 Github에서 Remote Repository를 생성하고, 기존에 생성한 Local Repository와 연결하는 작업

 

 

 

 

위와 같이 계정에서 create a new repository 를 진행한다. 그 후 아래와 같이 생성된 Remote Repository의 URL을 확인할 수 있다.

https://github.com/Gyoungho/YOLO_pjt.git

Gyoungho/YOLO_pjt

 

 

 

 

GitHub의 Token 생성

 

  - 보안상의 이유로 Remote Repository 접속 시, Token을 사용해야 한다.

  - 아래와 같이 설정할 수 있다.

  - Token 생성 후 반드시 Token 값을 복사해놔야 한다. 이후 보이지 않는다

 

 

 

 

 

 

1. Remote Repository 등록 - Local 과 Remote Repository의 연결

 

  - Token을 사용해서 Local과 Remote Repository를 연결한다.

  - 단, remote origin already exists. 와 같은 에러가 뜨는 경우, git remote remove origin 을 통해 삭제 후 재시도한다.

  - git remote -v : remote Repository에 연결된 정보 확인

 

# Remote Repository 등록
git remote add origin https://github.com/repository_name.git

# Remote Repository 등록 with Username and Token
git remote add origin https://username: token@github.com/repository_name.git

 

 

 

2. Origin 과 Master 및 원격저장소 (Remote) Push 

 

 - 브랜치(branch) : 저장소(repository) 내의 독립적인 관리영역

  * git에서 만들면 처음생성되는 브랜치 이름은 Master 이며

  * github에서 먼저 만들면, 처음 생성되는 브랜치 이름은 Main 이다
 - master 브랜치 : 저장소를 처음 생성할 때 만들어지는 브랜치
 - master : 해당 브랜치의 끝(최신 commit)을 참조하는 개체
 - HEAD : 어떤 commit을 가리키는 개체, HEAD가 이전 commit을 참조하면 Working directory의 내용이 이전 commit의 내용으로 변경됨
 - HEAD는 참조를 참조할 수 있음. (master를 참조하거나 commit을 직접 참조 가능)
 - HEAD는 git에서 사용되는 공식 명칭임. master, origin 또한 공통적으로 사용되는 명칭이나 필수는 아님(다른 이름으로 변경가능)

 

 

 

1. 원격저장소 조회(추가)하기 : $ git remote(-v)

• $ git remore add origin <url> :  <url>에 있는 원격저장소를  origin이라는 이름으로 추가하기
• 나의 로컬 저장소와 연결할 원격저장소의 이름은  origin, 그 주소는  url
• 즉, origin은 <단축이름>이다.

2. 원격저장소에 밀어 넣기 : $ git push -u origin master

• 내 repository의 master 브랜치를 origin의 master 브랜치로  push해라
• -u : 디폴트 설정. 즉 앞으로 $ git push만 써도 $ git push -u origin master가 실행됨

3. 원격저장소 갖고 와서 합치기 : $ git pull(origin master)

• origin을 내 repository의 master 브랜치로 갖고 와라(merge)
• 덮어쓰기이기 때문에 현재 내 작업내용과 원격저장소 간의 충돌이 발생하면 원격저장소가 남고 내 작업 내용은 사라진다.

4. 원격저장소 일단 갖고만 오기: $ git fech(origin master)

• 동기화시키지는 말고 (merge 하지 말고) origin을 내  repository의 master 브랜치로 일단 갖고 와라

5. 원격저장소 복사하기: $ git clone <url>

• <url>에 있는 원격 저장소 내용을 현재 디렉터리에 복사해 오기
• clone의 경우 원격저장소를 현재 디렉터리에 복사해 올 경우 remote add가 필요 없다.  clone이 이루어질 경우 자동적으로 원격저장소의 origin이 저장된다.

 

 

git push -u origin master

  - 로컬의 브랜치를 깃허브의 브랜치로 push 한다.
  - git push origin master 는 로컬의 마스터브랜치를 깃허브의 마스터 브랜치에 push한다는 뜻이다.

  - -u 옵션 : --set-upstream의 줄임말이다. 이 옵션을 쓰면 로컬 레포지토리의 master브랜치가 리모트 레포지토리의 master브랜치를 항상 추적하도록 설정된다.

 

 

에러가 좀 나서 잘 안되긴 했는데 결국 진행한 것 같다. ( 에러 시 아래 URL 재설정 )

   - $ git remote -v : 원격 repository 주소 확인
   - $ git remote set-url origin 새로운-리포지토리-URL

 

 

local의 폴더에 저장되어 있던, test_git.txt 파일이 Github에 있는 YOLO_pjt Repository에 등록된 것을 확인할 수 있다.

local Reposirty에서 commit하여 HEAD에 올려놓은 파일이 Push 를 통해서 Remote Repository 이동. (연된 Remote Repositort - GitHub에서 확인가능)

 

 

 

 

 

git pull

 

  - push 로는 master 브랜치에 있는 파일을 origin ( 원격 저장소 )로 Push 하였다.

  - 반대로 pull을 통해서 원격 저장소 (origin)에 있는 파일을 Local로 당겨올 수 있다.

  - 원격 저장소 (Origin, Github)에 README 파일을 하나 만들고 이를 Pull 해본다.

 

git pull 명령어를 통해서 remote repository에 있던 README 파일이 다운로드된 것을 알 수 있다.