Day13

☠지옥에서 올라온 파일관리자☠ 라고 불리는 `git`시스템은 과거에 파일 관리하는 방법이 시스템화 되어있지 않았을때, 지옥처럼 힘들게 관리되던 파일들과 소스코드들을 획기적으로 관리하고, 컨트롤 할 수 있게 해준 너무나 중요한 버전관리 시스템이다.

 

이번 미션에서는 파일을 관리하는 시스템을 공부하고 시스템 안에서 어떤 개념들이 사용되는지 학습하고 정리해보고자 한다. 특히나 git이 어떤 방식으로 수행되고, 그 과정에서 중요하게 여겨지는 방법이 무엇인지 정리해 보고자 한다.

 

VCS 버전관리 시스템(Version Control System)

파일 변화를 시간에 따라 기록해뒀다가 나중에 특정 시점의 버전을 다시 불러올 수 있는 시스템

VCS 기능

• 선택한 파일을 이전 상태로 되돌릴 수 있다.
• 변경 사항을 비교하고, 변경한 사람 및 변경시기를 추적할 수 있다.
• 파일을 쉽게 복구할 수 있다.

VCS 종류

로컬 버전관리(Local VCS)

데이터베이스를 사용해서 파일의 변경정보를 관리하는 시스템

• 간단하게 만들 수 있다.
• 실수하기 쉽다.
• RCS(Revision control system)

중앙집중식 버전관리(Centralized VCS)

서버가 별도로 있고 클라이언트가 중앙 서버에서 파일을 받아서 사용(Checkout)하는 방식

• 여러 사람과 함께 작업해서 생기는 문제를 해결하기 위해 개발되었다.
• 로컬 VCS보다 관리가 쉽다는 장점이 있지만 중앙 서버에 문제가 발생한다면 치명적인 타격을 입는다.
• CVS, Subversion, Perforce

분산 버전관리 시스템(Distributed VCS)

단순히 파일의 마지막 스냅샷을 Checkout 하지 않고 저장소를 히스토리와 더불어 전부 복제해서 저장한다.

• 서버에 문제가 생기면 이 복제물로 다시 작업을 시작할 수 있다.
• 클라이언트 중에서 아무거나 골라도 서버를 복원할 수도 있다.
• 많은 수의 리모트 저장소를 가질 수 있기 때문에 다양한 방법으로 협업할 수 있다.
• Git, Mecurial, Bazaar, Darcs

 

버전관리 시스템(Version Control System) 이란?

버전관리 시스템(Version Control System) 이란?

 

git

소프트웨어 개발에서 사용되는 분산 버전 관리 시스템

git의 주요 개념

• Repository(저장소)
  • 깃에서 변경 내역을 추적하고 관리하는 단위로, 일반적으로 로컬 저장소와 원격 저장소로 나누어진다.
    • 로컬 저장소 : 개발자의 개발 환경에서 사용되는 저장소
    • 원격 저장소 : 다른 개발자와 협업할 때 사용되는 저장소
• Commit(커밋)
  • 변경 내역을 저장소에 기록하는 작업
  • 각각의 커밋은 고유한 해시값을 가지며, 변경 내역의 이력을 추적할 수 있습니다.
• Branch(브랜치)
  • 커밋의 이력을 기반으로 생성된 작업 라인
  • 새로운 기능 추가나 버그 수정 등을 위해 독립적인 브랜치를 생성하여 작업할 수 있다.

git의 특징

• Distributed development
  • 전체 개발 이력을 각 개발자의 로컬로 복사본을 제공하고 변경된 이력을 다시 하나의 저장소로 복사한다.
    • 이러한 변경은 추가개발지점을 가져와, 로컬개발 지점과 동일하게 병합(merge)할 수 있다.
  • 저장소는 Git protocol 및 HTTP로 쉽고 효율적(특별한 웹서버 구성없이)으로 접근할 수 있다.
• Strong support for non-linear development
  • 신속하고 편리한 branch 및 merge 지원한다.
  • 비선형(여러갈래) 개발 이력을 시각화하고 탐색 할 수 있는 강력한 도구를 제공한다.
• Efficient handling of large projects
  • Git은 매우 빠르고, 대형 프로젝트나 이력이 많은 작업에 매우 합리적이다.
  • Git은 대부분의 다른 버전관리시스템보다 빠르게 요청한다. 그리고 일부 작업에서는 더 빠르게 진행한다.
    • 또한, 최근의 정상급 오픈소스 버전관리 시스템보다 장기간의 수정내역을 매우 효율적인 압축방법을 사용한다.
• Cryptographic authentication of history
  • GIt의 이력은  성공한 개발이력의 commit에 의해 개정명으로 저장된다.
  • 일단 그것이 배포되면, 그것을 모르고 예전 버전으로 변경하는 것은 불가능하다.
    • 또한, 그것들을 암호화 할 수 있다.
• Toolkit design
  • UNIX의 전통에 따라, GIT은 C로 작성된 많은 소규모 도구모음이다,
  • 그리고 많은 스크립트들이 기능 보강을 제공한다.
  • Git은 새로운 기발한 작업을 위한 손쉬운 사용과 쉬운 스크립팅을 위한 도구를 제공한다.

