eclipse EGit 시나리오별 사용법

git에 대한 개념적인 설명보다는 실무에서 무리 없이 사용할 수 있는 범위로 상황별 시나리오를 작성한다.

각각의 시나리오는 A, B 개발자가 Git을 함께 쓰는 것을 예로 든다.

1. 개발자A 새로운 파일 생성 후 로컬 리포지토리에 commit

---

이클립스에서 newFile1.txt 파일을 새로 생성하게 되면 해당 파일은 Untracked file의 상태를 가진다.

Untracked file의 의미는 Git에서 관리대상에 포함되지 않는 다는 의미이다.

이제 파일을 로컬 리포지토리에 commit해보자.

프로젝트를 클릭 한 후 team > Synchronize 를 실행하면 newFile1.txt 파일이 목록에 보이게 된다.

이제 해당 파일 commit을 해보려고 하면 commit을 할 수 없다. 커밋 버튼이 비활성화 되어 있거나 commit 다이얼로그 팝업창에 newFile1.txt 파일이 보이지 않을 것이다.

이유는 git에서는 파일의 상태를 3가지로 분류하기 때문이다.

Commited : 데이터가 로컬 데이터베이스에 안전하게 저장

Modified : 수정한 파일을 아직 로컬 데이터베이스에 Commit 하지 않음

Staged : 수정 파일을 곧 Commit 할 것

즉, Untracked file을 Staged 영역으로 추가해 주는 작업을 선행으로 해줘야 commit이 가능하다.

이클립스에서 파일을 Staged 하기 위해서는 Add to Git Index를 선택해 주면 된다.

자~ 이제 커밋을 하게 되면 로컬 리포지토리에 파일의 snapshot이 저장될 것이다.

2. 개발자A 로컬 리포지토리에 commit한 파일 remote 리포지토리에 push하기

---

push 방법은 간단하다.

프로젝트 선택 > Team > Push to Upstream을 클릭하면 정상적으로 서버에 반영이 된다.

3. 개발자A가 push한 소스 개발자B가 받기 (상황 : 개발자B는 로컬에서 아무런 수정 작업을 하지 않았음)

---

소스를 받을 때에는 프로젝트 선택 > Team > Pull 클릭하면 끝

4. 개발자A가 push한 소스 개발자B가 받기 (상황 : 개발자B는 로컬 리포지토리에 test2.txt라는 파일을 수정 후 commit하였다.)

---

Pull을 받으면 update Result의 상태가 Merged인 것을 확인 할 수 있다. 이는 이클립스의 머지툴이 자동적으로 로컬 리포지토리와 원격 리포지토리를 머지했다는 의미이다.

5. 개발자A가 push한 소스 개발자B가 받지 않고 push하기

---

이런 경우 git server로부터 rejected 된다.

기본적으로 git은 다른 사람이 push한 후에 내가 push하려고 하면 push할 수 없고, 다른 사람이 작업한 것을 가져와 머지한 후 push를 해야 한다. 머지 작업은 충돌되는 파일이 없다면 자동으로 해줌

6. 개발자A가 newFile1.txt 파일 수정 후 push하였고, 개발자B도 newFile1.txt 파일을 수정하였지만 커밋은 하지 않았음 (서로 다른 코드 라인을 수정)

---

pull을 받을 경우 conflict 오류가 발생하는 것을 알 수 있다.

이런 경우에는 newFile1.txt 파일을 commit하고, 다시 pull을 받아 보도록 하자.

정상적으로 pull을 받으며 newFile1.txt 파일이 merge 되는 것을 알 수 있다.

pull을 받기 전에는 로컬에서 수정된 파일을 모두 로컬 리포지토리에 반영 시켜 놓은 것이 이와 같은 오류를 방지하는 좋은 방법이 될 것 같음.

7. 개발자A가 newFile1.txt 파일 수정 후 push하였고, 개발자도 newFile1.txt 파일을 수정 후 commit 하였음 (서로 같은 코드 라인 수정)

---

프로젝트 선택 > team > Synchronize 실행하여 수종 merge 작업을 진행해야 한다.

이번 작업에서는 overwrite를 이용하여 원격지의 소스를 로컬 소스에 덮어 치는 방법으로 충돌을 해결하고, 로컬 소스를 commit 하였다.

이후 push하면 문제 해결

여기서 만약 Synchronize 를 실행하지 않은 상태에서 pull을 받으면 충돌난 파일이 다음과 같이 Result는 Conflicting 되어 있을 것이고, 소스는 다음과 같아진다.

<<<<<<< HEAD

add changed17

=======

add changed16

>>>>>>> branch 'master' of https://lng1982@dev.naver.com/git/namkyugit.git

HEAD 영역이 로컬 소스이고, 아래가 원격지의 소스이다.

적절하게 수정 후 Synchronize를 실행하고, 충돌난 파일을 클릭 한 후 Mark as Merged 를 클릭하면 된다.

이후 commit한 뒤 push하면 된다.

8. 브랜치를 이용한 개발 진행 (개발자A에게 회원 관리를 개발하라는 오더가 떨어졌다.)

master 브랜치는 현재 운영 중인 시스템의 소스이므로 새로운 브랜치를 생성한다.

프로젝트 선택 > Team > Switch to > New Branch

dev_member 입력 후 완료

이제 dev_member 브랜치로 프로젝트가 전환되어 있는 것을 확인할 수 있다.

개발자A는 회원 관리를 하루만에 완료하고, 로컬 리포지토리에 커밋한다. (능력자~)

이제 dev_member 브랜치에 커밋된 소스를 master 브랜치와 merge해야 한다.

먼저 master 브랜치로 전환을 한 후 프로젝트 선택 > Team > Merge 선택한다.

다음의 이미지를 보면 master 브랜치가 체크되어 있는 것은 현재 프로젝트에서 활성화 되어 있는 브랜치를 의미하고, dev_member브랜치와 머지를 하기 위해서는 dev_member 브랜치를 선택 후 "Merge" 버튼을 클릭하면 자동으로 머지가 된다.

이클립스의 EGit 환경을 기반으로 시나리오별 git 사용 방법에 대해서 정리를 하였으며 이후 개발을 진행하면서 겪게 되는 문제점들이나 추가되어야 할 필요성이 있는 시나리오가 있으면 추가할 예정이다.