GIT에 대해서 다시 한번 공부했습니다.

이전 회사에서도 GIT 이나 SVN 등을 사용하였으나, 실제 단독 개발로 이뤄지는 부분이 많은 터라 직접 내가 사용해 본적이 그리 많지 않았다. 분명 해당 정보를 정리해둔 게시물도 있다.
하지만, 최근 어느 회사에서든지 협업이 중요시됨에 따라, 반드시 익혀 두어야 할 부분으로까지 대두된 실정이다. 그렇다면 GIT 에 대해서 보다 자세히 공부 해보기로 하고 오늘 다시 첨부터 공부 했다.

http://kimseunghyun76.tistory.com/116 : 2년도 넘었네요.

아예 이번에 뽕을 뽑으려고 한다.

1.     GIT 의 정의
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
한글설명: http://git-scm.com/book/ko/%EC%8B%9C%EC%9E%91%ED%95%98%EA%B8%B0
* 솔직히 위에 URL 따라가서 다시 한번 봤는데, 이해하기 편하게 아주 잘 정리해 놓았습니다.
  그리고 나서 더더욱 설명이 잘 된 테스트 웹 사이트에서 한번 해주면 이해가 완죤 쏘~옥!!!

  GIT Branch 배우기 : http://learnbranch.urigit.com/ 

2.     GitHub
Git 호스팅을 하는 곳으로 무료(공개 저장소), 유료(비공개 저장소) 서비스 제공
URL : https://github.com/

3.     기본 개념
각 개발자 로컬 컴퓨터 상에 저장소를 생성해서 사용하다가 작업 완료가 될 경우에는 형상서버(Git 서버)로 이동(push) 후 다시 CI 서버로 넣는다(pulling). CI 서버상에서 빌드 및 테스트 분석 보고 등이 이뤄지고 이상이 없다면 , 테스트/ 상용 서버로 배포 형태로 진행.
GIT는 로컬에 저장소를 따로 가짐에 따라 백업을 위한 공간인 동시에 로컬에서 이력을 관리할수 있음.
커밋(commit)이 가지는 두 가지 의미가 이전까지는 제대로 정의되지 않아서 문제.
Serversion에서 commit 은 두가지 의미가 내포, 내가 완성한 프로그램 운영서버에 배포한다, 그래서 형상 서버에 올리겠다. 글구 백업 과 이력 관리해 달라라고 요청하는 의미
결국 Serversion을 CI 환경에 중심 형상 서버로 사용하게 되면, 개발자가 커밋한 행위가 배포를 요청한 것인지, 아니면 이력을 관리해 달라고 요청한것인지 구분이 어렵다.
이로 인해 늘 빌드 하거나 운영 서버에 새로운 기능이 배포될 때 마다 문제 발생.
GIT의 commit 는 위 두가지의 의미를 분리 했다.
Commit 는 자신의 로컬 저장소에만 요청, 배포는 원격 저장소에 푸쉬를 통해 요청.

4.     저장소 만들기
 git에서는 복사본 또는 working tree뿐만 아니라 저장소까지도 자신의 로컬 모신에 .git 디렉토리에 유지(Serversion 은 저장소는 원격 서버에 호스팅, 자신의 로컬 머신에는 복사본 또는 Working copy를 유지)
git는 파일을 3군데에 저장을 한다.
 (1) 작업 트리 : 로컬에서 작업하는 공간, (svn: working copy)
 (2) 스테이징 영역 : 작업트리와 저장소 사이에 버퍼 공간, 커밋할 대상을 올려두는 곳
 (3) 저장소 : 실제 파일이 저장되는 공간
local> git init
local> git add text.html
이렇게 하면 작업트리에 파일이 스테이징으로 이동된다.
local> git commit –m “add body text” text.html 
드디어 마지막 저장소로 커밋을 해본다.
local> git status
local> git log

5.     Branch 만들기
local> git branch myfirstbranch master
이때 branch 명령어는 두개의 인자를 받는다, 첫번째 인자는 브런치 명이며, 두번째 인자는 브런치할 프로젝트의 명이다.

A free Git client for Windows or Mac. : http://www.sourcetreeapp.com/

6.     Release tagging.
local> git tag my-project-1.0 test_1.0
릴리즈가 끝나면, 이제 릴리즈 브랜치에서 변경된 내용을 마스터 브랜치에도 반영을 해야 하며, 이러한 작업을 브런치 병합 또는 합치기… 작업트리를 마스터 브랜치로 변경
local> git checkout master ; git rebase test_1.0
아래와 같이 add 와 commit 를 동시에
local>git commit –a –m  “rebase conflict, merged by hand”
그럼 이제 불필요한 릴리즈 브런치는 삭제하자. 태깅해 두었기 때문에 해당 브런치에서 수정작업이 필요하다면 태킹한 브런치에서 얼마든지 분기가 가능하다.
local> git branch –D RB_1.0
이제 my-project-1.0 이라는 이름으로 태깅한 릴리즈를 압축한다.
local>git archive –format=zip –prefix=my-project-1.0/ my-project1.0 > mysite-1.0.zip

