소스코드 버전관리를 사용하지 않았을때 발생했던 문제점소스코드버전관리를 통해 문제가 해결되는 사례소스코드버전관리란?Git이란?Git 설치하기저장소 만들기수정하고 저장소에 저장하기Branch브랜치의 사용예Github와 BitbucketAtom을 이용한 Git 사용하기Git에 관한 잡다한 이야기들

소스코드 버전관리를 사용하지 않았을때 발생했던 문제점
- 우리는 프로그래밍을 하면서 많은 소스코드 파일을 작성합니다. 작업을 할때 마다 종종 백업이 필요한 상황이 많습니다. 특히 어떤 작업을 마친 뒤 그 폴더를 통으로 백업하려고 합니다. 공유를 위해서 폴더를 압축하고 다른사람에게 "폴더명_날짜.zip" 같이 파일명을 지어서 전송합니다.
- 하지만 이렇게 백업할 경우 불편한 점은 내가 수정한 내용을 구체적으로 기억하지 못할경우 변경내역을 확인 하기가 어렵습니다.
- 또한 만약 컴퓨터에만 보관을 했는데 하드디스크가 고장난다면 애써 작업한 소스코드를 다 잃어버리게 됩니다.
소스코드버전관리를 통해 문제가 해결되는 사례
- 소스코드버전관리는 이런 문제를 해결하기 위해 만들어졌습니다.

- 프로그래밍을 하고 중간중간 백업을 함으로써 언제든지 해당 시점으로 내 폴더를 복구 할 수 있습니다.
- 또한 외부의 서버에 소스코드를 보관해서 내 컴퓨터의 파일이 삭제 되더라도 다시 다운 받아서 작업을 계속할 수 있습니다.
- 또한 함께 작업하는 사람에게도 편리하게 모든 작업 내역을 공유할 수 있습니다.
소스코드버전관리란?
- 소스코드 버전관리를 이용하면
- 소스코드의 변경된 내역을 묶어서 저장할 수 있습니다.
- 원하는 시점으로 복구 할 수 있습니다.
- 서버에 변경저장기록을 모두 저장 할 수 있습니다.
- 다른 사람으로 부터 공유받은 올려놓은 소스코드를 서버로 부터 쉽게 내려 받을 수 있습니다.
Git이란?
- Git은 소스코드 및 파일의 변경내역을 저장하는 분산버전관리시스템 입니다.
- 리누스 토발즈에 의해 처음 만들어졌습니다.
- Github, Bitbucket, Gitlab 등의 Git기반의 버전관리호스팅 서비스들이 있습니다.
- 추천서적 : ProGit https://git-scm.com/book/ko/v2
Git 설치하기
- Ubuntu에서 설치하기
- 명령어로 설치하기
$ sudo apt-get update $ sudo apt-get install git
- Mac 설치하기
- https://git-scm.com/ 접속
- Download for Mac 버튼 클릭
- 다운 받은 파일 실행
- Windows 설치하기
- https://git-scm.com/ 접속
- Download for Windows 버튼 클릭
- 다운 받은 파일 실행
- Git 버전 확인
$ git --version git version 2.19.1
- 초기 설정
- 사용자정보 설정
$ git config --global user.name "John Doe" $ git config --global user.email johndoe@example.com
저장소 만들기
- 작업할 디렉토리 만들고 이동하기
$ mkdir hellogit $ cd hellogit
- 현재 디렉토리를 Git 저장소로 만들기
$ git init
- 저장소에 파일을 추가하고 커밋하기
$ touch README $ git add README $ git commit -m "initial project version"
수정하고 저장소에 저장하기
- 파일의 상태 확인하기
$ git status
- git이 관리할 대상으로 파일 등록
$ git add README
- 버전 만들기(commit)
$ git commit -m "저장메세지를 입력해주세요"
- 파일 무시하기 - gitignore
- .gitignore파일에 버전관리에서 제외할 파일을 추가한다.
# a comment - 이 줄은 무시한다. # 확장자가 .a인 파일 무시 *.a # 윗 줄에서 확장자가 .a인 파일은 무시하게 했지만 lib.a는 무시하지 않는다. !lib.a # 루트 디렉토리에 있는 TODO파일은 무시하고 subdir/TODO처럼 하위디렉토리에 있는 파일은 무시하지 않는다. /TODO # build/ 디렉토리에 있는 모든 파일은 무시한다. build/ # `doc/notes.txt`같은 파일은 무시하고 doc/server/arch.txt같은 파일은 무시하지 않는다. doc/*.txt # `doc` 디렉토리 아래의 모든 .txt 파일을 무시한다. doc/**/*.txt
- 변경사항 확인하기
$ git diff
- 커밋히스토리 조회하기
$ git log
- Git Remote
- 클론할 프로젝트 찾기
- https://github.com 접속
- jquery 검색하기
- https://github.com/jquery/jquery 로 접속하기
- Clone or download 버튼 클릭하기
- 주소 복사하기
- 새 작업 디렉토리만들고 이동하기
$ cd $ mkdir clonetest $ cd clonetest
$ git clone https://github.com/jquery/jquery.git $ cd jquery $ git log
Branch
- branch란?
- 개발을 하다 보면 코드를 여러 개로 복사해야 하는 일이 자주 생긴다. 코드를 통째로 복사하고 나서 원래 코드와는 상관없이 독립적으로 개발을 진행할 수 있는데, 이렇게 독립적으로 개발하는 것이 브랜치다.
- Git의 브랜치는 특정 커밋을 가르키는 바로가기 같은 것 입니다.
- 브랜치를 생성하면 현재 커밋을 가르키는 브랜치가 생성됩니다.
- 특정 브랜치에서 작업중인데 새로운 커밋을 하면 브랜치는 그 새로운 커밋을 가르키게 됩니다.
- 기본 브랜치는 master 브랜치 입니다. git저장소를 초기화 할때 자동으로 만들어 집니다.
- Git은 'HEAD'라는 특수한 포인터가 있습니다. 이 포인터는 지금 작업중인 브랜치를 가르킵니다.
브랜치의 사용예
- '홍길동'은 새로운 기능을 개발 할 때마다 새로운 브랜치를 만들고 그안에서 작업을 하고 커밋을 합니다. 기본 브랜치는 master 브랜치 입니다. 회원가입기능을 만들려고 한다면 feature-usersignup 브랜치를 생성하고 그 안에서 소스코드를 수정하고 커밋을 합니다. 회원가입기능의 개발이 완료가 되면 그동안 커밋했던 feature-usersignup 브랜치의 내용들을 master 브랜치에 합칩니다. 또 새로운 작업을 하려고 하면 master브랜치에서 다시 새로운 feature브랜치를 생성하고 작업을 합니다.
회원가입 기능을 작업하고 있는데 급하게 버그를 수정해야 하는 경우가 발생합니다.
그런경우 현재의 작업상태를 임시로 커밋해두고
회원가입 기능 작업 시작이전 상태의 스냅샷으로 작업폴더를 변경할 수 있습니다.
버그패치용 브랜치를 만들고 수정작업을 합니다.
이후 작업이 완료되면 버그패치용 브랜치의 추가된 변경내역을 마스터 브랜치에 합칠 수 있습니다.