git의 작동 원리

• 스탭샷(snapshot)
  • 파일의 변경 내역을 추적해서 관리하는 것
  • 깃은 파일이 변경되면 이전 파일의 상태를 저장하여 변경 내역을 추적한다.
    • 저장된 파일들의 변경 내역을 커밋하고, 커밋의 이력을 통해 파일의 변경 내역을 추적할 수 있다.

git - 간편 안내서 - 어렵지 않아요!

git - 간편 안내서 - 어렵지 않아요!

 

Git의 3가지 영역

Working Directory :

• Git이 추적 중인 파일들이 위치하는 영역
• git init을 통해서 git이 관리하도록 지정된 디렉토리
• 지정된 디렉토리에서 .git 디렉토리를 제외한 모든 것(파일, 하위 디렉토리)
• 작업한 파일(생성, 수정한 파일)들이 저장되는 곳

Staging Area

• commit 할 준비가 된 파일들이 위치하는 영역
• 해당 영역은 .git 디렉토리에 단순한 파일로 존재한다.
• 작업한(수정된) 파일들 중 버전으로 만들고자(commit 하고자) 하는 파일을 저장한다.
• git에서는 기술용어로써 "Index"라고 부른다.

Git Directory(Repository)

• 커밋되어 버전을 관리하는 파일들이 위치하는 영역
• Git이 프로젝트의 메타데이터와 객체 데이터베이스를 저장하는 곳
• .git 디렉토리 == Repository
• 프로젝트의 버전 정보를 관리하기 필요로 한 모든 파일이 저장되어 있다.

Git의 3가지 상태

modified

• 수정한 파일을 로컬 데이터베이스에 commit하지 않은 것
• Working Directory 영역에 있는 파일들 중 수정을 한 파일들의 상태

staged

• 수정한 파일들 중 commit 할 것이라고 표시한 상태
• Staging Area 영역에 있는 파일들의 상태

commited

• Staged 상태의 파일들이 로컬 데이터베이스에 안전하게 저장됐다는 것
• commit 된 대상 파일은 Working Directory 영역으로 돌아가게 되고 대상 파일의 버전을 관리하는 파일들은 Git Directory(Repository)에 저장된 상태
• Commited 상태 대상 파일을 수정하게 되면 Modified 상태가 된다.

Git 파일의 4가지 LifeCycle

Git의 파일들은 반드시 untracked, unmodified, modified, staged 이 4가지 상태 중 하나의 상태를 가지고, 4가지 상태를 반복적으로 순환하면서 관리된다.

 

Tracking

• Git에 의해서 추적이 되는지 안되는지를 구분하고 분류한다.
• Git안에 생성은 되어있지만 Git에 의해서 추적되고 관리되지 않는 파일을 Git에 등록해서 변화 과정을 추적하고, 관리되게 해준다.

Untracked

• Working Directory에 존재는 하지만 git이 관리를 하지 않는 파일들의 상태
  • Working Directory에 새롭게 만들어진 파일들이 이에 해당한다.
• 새로운 파일을 만든 후  git status 명령을 실행하시면 "Untracked fiels : 파일 이름" 문구가 뜨고, 해당 문구의 파일이 Untracked 상태의 파일을 의미한다.

Unmodified

• 수정을 하지 않은 파일 상태
• Unmodified 상태의 파일은 한 번 이상 commit 된 파일 중 수정을 하지 않은 파일 또는 다른 저장소의 파일들을 clone 하였을 때의 파일들을 의미한다.
• 앞의 Git 3가지 상태 ****에서 살펴본 committed와 같은 개념

Modified

• 수정을 한 파일의 상태
• Unmodified 상태의 파일을 수정을 하게 되면 Modified 상태 파일로 바뀐다.
• Unmodified 상태의 파일을 수정 한 뒤  git status  명령을 실행하면 "changes not statged for commit : 파일 이름" 문구를 볼 수 있다. 해당 문구는 Modified 상태의 파일을 나타낸다.
• "changes not staged for commit"의 의미는 Tracked 상태이지만 아직 Staged 상태는 아닌 파일들의 목록을 의미한다.

Staged

• commit 하고자 하는 파일의 상태
• 위에서 살펴본 Staging Area 영역에 있는 파일의 상태( 앞의  Git 3가지 상태  ****에서 살펴본 Staged와 같은 개념)
• Untracked 상태의 파일 혹은 commit 된 이후 수정이 진행된 파일(Modified 상태의 파일)을  git add  명령을 수행하게되면 해당 파일들은 Staged 상태가 된다.
• git add  명령 이후  git status  명령을 실행하면 "changes to be committed : 파일이름" 을 볼 수 있는데 해당 문구에 있는 파일이 바로 Staged 상태 파일이다.
• "changes to be committed"는 'commit(버전화) 될 파일들의 목록' 을 의미한다.

[Git] git의 3가지 영역, 3가지 상태, 라이프 사이클

