Eclipse에서의 Git 활용 - 3: local repository와 commit

프로젝트 생성과 git 연동

먼저 eclipse에서 새로운 프로젝트를 생성하고 local에서 git을 사용해보자.

 

프로젝트 생성

프로젝트 생성에 대해서는 별로 할 말이 없다. 평소 하던대로 프로젝트를 생성한다.

 

local repository 연결

 

share project

생성된 프로젝트의 버전 관리를 위해서는 먼저 프로젝트를 공유 해야 한다. 프로젝트 오른 클릭 후 Team --> Share Project를 선택한다.

그럼 local repository를 설정할 수 있는 configure Git Repository 메뉴가 나온다.

repository 정보를 다른 경로에 만들 수도 있지만 그냥 현재 프로젝트 경로에 만들어주기 위해 Use or create repository in parent folder of project를 체크한다.

 

다음 화면에서 체크박스를 선택해서 경로를 결정한 후 [Create Repository] 버튼을 클릭해서 .git 파일을 생성하면 Finish 버튼이 활성화된다.

마지막으로 Finish를 클릭하면 local repository가 완성된다.

그 결과로 해당 경로에는 숨김 파일로 .git 폴더가 생성되고 버전 관리와 관련된 여러 정보가 등록된다.

 

command line

command line에서 위 과정은 git init 명령을 사용하면 된다.

❯ git init
Initialized empty Git repository in /Volumes/Data/temp/test/.git/

❯ ls -al
total 0
drwxr-xr-x@ 3 quietjun  staff   96  7 11 13:58 .
drwxr-xr-x  5 quietjun  staff  160  7 11 13:57 ..
drwxr-xr-x@ 9 quietjun  staff  288  7 11 13:58 .git

 

egit의 소스 상태 표현

프로젝트가 만들어졌다면 소스 코드를 관리해보자.

이클립스는 다양한 모습의 아이콘으로 소스의 상태를 나타낸다.

상태	아이콘	의미
dirty(folder)		폴더에 > 표시는 폴더 내부에 최소 하나 이상의 파일이 dirty 하다는 의미이다. 이 의미는 working tree에 변경된 내용이 있고 아직 staging area나 repository에 반영되지 않았다는 이야기이다.
tracked		git repository에 등록된 리소스이고 버전 관리되고 있는 대상이다.
untracked		git repository에 등록된 적이 없는 리소스이고 당연히 버전 관리 대상이 아니다.
ignored		.gitignore의 설정에 의해 무시되는 리소스들이다.
dirty(file)		리소스가 working tree에서 변경되었고 아직 staging area나 repository에 반영되지 않았다.
staged		리소스가 add 명령에 의해 staging area에 등록된 상태이다.
partially-staged		staging area에 있는 상태인데 다시 수정된 경우이다.
added		아직 한번도 commit 된적이 없는 리소스가 add된 경우이다.
removed		리소스가 삭제되기 위해 staging area에 있는 상태이다.
conflict		merge 과정에서 파일이 충돌한 상태이다.
assume-valid		이 리소스는 변경되지 않는 것으로 간주하므로 git이 모니터링 하지 않는다.

 

command line

command line에서 리소스의 상태를 확인하기 위해서는 git status 명령을 사용한다.

❯ git status
On branch master
Untracked files:
  (use "git add <file>..." to include in what will be committed)
	src/

 

리소스 상태 관리

새로 Test.java를 만들고 git에서 관리해보자.

package gittest;

public class Test {

}

새롭게 파일을 만들면 untracked 상태이다. 즉 git 입장에서는 처음 보는 녀석이라 관리 대상도 아니다.

 

resource 관리

프로젝트를 오른 클릭해서 Team > commit을 클릭하면 Git Staging View를 확인할 수 있다. 여기서는 git이 working tree --> staging area --> repository의 단계로 리소스를 관리하는 단계를 처리한다.

