메모

AI프렌즈 세미나 - GIT(깃)

_empty_ 2019. 5. 15. 20:41

GIT_전기연구원 전기의료기기 연구센터

 

Git : 히스토리를 담을 수 있고 제출용으로도 사용할 수 있다.

해외 IT기업에서는 Git을 회사에서 검토해서 코드를 보고 메신저로 코딩테스트를 진행함.

즉, 해외기업을 노리고 있다면 Git은 필수.

 

필요성

1. 수많은 수정본과 복사본, 특히 기업 차원에서 배포하다보면 어떤 버전에서 문제가 생겼는지 알아야한다.

코드 관리를 도와줄 무언가가 필요해짐.

-> Version Control System

Local -> Centralized -> Distributed(분산) , Git은 분산시스템 중 하나.

 

2. 기존의 CVS, SVN과 달리 Git은 분산 버전 처리방식. 저장소가 여러 곳에 있을 수 있음.

~ CVS, SVN ~

1. 두 사람이 A를 check-out(저장소->작업공간)함

2. 한 사람이 Working(소스코드 A를 B로 변경함)

3. B로 바꾼 코드를 Commit(작업공간->저장소)해서 서버의 A가 B로 변경됨

4. 다른 한 사람이 기존의 A를 기반으로 C로 변경했는데, 서버의 A는 B로 바뀐 상태이기 때문에 에러가 남

 즉 commit하려는 순간  conflict가 일어남. 소스관리 툴의 도움을 받을 수 없다.

 

장점 1 . Git은 우선은 A->C로 변경한 것을 Commit은 할 수 있음. 즉 history가 남게 된다. 즉 소스관리 툴으 도움을 받을 수 있다.

서버에서는 conflict가 나겠지만 우선 기록이 된다는 점.

장점 2 . 항상 저장소에 연결되어야 한다. -> Git은 오프라인에서도 작업할 수 있다

장점 3 . 프로그램 규모와 인원이 늘어날 수록 느리다 -> Git은 느려지지 않는다.

장점 4 . 모든 안이 공개되어야한다 -> Git은 여러 아이디어를 자신의 하드디스크에서 테스트한 후 최종 안만 서버에서 공개할 수 있다

장점 5 . 단일 저장소 - > 다중 원격 저장소 (소스 코드의 분산저장/관리가 용이함)

 

Push 로컬저장소->원격저장소로 코드 이동

에러 발생 : Pull 원격 저장소의 변경된 코드를 로컬로 끌어옴

Merge 변경된 코드를 기반으로 새로운 코드로 변경

이런 구조로 여러명이 소스코드 작업을 할 수 있음

 

Git은 스냅샷을 남긴다는 개념. history를 남긴다는 것이 그 전의 모든 작업을 담는다는 느낌.

 

디지털 노마드 - 실리콘밸리의 새로운 흐름. 개발자들이 Git으로 소통하며 회사를 운영하는 방식.

 

3. 시작하기

Git > Git Client > Git Server

Git

1.1 Git installer로 설치

1.2 터미널에서 설치

2. Git 초기설정 - 이름과 메일주소 설정

 

Git Client

1. Sourcetree (Windows/Mac) : 상업적으로도 무료

2. smart-git (Windows/Mac/Linux) : 비상업적으로만 무료

3. Gitkraken (Windows/Mac/Linux) : 비상업적으로만 무료

 

Git Server

1. GitHub

2. Bitbucket

3. My server

 

Git Server 연결하기

1. Git Server 주소 얻기

2. Git Server와 연결하기

: github기준 clone or download 버튼을 누르고 주소 복사해서

터미널창 열어서 git clone (복사했던 주소) 입력 

 

4.사용하기

 

5. GUI 클라이언트

터미널창에서 명령어로 push pull merge commit 하지 않아도 되게

브라우저 창처럼 버튼식으로 창이 뜨는것.

리눅스에서 명령어로 파일 만들고 지워도 되지만 디렉터리 들어가면 가시적인 것처럼

파일 상태 뷰(ctrl+1) / 로그 보기 뷰(ctrl+2)

 

브랜치 생성

브랜치 == 하나의 대표되는 흐름.

새로운 아이디어나 기능을 구현해야 할 때에는 별도의 브랜치를 생성하여 작업하기.

코드의 플로우?

같은 시작점에서 각기 다른 아이디어로 코드를 진행한다 치면 두 개의 브랜치를 생성하는 것임.

Master - - - - (b)--------l

Idea1               l-------J

Idea2              l------

 

Idea 1과 2로 브랜치가 나뉘었는데, 1이 성능이 먼저 나와서 1을 master에 merge.

idea2 삭제가 가능해진다. 1을 merge하고 2는 사라지는 것.

물론 두명이 각각 다른 아이디어로 진행하다가 한명이 먼저 commit & push했을 경우

다른 한 명이 merge를 시도했을 때 commit만 성공하고 push에서 conflict가 발생할 수 있음.

push 해서 서버의 코드를 가져와서 이전에 누군가 같은 브랜치에서 시작한 코드를 수정해서..? push해서 충돌이 일어났음을 알기. 

사용하는 프로그래밍 툴을 이요하여 충돌이 일어난 부분 수정한 뒤 commit & push하면 됨.

 

6. 브랜치 관리기법

simple

develop master 두 줄기로 관리

git-flow

프로젝트 관리 / 

master (최종 릴리즈 : 버전관리)

hotfixes (긴급수정)

release branches (최종 릴리즈 준비)

개발 관리 /

develop (개발 브랜치 : 자주 커밋)

feature b ranches (기능별, 아이디어별 구현)

 

대부분 git client에서 git-flow 관리를 도와주는 메뉴가 존재함.

 

7. 협업하기

 

8. 기타

stash :  깃이 제공하는 공식적인 압축 툴. 임시로 저장하기

rebase : 기능은 merge와 동일. 시간순으로 merge를 시켜줌.

linux 예약 실행 스케줄러 : crontab - 매일 자동으로 프로젝트 실행 여부를 검사하기. 매일 compile 되는지 확인.

git은 여러명, 많은 사람이 작업을 함께 할수록 필요성 증가