2) Navigator 창에서 프로젝트 선택 후 마우스 오른쪽 버튼을 클릭한다. Team> Share Project를 클릭한다.
3) Configure Git Repository 창이 뜨면 Create를 클릭한다.
4) Repository Directory를 지정하고 Finish를 클릭한다.
5) Git Repository 창을 보면 추가된 프로젝트를 볼 수 있다.
2. Remote 저장소와 연결하기
1) Git Repository 창에서 해당하는 프로젝트를 펼친다. Remote 항목 위에서 마우스 우클릭 후 Create Remote를 클릭한다.
2) Remote 이름을 넣고 OK 클릭.
3) Configure Push 창이 나오면 Change 버튼을 클릭한다.
4) 이전에 만들어 둔 서버 URI를 입력한다. Protocol을 지정하고 User와 Password를 입력한 후 Finish 클릭.
5) Configure Push 창이 다시 보인다. Save and Push를 클릭하면 현재 파일을 Remote에 올리게 되고 Save를 클릭하면 서버에 올리지 않고 Remote 정보만 저장한다. 현재는 로컬 저장소에 Commit하지 않았으므로 Save and Push를 클릭하면 에러가 발생한다. 먼저 로컬 저장소에 Commit하고 Remote에 Push할 수 있다. 따라서 여기에서는 Save를 클릭한다.
3. Commit – 로컬 저장소에 저장하기
1) Commit을 하려면 저장하고 싶은 파일과 폴더를 선택하여 Git Staging 창의 Staged Changes에 끌어 넣는다. Commit Message도 작성해야 한다.
2) Commit 목록에서 빼고 싶으면 해당파일에서 마우스 우클릭하여 Remove from Index를 클릭하면 Unstaged Changes로 이동한다. Unstaged Changes에서 Ignore를 하면 저장에서 제외된다. .gitignore 목록에 올라간다.
3) Commit 버튼을 클릭한다. [NO-HEAD]가 master로 바뀌었다.
4. Push – 로컬 저장소에서 Remote로 소스 보내기
1) Push Branch ‘master’를 클릭.
2) Next 클릭.
3) Finish 클릭.
4) 이상이 없으면 다음 창이 뜬다. OK를 클릭하고 Remote에 올라갔는지 확인해 본다.
5) Remote에 저장된 파일들이 보인다.
6. 작업 저장
1) 이후에 변경된 파일을 올리려면 Team> Add to Index한다.
2) Git Staging 창에 보면 Staged Changes에 변경된 파일이 보인다.
3) Commit and Push를 하면 Local과 Remote 모두에 저장이 되고 Commit을 하면 Local에만 적용된다.
전 사실, svn을 쓰다가 git으로 넘어와서 그런지,처음에는 개념이 잘 이해가 안되었었어요.
그저 git을 사용했던 사람들에게 들어서 이정도는 알고 있었죠.
빠르다.
모두가 원본을 가진다.
local에서 대부분의 작업을 할 수 있다.
그리고 대부분의 VCS(version control system)처럼 git도 이런 개념들을 가지고 있습니다.
(svn에도 trunk, branch, tag가 있죠.)
master
branch
tag
svn을 쓰던 분들은 trunk가 master로 바뀌었다고 생각하면 됩니다.
'뭐가.. 어떻게 다르다는 거야?'
'그래서 그렇게 해서 어떻게 하겠다는건데?'
음.... 이런 생각이 드실거에요.
사실 subversion(svn)을 사용하면서 제가 느꼈던 힘들었던 부분은, 다른 사람과의 공동작업에 있어서 코드를 통합하는 경우(merge, commit)에 너무 많은 충돌을 경험했었다는 것이죠.
실제 버전이 관리되는건(사람들은 svn 서버에 있는 코드를 받아서 작업하는것) 서버에서 해주는 일이었기에, 어쨋든 작업을 하게 되면, 서버로 코드가 모이게 됩니다.
이때 여러 사람이 동시에 작업하던 클래스나 파일이 있다면.... 이제부터 힘겨워지기 시작하는거죠.
git을 사용하면 이런 대부분의 문제들에 대해서 자유로워질 수 있습니다.(라고 생각하는 중...)
Git을 혼자서 사용한다면,
그저 그 자체로도 branch를 만들고, 코드를 commit하고 merge하는 등 모든 버전관리 기능을 다 사용할 수 있어요.
자신의 컴퓨터에 있는 repository(local의 repository)에서 모든 것을 다 할 수 있다.
예를들면, 이런 느낌이에요.
subversion을 사용할때, 혼자서 svn 서버를 돌리면서, 혼자서 서버에 commit하고 등등을 한다면..
Git을 사용했을 때는, 혼자서 쓴다면 서버가 필요없죠. [local]에서 모든것을 다 할 수 있으니까요.
git에서는 자신의 local repository가 svn의 서버에 있는 repository처럼 동작한다는것이죠.
하지만리누스 토발즈느님께서 Git을 그렇게만 쓰라고 만든게 아니지요.
(위 wiki 인용부에도 나와있지만, 원래는 리눅스 커널 개발에서 버전관리등을 하려고 개발한게 git이라고 하지요.)
Git은 DVCS(Distributed version control system)이잖아요.
원격지의 repository에 연결을 해서 다같이 작업을 해야 제 맛(?)인게 git이라고 할 수 있어요.
그리고 github.com 에 repository를 등록하고 프로젝트를 올리고 해봐야 더 재밌죠.
git의 장점은 여러사람이 함께 프로젝트를 진행할때 알 수 있습니다.
git에서는 내가 코드를 작성하다가, 다른 사람이 진행하고 있는 branch에 가서 코드를 보거나 특정 부분에 가서(특정 commit이나 특정 tag) 코드를 보다가 다시 내가 작업하던 코드로 돌아오고 하는 것들이 너무나 자연스럽고 빠릅니다.
처음에 제가 최신의 마스터 소스코드를 받아왔다고 해 봅니다.(pull)
어떤 특정 부분을 지정해서 그 부분을 보고 있는 상태를 [checkout]이라고 합니다.
즉,저는 master를 checkout해서 보고 있는 거죠.
이제 옆에 빨간색으로 보이는데로 이동을 해서 코드를 보고 싶습니다.
그러면 그저 그 부분으로 checkout을 하기만 하면 됩니다.
이렇게 그 부분(빨간색 branch의 어떤 특정 commit)으로 체크 아웃을 하면, 그 부분을 보게 되는거죠.
다시 원래의 마스터 최신 코드로 돌아오는것도 master의 최신 commit을 checkout 하기만 하면 됩니다.
이때, 내 컴퓨터(local)에는물리적으로 한 세트의 소스코드만 존재한다는 것이죠.
소스코드의 세트를 여러개 받아놓고 작업을 할 필요가 없습니다. 예전에 작업하던 곳으로 돌아가더라도, 소스코드는 한 세트만 가지고 있으면 되는거죠.
이게 가능하게 되는건, git이 포인터를 사용하기 때문입니다.
이 말인즉슨, 각각의 branch, commit, tag에 대해서 git은 포인터로 처리를 하고 저장한다는 것입니다.
그래서 이 태그에서 저 태그로, 이 브랜치에서 저 브랜치로 옮겨 다니면서도 빠르게 문제없이 옮겨다니며 작업할 수 있는것이죠.
단지'내가 보고 있는 곳의 포인터를, 다른곳의 포인터로 바꿔치기'하면 되는것이니까요.
(git을 2주-3주 정도 사용해 보며, [포인터를 바꿔치기한다]라고 저는 이해를 했습니다.)
(물론 작업을 진행하며 충돌이 날수도 있고 여러가지 문제로 예전상태로 checkout이 안되는 경우도 있긴합니다만, 그럼에도 불구하고 svn에 비해서는 너무 빠르고 자연스럽군요.)
git을 '여러 사람이 사용할 때, 장점을 잘 알 수 있다.'라는 얘기에서 좀 벗어났네요. 다시 돌아와서 얘기를 해보죠.
위에서git은 local환경에서도 모든것을 다 할 수 있다.라고 했습니다.
git은 소스코드를 가진 모든 컴퓨터(모든 컴퓨터의 git repository)가 원본이 됩니다. 그래서 누군가의 컴퓨터가 망가지고, 어딘가의 소스코드가 날아가더라도, 원본 그대로의 프로젝트를 유지하기가 쉽죠.
거기에다가 local에서 모든것을 할 수 있다는 말은, 원본(내 컴퓨터의 repository도 원본이니까)에서 모든 작업을 다 할 수 있다는 것이니, 작업을 진행함에 있어서도 부담이 없습니다.
(물론, push라는 명령을 통해 메인 repository(remote라고 부르는)에 해당 사항을 적용 시켜주어야 합니다.)
이 말을 조금 다르게 하면, 내 컴퓨터에서 모든 작업을 다 하고, 해당 코드에 대한 안정성이 확보됬을때, 실제 원격의 master에 코드를 적용할 수 있다는 거죠. 그러면서도 중간중간 자신 혼자서 개발하면서 commit한 내용들에 대한 보관도 다 이루어 집니다(local에서도 commit을 할 수 있으니...).
혼자서, local에서만 작업을 했더라도, 개발 이력에 대해서 트래킹이 가능하죠.
svn이 하나의 메인 repository를 놓고 각각의 개발자들이 서브가 되어 자신이 개발한걸 메인 repository에 commit하는 형식이었다면, git은 메인 repository는 존재하지만, 각각의 개발자들이 또 다른 원본의 repository를 가지면서 작업을 하게 됩니다. 그리고 자신의 컴퓨터(local)의 repository에 commit을 하게 되고, 안정성등이 확보가 된다면 메인(remote) repository에 push를 하는 방식이 되는 거죠. 이때 이 메인 repository는 실제 github enterprise일 수 있지만, 다른 누군가의 컴퓨터일수도 있습니다. 설정하기 나름이니까요.
master에서 branch를 하나 만들어 코드를 작업하다가, 다시 master에 merge를 통해 하나의 코드로 만든다라는 거죠.
예를들어,
1. 프로젝트에서 bug가 발견되어, 이를 고쳐야 합니다. 하지만 master에서 작업하기에는 좀 껄끄럽죠. master는 안전성을 유지한 상태여야 하니까요. 이럴때, hotfix라는 branch를 하나 만들어서 작업을 진행하는거죠. 그 사이, master에는 완벽한 상태의 원본이 유지될거고, 저는 hotfix를 통해 버그를 수정할 수 있습니다. 그리고 작업이 끝나고나면 master로 merge를 하거나, 해당 커밋만 체리픽 할 수 있죠.
2. 제가 이런 작업을 진행하는 사이, 누군가는 서브기능을 추가하고 있을 수 있습니다. 단순하게 그 사람이 작업하는 branch를 sub라고 해볼게요. 그리고 그 사람은 작업을 마치고 나면 master와 sub를 merge하겠죠.
3. 그러는 사이, 누군가는 master에서 작업을 진행하고 있을수도 있죠. 열심히 commit, push를 하며 master의 코드를 고쳐나갈겁니다.
그리고 결국에 이런 1, 2, 3의 작업들을 통해 작성된 코드들은 master로 모이게 되겠죠.
그림으로 나타내 보면 이렇게 표현할 수 있습니다.
그림을 보시거나, git에 대한 설명을 여기저기서 보신 분들은 아시겠지만,
branch는 마스터로 부터 뻗어져 나온 가지입니다. 또 마찬가지로 master 또한 가지입니다. 가지보다는 기둥에 가깝겠지만요. master 라는 기둥(또는 가지, branch)로 부터 가지(branch)를 뻗어서 작업을 진행하다가, 다시 master라는 기둥(branch)으로 merge를 하는 것이죠. 가지는 한두개가 아닐 수 있고, 각각이 가지에서 작업하는 사람은 1명 이상이겠지요.
그리고 각각의 가지 안에서는 commit, push, pull이라는 작업들이 계속해서 일어날 것이고,
이런 작업들이 진행되는 동안, 파일들은 unstage, unmodified, modified, stage 상태를 왔다갔다 하겠죠.