7.     원격 저장소 사용하기(프로젝트 공유)
팀원이 새롭게 들어와서 함께 개발을 해야 하는 상황에서 지금까지 로컬 저장소에서 관리하던 프로젝트를 팀원과 공유해야 한다. 즉 원격 저장소가 필요하다.
원격 저장소를 만들었다면 지금까지 개발된 코드를 올린다.
 URL : http://git-scm.com/documentation 
  / http://git-scm.com/book/ko/Git-%EC%84%9C%EB%B2%84
원격 저장소는 워킹 디렉토리가 없는 bare 저장소 이다.
다시 말해 일반적인 git 프로젝트에서 .git 디렉토리만 있는 저장소란 뜻이다.
원격 서버를 운영하려면 먼저 사용할 프로토콜을 선택해야 한다.
(git 는 local, ssh,git,http protocol 를 지원, http protocol 를 제외한 나머지 방식에서는 모두 git이 서버에 설치되어 있어야 함.)
- local : 원격 저장소가 동일한 머신의 다른 디렉토리에 있을 때 사용. 즉 팀원 모두 NFS와 같이 파일 시스템을 공유할 때 사용.
 local> git clone /opt/git/project.git
 local> git clone file:///opt/git/project.git
 이미 있는 GIT 프로젝트에서 아래와 같이 로컬 저장소를 추가
 local> git remote add local_proj /opt/git/project.git
그러면 네트워크에 있는 리모트 저장소처럼 push 하고 pull 할수 있다.

- git : git에 포함된 데몬을 사용하는 방법으로 포트는 9418을 사용, 인증 매커니즘이 없음. 이 프로토콜로는 push 설정이 가능하나, 인증하도록 할수 없기 때문에 잘 안쓴단다.
- ssh : Git의 대표 프로토콜은 SSH이다. 대부분 서버는 SSH로 접근할 수 있도록 설정돼 있다. 뭐, 설정돼 있지 않더라도 쉽게 설정할 수 있다. 그리고 SSH는 읽기/쓰기 접근을 쉽게 할 수 있는 유일한 네트워크 프로토콜이다..
 local> git clone ssh://user@server/project.git
 local> git clone user@server:project.git
사용자 계정을 생략하면 git은 현재 로그인한 사용자의 계정을 사용.
 SSH는 시에 데이터를 압축하기 때문에 효율. 단점으로는 익명 접근 불가.
- http/s : 설정이 간단, 푸쉬를 할수 있도록 설정할 수 있지만, 까다로와서 잘 사용되지 않는다.
프로토콜을 조합해서 사용해도 됨,

8.     GIT 서버 , 서버에 GIT 설치하기
* 다 적으면서 이해하려고 하다보니.. 문제는 위에 URL 상에서 나온 튜토리얼만 잘 숙지하면 될듯.

 

자~~!!! 여기 까지 봤으면 마지막 Summary 해놓은것으로 마무리!!
딱 10분이면 끝!!!

http://rogerdudler.github.io/git-guide/index.ko.html 

 

 

l  CI 서버
Continuous Integration, 빌드 자동화 서버
이전에 단순히 컴파일과 같은 것으로 여겨졌던 빌드 개념이 CI 서버에서는 모든 중요한 유효성 검사 및 테스트 단계가 포함되어 이루어지는 것으로 변화.
CI서버를 통해 자주 통합하고 검증함으로써 최신 코드가 항상 건강한 상태인지 확인 할 수 있으며, 통합주기를 짧게 가져감으로써 오류 발생시 원인 파악을 신속하게 할 수 있음.
또한 자동화된 코드 검사를 통해 지속적인 상태 모니터링이 가능하기 때문에 프로젝트 관리가 용이하여 항상 배포할 수 있는 소프트웨어 상태를 유지 시켜주기 때문에 이는 기존 폭포수 방식에서 벗어난 애자인 방법론에서 요구하는 필수 조건이기도 함.

 

l  Jenkins : 지속적인 통합(CI, 빌드 자동화)를 지원해주는 가장 유명한 도구, Java 로 제작되었으며, 400여개 이상의 플러그인 제공, 기존에 Hudson 이라는 이름의 도구 였으나, Oracle로 합병됨에 따라, 별도로 분리됨.
아래는 다운로드 부터 설치까지인데.. 이건 직접해보면서 하는 것이 좋을듯.

1) 다운로드 : http://jenkins-ci.org/
2) 설치
 - WAR 파일 : Tomcat 의 webapps 폴더에 복사한 뒤 Tomcat를 restart 혹은 Tomcat manager에서 WAR 파일을 등록하면 설치 완료. 이후 http://localhost:8080/jenkins 로 시작(URL 뒷부분은 WAR 파일 이름에 의해 결정)
 # Tomcat manager 등록시 파일 업로드 제한이 있으므로 확인 후 수정
3) Tomcat 내 webapps/manager/WEB-INF/web.xml 설정 파일 변경
4) 환경 설정
5) 프로젝트 빌드 설정
6) 빌드 실행하기
7) 플러그인 설치