티스토리 뷰

[DEV] 개발툴

eclipse EGit 시나리오별 사용법

공부하는 규우82 2014.01.18 09:29

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 사용 방법에 대해서 정리를 하였으며 이후 개발을 진행하면서 겪게 되는 문제점들이나 추가되어야 할 필요성이 있는 시나리오가 있으면 추가할 예정이다.





TAG
,
댓글
  • 프로필사진 비밀댓글입니다 2014.03.04 23:39
  • 프로필사진 공부하는 규우82 물론입니다. ^^ 2014.03.05 20:26 신고
  • 프로필사진 주니어개발자 감사합니다 잘 읽고 잘 배웠습니다!
    로컬은 eGit 원격지는 Github를 사용해 프로젝트 버전관리를 하고자 하는데
    혹시 팀단위 개발프로젝트 진행시 기능사용이나 매커니즘 이해 미숙으로 겪게 되는 문제점을 애초에 피해서 작업을 진행하려면 처음에 어떻게 규칙이나 약속을 정하고 활용해야 할지 고민이에요.
    같은 주제로 혹시 더 추가되는 시나리오나 루틴에 대해 칼럼 써주시면 얼른 또 보러올게요 감사합니다!
    2019.05.25 23:39
  • 프로필사진 공부하는 규우82 안녕하세요. 제가 이해한게 맞는지는 모르겠지만 답변 달아봅니다.

    Q : "팀 단위 개발프로젝트 진행 시 기능 사용이나 매커니즘 이해 미숙으로 겪게 되는 문제점"

    A : 사실 git 에 대해서 개발팀 모두가 잘 이해하고 있다면 겪지 않으리라 봅니다. 하지만 기존의 CVS, SVN과 다소 다른 방식으로 동작하기에 Git을 잘 모르시는 분들은 어려워 하실 수도 있는데요. 잘 아시는 분이 교육 전파를 하는 것도 하나의 방법이 될 수 있을 것 같습니다.
    일반적으로 실무에서는 다음의 방법들을 미리 정의하고 있습니다.
    - 브랜치 전략 (develop, feature, master, hotfix 관련)
    - commit 규칙
    - 언제 커밋할 것인가?
    - rebase 사용을 통해 커밋 로그 합치기


    최근에 바쁜일이 많아서 블로깅을 잘 못하고 있는데 여유가 있는 시간에 위와 관련된 이야기를 작성해 보도록 하겠습니다.

    감사합니다.
    2019.05.29 19:31 신고
댓글쓰기 폼