현재 unstaged changes 즉 working tree에는 변경이 있는데 아직 staged나 commit 되지 않은 즉 dirty 상태의 리소스들을 보여준다. 흥미로운 점은 우리가 만든 소스코드는 Test.java 하나인데 나머지 군더더기 파일들이 많이 생성된 것을 볼 수 있다.

이런 자동 생성파일들은 다른 팀원간의 리소스 공유 시 환경이 달라서 문제가 될 수 있다.  이와 관련된 내용은 뒤에 .gitignore 항목에서 살펴보자.

이제 [+] 나 [++] 버튼을 이용해서 리소스들을 staged changes로 이동시킨다.

상태 아이콘들이 처음으로 commit 대상이 된다는 의미(staged 상태)로 + 표시로 변경된다.

아직 특별한 branch를 만들지 않은 상태이고 이번에 commit 하게 되면 master branch를 생성한다는 내용도 보인다.

command line

command line에서 dirty 상태의 resource를 state로 옮기기 위해서는 git add 명령을 사용한다. stage의 resource를 dirty로 되돌릴 때 전체를 다 되돌리기 위해서는 git reset, 개별 파일을 지정할 때에는 git restore --staged <file>...을 사용한다.

❯ git add .
❯ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	new file:   src/gittest/Test.java

❯ git reset
❯ git status
On branch master
Untracked files:
  (use "git add <file>..." to include in what will be committed)
	src/

nothing added to commit but untracked files present (use "git add" to track)

 

.gitignore 설정

프로젝트를 진행하다 보면 우리가 만드는 소스 코드 이외에 여러가지 부산물들이 생성된다. 컴파일된 결과물이라든가 클래스 패스, 프로젝트 설정 등 생각보다 많은 것들이 등록된다. 그런데 이런 것들이 소스코드처럼 모두에게 필요한 것은 아니다.

예를 들면 컴파일 결과인 .class들은 어차피 개발자들이 따로 컴파일을 진행할 것이기 때문에 필요가 없다. 일반적으로 git에서는 공유할 필요가 없어서 무시할 내용들을 .gitignore 파일에서 관리한다.

 

.gitignore 의 파일 규칙

.gitignore는 프로젝트의 최상단 폴더에 작성하게 된다.(물론 각각의 하위 폴더별로 .gitignore를 배치하여 그 폴더의 규칙을 재정의 할 수 있다.)

.gitignore 파일에 입력하는 패턴은 다음의 규칙을 따른다. 자세한 내용은 아래 링크의 파일 무시하기 부분을 참조한다.

Git - 수정하고 저장소에 저장하기

 

gitignore 파일 생성 사이트 활용

하지만 툴에서 만들어지는 설정 파일들이나 프로젝트 부산물들을 다 파악해서 .gitignore 파일을 만들기는 쉽지 않다. 따라서 OS나 IDE, 언어별로 template을 이용하는 경우가 많다.

gitignore.io 사이트는 이런 작업을 아주 수월하게 처리해준다. www.toptal.com/developers/gitignore

gitignore.io

사이트의 입력 창에 eclipse와 나중에 사용하게될 vscode를 입력 후 Create 버튼을 누르면 일반적으로 이클립스에서 무시할 파일들이 등록된 .gitignore를 확인할 수 있다.

 

# Created by https://www.toptal.com/developers/gitignore/api/eclipse,vscode
# Edit at https://www.toptal.com/developers/gitignore?templates=eclipse,vscode

### Eclipse ###
.metadata
bin/
tmp/
*.tmp
*.bak
*.swp
*~.nib
local.properties
.settings/
.loadpath
.recommenders

# 중간 생략