- 팀 '제주코드'는 '제주카페'라는 안드로이드앱을 런치한 후 지속적으로 업데이트 하고 있습니다. 매주 월요일 오후마다 일주일동안의 수정내역을 반영한 앱을 앱스토어에 업데이트 합니다. 팀은 두개의 브랜치를 가지고 있습니다. master와 develop 입니다. develop에는 평소 개발이 완료될때마다 지속적으로 커밋을 합니다. 그리고 일주일에 한번씩 앱스토어에 배포하기전에 가장 최신의 develop브랜치의 내용을 master브랜치에 반영시킨 후 그 소스코드를 가지고 앱을 빌드해서 배포를 합니다. 따라서 월요일이 되기전의 master브랜치는 가장 최근에 앱스토어에 배포한 소스코드의 스냅샷 커밋을 항상 가르키고 있습니다.
- 현재 브랜치 목록과 현재 브랜치 확인
$ git branch
- branch 만들기 브랜치를 새로 만들수 있다. testing 브랜치를 만들어 보자.
$ git branch testing
- checkout 새로 만든 브랜치로 이동할 수 있다. testing 브랜치로 이동해보자.
$ git checkout testing
- 새로운 내용을 추가하고 커밋해 보자.
$ echo 'hello branch' >> branch.txt $ git status $ git add branch.txt $ git commit -m "브랜치 테스트용 파일 추가"
- branch 병합 이제 master브랜치에 testing브랜치에 추가된 내용을 병합해보자.
$ git checkout master $ git log $ git merge testing $ git log
Github와 Bitbucket
- Github
- Github가입하기
- 프라이빗 리파지토리 생성하기
- 리파지토리명 : hellogit
- 만들었던 저장소 푸시 하기
$ cd hellogit $ git status $ git remote add origin https://github.com/beomjae/hellogit.git $ git push -u origin master
$ cd $ mkdir hellogit2 $ cd hellogit2 $ git clone https://github.com/beomjae/hellogit.git .
$ echo "add more" >> a.txt $ git status $ git add . $ git commit -m "추가작업내역입니다." $ git push origin master
Atom을 이용한 Git 사용하기
- 소스코드 수정
- 변경내역 보기
- Stage 하기
- 커밋하기
- 푸시하기
- 체크아웃하기
Git에 관한 잡다한 이야기들
- 그래서 Git을 꼭 써야하나요?
- Git은 이제 개발할 때 사실상 필수요소 입니다.
- 백업을 해놓음으로서 부담없이 코딩할 수 있습니다. 내가 코드를 잘못 수정해도 언제든지 쉽게 되돌아갈수 있는 마음이 생기기때문입니다.
- Git과 근무일지
- git 커밋내역을 보면 누가, 언제, 어떤 작업을 했는지 적나라하게 기록되어있습니다. 따라서 팀원간에 공동으로 작업을 한다면 다른 팀원이 어떤 개발을 했는지 묻지 않아도 커밋로그만 봐도 알 수 있습니다. 개발 안하고 농땡이 칠 수가 없어요.
- 커밋로그와 한글
- 한국인으로만 이루어진 프로젝트라면 저는 커밋로그를 한글로 적습니다. 영어로 문장을 길게 작성하기 어렵기 때문입니다. 커밋로그는 말그대로 내가 작업한 내역을 적는 곳입니다. 따라서 최대한 자세히 적으면 좋습니다. 매번 커밋할때마다 영어로 작문하려면 스트레스 받고 그러다보면 자연스럽게 커밋로그가 짧아집니다. 그러지 말고 그냥 한글로 자세하게 적는게 좋다고 생각합니다.
- Bitbuket과 Github
- 비트버킷과 Slack의 연동
- 비트버킷과 CI(젠킨스)의 연동
- 간단한 이슈트래커를 제공하는 Bitbucket과 Github
- 커밋로그에 이슈번호 적기