참고사이트(https://zimt.tk/Github-SourceTree-1562ba21b4444ea3a57c40f9f5f26631)
1. 깃허브에서 Repository 생성
: 깃허브에 반영할 프로젝트에 맞게 repository를 생성한다.
2. 이클립스(STS)에서의 사전작업
- 깃허브에 넣을 프로젝트를 지정한다.
- 프로젝트 폴더에 사전에 커스터마이징 한 gitignore 파일을 넣는다. (반드시 깃허브 연결전에 넣어야 한다.)
- 깃허브와 연결하기 위해 Team => Share project => Use or Create repository in parent folder of project => Create Repository => Finish한다.
- Git Staging의 Unstaged Chages를 Staged Changes로 옮기고 commitMessage에 커밋내용 작성 후 commit and push를 눌러 깃허브에 보낸다.
- Github repository 주소를 붙여넣고 연결한다.
※ gitegnore란?
※-1. 정의
: Git에서는 기본적으로 gitignore 파일을 제공하는데 이는 깃허브에 올라갈 파일중에 .classpath와 같은 중요하거나 소스코드와 관계 없을 경우 처리(무시)하는 기능이 있다.
※-2. 사용 이유
- 팀 단위로 파일들을 공유 할 경우 .java 확장자와 같은 필요한 소스코드만 올릴 수 있다.
- .bin과 같은 확장자 파일은 로컬 이클립스에 대한 프로젝트 정보가 들어있고, .class과 같은 경우는 컴파일 된 파일이기 때문에 다른 파일들과 섞이면 에러가 빈번해 계속 project clean 해야 하는 등 이러한 문제 발생을 줄일 수 있다.
- https://www.toptal.com/developers/gitignore에서 필요한 gitegnore 요소들을 커스터 마이징 할 수 있다.
3. 이클립스 - 소스트리 - 깃허브 간 연결
- New tab => Add => 탐색 => 프로젝트 폴더 검색 => 추가
- History탭을 보면 이클립스에서 commit, push한 커밋 메시지 내용이 보인다.
- 코드 내용을 변경하면 스테이지에 올라가지 않은 파일이 생기는데 + 버튼을 눌러서 스테이지에 올라간 파일로 옮겨준다. 이 후 커밋메시지 작성 후 커밋버튼을 누른다.
- History탭에서 master 브랜치로 커밋된 것을 확인한다. 단, branch에서 master 브랜치는 local(이클립스 즉 본인)을 의미하고 origin/master 브랜치는 서버(github)를 의미한다.
- push 버튼을 누르고 커밋된 항목을 체크하여 깃허브로 전송한다.
- 깃허브에 푸시한 내용이 반영되었는지 확인한다.
4. Rollback
Way-1(추천)
: 이전 버전의 소스를 복사해서 이클립스 상에 붙여넣고 새로 commit과 push 절차를 진행한다.
Way-2
: 히스토리 상에서 맨 마지막 버전부터 커밋 되돌리기(revert)를 한다. 단, 최초로 푸시한 내용을 커밋 되돌리기 기능을 이용해선 안된다.
5. 새로운 환경에서 깃허브에 있는 작업물 가져오기(import)
- 이클립스의 Git Repository에 있는 Clone Git Repositry 버튼을 누른다.
- Clone Git Repositry에서 깃허브의 주소를 가져오고 각 항목들을 체크한 뒤 next를 누른다.
- 브랜치가 master로 되어있는 것을 확인하고 체크한뒤 next를 누른다.
- 경로를 자기가 원하는 workspace에 지정하고 finish를 눌러 clone한다.
- Clone Git Repositry에 새로 생성된 git항목을 확인하고 오른쪽 버튼을 눌러 import projects 버튼을 누른다.
- 경로와 import 하고자 하는 항목이 제대로 체크 되었는지 확인후 finish를 하여 정상적으로 import 되었는지 확인한다.
6. 브랜치 생성 및 머지
- 소스트리에서 상단의 Branch 버튼을 눌러 명칭에 맞는(develop) 브랜치를 생성한다.
- 소스트리 좌측메뉴에서 생성된 브랜치를 확인한 후 활성화한다.
- 이클립스에서 변경하고자 하는 소스코드를 구현 후 commit/push를 통해 master 브랜치에 해당되는 리포지토리에 보낸다.
- 마스터 브랜치 측에서 pull & request 요청이 뜨면 develop 브랜치가 보낸 소스코드를 확인 후 최종적으로 승낙하여 머지를 한다.
- 머지된 소스코드가 브랜치별로 반영되었는지 확인한다.
※. merge에 대해 개인적으로 생각하는 절차
- master branch에 해당되는 팀장이 본인 계정 깃허브에 repository를 생성하고 프로젝트 틀만 commit/push하여 등록한다.
- master branch(팀장)는 여러 develop branch들을 생성하여 팀원들에게 배분한다.
- 각 develop branch를 배분받은 팀원들은 역할에 따라서 소스코드를 구현한다.
- 팀원들은 소스코드 구현이 완료되면 commit/push를 하여 팀장 깃허브에 해당 repository로 merge 요청을 한다.
- master branch는 마지막에 최종적으로 merge request 된것들을 수렴하여 response후 깃허브에 반영한다.
7. 컨플릭트 예방
- 소스코드의 변경사항이 있을때 소스트리 상단 메뉴에서 Fetch한다.
- Pull 항목이 생성되면은 master 브랜치부터 차례대로 절차를 진행한다.
※ 가급적이면 master 브랜치에서 작업하지 않고 별도의 develop 브랜치를 생성한다.
8. 컨플릭트 대처
- 머지할때 컨플릭트 에러가 뜰 경우 깃이 표시해주는 해당 부분을 체크한다.
- 이 부분을 지우는 것이 최선이나 협업자와 반드시 먼저 상의하여 진행한다.
- 컨플릭트 부분을 해결하고 fetch 기능을 사용하여 master 브랜치부터 차례대로 pull 작업을 진행 후 최종적으로 push한다.
'WebDev > 본과정' 카테고리의 다른 글
Spring Boot의 정적 리소스 처리 (0) | 2021.05.17 |
---|---|
Spring Boot의 테스트와 깃 형상관리 (0) | 2021.05.17 |
Log4j와 스프링 부트 기초 (0) | 2021.05.17 |
스프링 시큐리티의 세션, 공격기법 대처 및 소셜 로그인 (0) | 2021.05.17 |
스프링 시큐리티를 이용한 로그인 (0) | 2021.05.17 |
최근댓글