### vscode ###
.vscode/*
!.vscode/settings.json
!.vscode/tasks.json
!.vscode/launch.json
!.vscode/extensions.json
*.code-workspace

# End of https://www.toptal.com/developers/gitignore/api/eclipse,vscode

eclipse에서 현재 project의 root에 .gitignore 파일을 만들고 위 내용을 붙여주자.

 

 

그리고 git이 .ignore의 내용을 알 수 있도록 .gitignore 파일만 stated changes에 등록 후 commit 처리를 해준다.commit 시에는 commit message가 필수이므로 적절한 메시지를 추가해주어야 한다.

 앞으로는 프로젝트를 만들고 git으로 관리하겠다고 생각하면 제일 처음에 진행할 일이 .gitignore파일을 챙기는 일이다.

 

.classpath와 .project

.classpath와 .project는 프로젝트를 구성하는 메타 파일들이다. 만약 이 파일들이 없다면 프로젝트는 재대로 구성되지 않고 에러를 발생시킬 것이다. 따라서 위의 설정에서는 이 파일들을 모두 포함시켜 놓은 상태이다.

하지만 뒤에 배울 협업의 단계에 가면 이 파일들이 있는 것이 오히려 문제를 일으킬 수 있다. 예를 들어 A는 라이브러리를 C:\ssafy에서 관리하고 B는 d:\ssafy에서 관리한다고 하자. A가 .classpath를 공유하고 B가 그 파일을 받아서 사용하려면 본인의 환경에 맞게 수정해야 한다. B가 수정한 파일이 서버에 등록되고 A가 내려받으면 다시 수정하는 핑퐁이 발생한다.

 

물론 가장 쉬운 방법은 A와 B가 환경까지 완전히 맞추는 것이지만 대다수 팀으로 구성된 경우 쉽지 않다. 

따라서 .classpath와 .project 파일은 관리해야할 소스가 아니므로 ignore에 등록하는게 맞다. .gitignore파일에서 다음의 내용을 확인하고 주석을 해지해주자. 추가로 .classpath 파일도 등록한다.

# Uncomment this line if you wish to ignore the project description file.
# Typically, this file would be tracked if it contains build/dependency configurations:
.project
.classpath

 

이제 repository에는 프로젝트 구성에 필요한 파일이 없어졌기 때문에 이 repository를 clone 하더라도 바로 프로젝트를 생성할 수 없다. 따라서 이런 파일 없이도 프로젝트를 구성할 수 있도록 project의 [Java Build Path] 속성이나 [Project Facets], [Project Natures]속성을 읽고 편집하는 능력을 키우는 노력을 할 필요가 있다.

 

공유 리소스 관리

 

코드 커밋 하기

이제 UnStated Changes에는 우리가 작성한 소스파일만이 남아있게 되었다.

Test.java 파일을 stated area로 이동시키고 commit 메시지 작성 후 commit 해보자. 이제 리소스는 commit 상태로 되어 local repository에 완전히 반영되게 된다. 

commit이 완료된 후 파일의 상태를 보면 tracked로 변경되어있다. 아울러 프로젝트는 master branch를 사용하고 있음을 알 수 있다.

 

command line

command line에서 commit 하려면 git commit -m <message> 를 사용한다.

❯ git commit -m "first commit"
[master e90bab6] first commit
 1 file changed, 10 insertions(+)
 create mode 100644 src/gittest/Test.java
❯ git status
On branch master
nothing to commit, working tree clean

 

소스 변경 하면서 상태 살펴보기

Test.java파일을 일부 변경해서 다시 unstaged changes로 이동시켜보자.

package gittest;

public class Test {
    String first = "first";
}

 

이제 unstaged changes에는 변경되서 dirty 상태인 Test.java 파일만 존재한다. 파일을 오른쪽 클릭해서 살펴보면 리소스의 상태를 변경할 수 있는 다양한 기능들이 재공된다.

이중 [Replace with HEAD Revision]는 HEAD  버전으로 리소스를 되돌린다. HEAD란 현재 브랜치에서 작업자가 사용하고 있는 버전을 의미(마지막으로 커밋한 버전)한다. 즉 현재의 변경 사항을 취소하는 것이다.

여기서는 취소하지 말고 commit 시켜주자.