참고사이트(https://zimt.tk/Github-SourceTree-1562ba21b4444ea3a57c40f9f5f26631)


1. 깃허브에서 Repository 생성

: 깃허브에 반영할 프로젝트에 맞게 repository를 생성한다.

 

 

2. 이클립스(STS)에서의 사전작업

  1. 깃허브에 넣을 프로젝트를 지정한다.
  2. 프로젝트 폴더에 사전에 커스터마이징 한 gitignore 파일을 넣는다. (반드시 깃허브 연결전에 넣어야 한다.)
  3. 깃허브와 연결하기 위해 Team => Share project => Use or Create repository in parent folder of project => Create Repository => Finish한다.
  4. Git Staging의 Unstaged Chages를 Staged Changes로 옮기고 commitMessage에 커밋내용 작성 후 commit and push를 눌러 깃허브에 보낸다.
  5. Github repository 주소를 붙여넣고 연결한다.

 

 

※ gitegnore란?

※-1. 정의

: Git에서는 기본적으로 gitignore 파일을 제공하는데 이는 깃허브에 올라갈 파일중에 .classpath와 같은 중요하거나 소스코드와 관계 없을 경우 처리(무시)하는 기능이 있다.

 

※-2. 사용 이유

  • 팀 단위로 파일들을 공유 할 경우 .java 확장자와 같은 필요한 소스코드만 올릴 수 있다.
  • .bin과 같은 확장자 파일은 로컬 이클립스에 대한 프로젝트 정보가 들어있고, .class과 같은 경우는 컴파일 된 파일이기 때문에 다른 파일들과 섞이면 에러가 빈번해 계속 project clean 해야 하는 등 이러한 문제 발생을 줄일 수 있다.
  • https://www.toptal.com/developers/gitignore에서 필요한 gitegnore 요소들을 커스터 마이징 할 수 있다.

 

 

3. 이클립스 - 소스트리 - 깃허브 간 연결

  1. New tab => Add => 탐색 => 프로젝트 폴더 검색 => 추가
  2. History탭을 보면 이클립스에서 commit, push한 커밋 메시지 내용이 보인다.
  3. 코드 내용을 변경하면 스테이지에 올라가지 않은 파일이 생기는데 + 버튼을 눌러서 스테이지에 올라간 파일로 옮겨준다. 이 후 커밋메시지 작성 후 커밋버튼을 누른다.
  4. History탭에서 master 브랜치로 커밋된 것을 확인한다. 단, branch에서 master 브랜치는 local(이클립스 즉 본인)을 의미하고 origin/master 브랜치는 서버(github)를 의미한다.
  5. push 버튼을 누르고 커밋된 항목을 체크하여 깃허브로 전송한다.
  6. 깃허브에 푸시한 내용이 반영되었는지 확인한다.

 

 

4. Rollback

Way-1(추천)

: 이전 버전의 소스를 복사해서 이클립스 상에 붙여넣고 새로 commit과 push 절차를 진행한다.

 

Way-2

: 히스토리 상에서 맨 마지막 버전부터 커밋 되돌리기(revert)를 한다. 단, 최초로 푸시한 내용을 커밋 되돌리기 기능을 이용해선 안된다.

 

 

5. 새로운 환경에서 깃허브에 있는 작업물 가져오기(import)

  1. 이클립스의 Git Repository에 있는 Clone Git Repositry 버튼을 누른다.
  2. Clone Git Repositry에서 깃허브의 주소를 가져오고 각 항목들을 체크한 뒤 next를 누른다.
  3. 브랜치가 master로 되어있는 것을 확인하고 체크한뒤 next를 누른다.
  4. 경로를 자기가 원하는 workspace에 지정하고 finish를 눌러 clone한다.
  5. Clone Git Repositry에 새로 생성된 git항목을 확인하고 오른쪽 버튼을 눌러 import projects 버튼을 누른다.
  6. 경로와 import 하고자 하는 항목이 제대로 체크 되었는지 확인후 finish를 하여 정상적으로 import 되었는지 확인한다.

 

 

6. 브랜치 생성 및 머지

  1. 소스트리에서 상단의 Branch 버튼을 눌러 명칭에 맞는(develop) 브랜치를 생성한다.
  2. 소스트리 좌측메뉴에서 생성된 브랜치를 확인한 후 활성화한다.
  3. 이클립스에서 변경하고자 하는 소스코드를 구현 후 commit/push를 통해 master 브랜치에 해당되는 리포지토리에 보낸다.
  4. 마스터 브랜치 측에서 pull & request 요청이 뜨면 develop 브랜치가 보낸 소스코드를 확인 후 최종적으로 승낙하여 머지를 한다.
  5. 머지된 소스코드가 브랜치별로 반영되었는지 확인한다.

 

※. merge에 대해 개인적으로 생각하는 절차

  1. master branch에 해당되는 팀장이 본인 계정 깃허브에 repository를 생성하고 프로젝트 틀만 commit/push하여 등록한다.
  2. master branch(팀장)는 여러 develop branch들을 생성하여 팀원들에게 배분한다.
  3. 각 develop branch를 배분받은 팀원들은 역할에 따라서 소스코드를 구현한다.
  4. 팀원들은 소스코드 구현이 완료되면 commit/push를 하여 팀장 깃허브에 해당 repository로 merge 요청을 한다.
  5. master branch는 마지막에 최종적으로 merge request 된것들을 수렴하여 response후 깃허브에 반영한다.

 

 

7. 컨플릭트 예방

  1. 소스코드의 변경사항이 있을때 소스트리 상단 메뉴에서 Fetch한다.
  2. Pull 항목이 생성되면은 master 브랜치부터 차례대로 절차를 진행한다.
    ※ 가급적이면 master 브랜치에서 작업하지 않고 별도의 develop 브랜치를 생성한다.

 

 

8. 컨플릭트 대처

  1. 머지할때 컨플릭트 에러가 뜰 경우 깃이 표시해주는 해당 부분을 체크한다.
  2. 이 부분을 지우는 것이 최선이나 협업자와 반드시 먼저 상의하여 진행한다.
  3. 컨플릭트 부분을 해결하고 fetch 기능을 사용하여 master 브랜치부터 차례대로 pull 작업을 진행 후 최종적으로 push한다.