[Git] git의 3가지 영역, 3가지 상태, 라이프 사이클

 

Git 개체(Objects)

• Blob 개체
  • .git/objects/(hashMap 앞2글자)/(HashMap 뒤 38글자) 의 저장경로
  • 파일 내용만 저장되어있다.
  • 파일이름은 저장 하지 않는다.

 

Git & GitHub

GitHub란?

깃(Git)을 기반으로 소스코드와 관련 파일을 저장하고 관리할 수 있는 웹 기반 호스팅 서비스

git&GitHub 기본 용어

• 스테이지(Stage)
  • 버전으로 만들 파일이 대기하는 곳
• 저장소(Repository)
  • 스테이지에서 대기하고 있던 파일들을 버전으로 만들어 저장하는 곳
• 커밋(Commit)
  • 파일이 스테이지에 있을 때, 버전을 만드는 것
• gitignore
  • 버전 관리 중인 디렉터리 안에 관리하지 않을 특정 파일이나 디렉터리의 목록을 지정해 주는 파일
• 브랜치(Branch)
  • 변경 사항을 분리하여 관리할 수 있는 저장소
  • 각각의 브랜치는 독립적인 작업 공간을 가지며, 변경 사항을 추적하고 병합할 수 있다.
• 푸시(Push)
  • 로컬 저장소에서 변경된 코드를 원격 저장소로 업로드하는 작업
• 풀(Pull)
  • 원격 저장소에서 변경된 코드를 로컬 저장소로 가져오는 작업
• Fetch Origin
  • 원격 저장소로부터 변경사항을 가져오는 동작
  • pull과 다른 점 : 변경 사항을 로컬 저장소에 반영하지 않고 단순히 업데이트된 커밋들을 가져온다.

git&GitHub 기본 명령어

git remote

현재 로컬의 디렉토리가 연결되어있는 원격 저장소가 어디인지 확인 할 수 있다.

git log

git에서 수행되었던 커밋들의 히스토리를 조회할 수 있다.

git clone

원격 저장소(GitHub)에 이미 존재하는 프로젝트를 로컬에 복제해서 저장할 수 있다.

 

SHA(Secure Hash Algorithm)

전자 데이터에 대한 디지털 지문이나 메시지 다이제스트를 생성하는 데 사용되는 암호화 해시 함수의 집합

• 해시를 사용한 암호화 알고리즘
• 단방향 암호화 알고리즘

SHA의 동작 원리

• 임의의 크기의 입력 메시지를 가져와서 일련의 수학적 연산을 적용해서 해시, 메시지 다이제스트로 알려진 고정 크기 출력을 생성한다.
• 입력 메시지에 따라 고유하게 해시 코드를 생성해서 나타낸다.

SHA의 장점

• 무결성
  • SHA는 각 입력 메시지에 고유한 디지털 지문, 메시지 요약을 제공하여 전다 데이터의 무결성을 보장한다.
• 속도
  • SHA는 다른 암호화 기술에 비해 암호,복호 하는 속도가 빠르다.
  • 다양한 입출력에 대해서 효율적으로 암호화를 제공하기 때문에 다양한 용도로 사용된다.
• 광범위한 사용
  • SHA는 다양한 입출력에 대해서 좋은 범용성을 가지고 있기 때문에, 디지털 서명 프로토콜, 메시지인증 코드 및 기타 보안 애플리케이션에 널리 사용된다.

SHA의 단점

• 충돌 공격
  • 두개의 서로 다른 입력 메시지가 동일한 해시를 생성할 수 있는 충돌 공격에 취약하다.
  • 이를 해결하기 위해서 SHA-2, SHA-3 같은 다양하고 강력한 버전이 개발되었다.
• 제한된 보안
  • 광범위하게 사용되기 때문에 인터넷을 통한 데이터 전송에서 안정성의 요구사항이 높아지고 있다.

 

얕은 복사 vs 깊은 복사

Value and Reference type

모든 데이터 타입은 값 타입(value type) 또는 참조 타입(reference type)을 가진다.

• 값 타입(Value type) : 각각의 고유의 메모리를 소유한다. 스위프트에서 struct, enum, array, tuples 들이 해당 타입에 속한다.
• 참조 타입(Reference type) : 생성된 인스턴스들은 주소값을 공유한다. 스위프트에서 class가 해당 타입에 속한다

깊은 복사(Deep copy)란?

• 데이터 자체를 통째로 복사한다.
• 복사된 두 객체는 완전히 독립적인 메모리를 차지한다.
• value type의 객체들은 깊은 복사를 하게 된다.

💡 깊은 복사는 인스턴스가 완전히 독립적이다.

얕은 복사(Shallow copy)란?

얕은 복사는 아주 최소한만 복사를 한다. 값을 복사한다 하더라도, 인스턴스가 메모리에 새로 생성되지 않는다. 값 자체를 복사하는 것이 아니라 주소값을 복사하여 같은 메모리를 가리키기 때문이다.

 

깊은 복사 VS 얕은 복사

깊은 복사 VS 얕은 복사