This is a slide which summarizes Pro Git. I have made this because I wanted to give the description of Git to my co-workers. I hope that it would be a great help to find a specific topic of Git. If you want to know more details than this, you can easily refer to the information of Pro Git because this slide has the same titles as it.
2013년 7월 13일 토요일
제가 Pro Git 내용을 요약한 자료를 공개합니다. 같이 일하는 동료들에게 Git 에 대해 소개하려고 만들었던 자료입니다. Git에 대한 특정 내용을 알고 싶을 때, 이 자료의 목차에서 내용을 찾아보기에 좋은 것 같아 블로그에 올립니다.
This is a slide which summarizes Pro Git. I have made this because I wanted to give the description of Git to my co-workers. I hope that it would be a great help to find a specific topic of Git. If you want to know more details than this, you can easily refer to the information of Pro Git because this slide has the same titles as it.
This is a slide which summarizes Pro Git. I have made this because I wanted to give the description of Git to my co-workers. I hope that it would be a great help to find a specific topic of Git. If you want to know more details than this, you can easily refer to the information of Pro Git because this slide has the same titles as it.
2013년 4월 2일 화요일
Git 과 svn 비교 - svn 대비 git의 차별점
Git에 대해 생각했던 점을 정리해보려 합니다. 이 글은 git을 처음 시작하는 분이나, 혹은 git을 이미 잘 사용하고 있는 분에게도 생각해볼 만한 유용한 내용을 공유하려는 목적으로 작성되었습니다.
git을 사용하면서 스스로에게 다음과 같은 질문을 할 때가 많았습니다.
그런데, 많은 open source projects 들이 git을 사용하고 있고, 소위 잘나가는 개발사들은 git을 기반으로한 source control을 사용합니다. 거기에는 나름의 이유가 있고, 그 이유를 정확히 알아야 우리가 각 project에 최적인 방법으로 source를 운용할 수 있습니다. 우리가 원하는 것은 결국 소스를 최신으로 유지하면서도 개발자들이 원하는대로 원하는 순간에 수정할 수 있는 방법을 찾는 것이고, 이를 달성하기 위해서는 분산 관리 방식의 장점을 정확히 이해하는 것부터 시작해야 할 것입니다.
svn으로 작업할 때에는 소스를 중앙 저장소에 commit 하기 전에 대부분의 기능을 완성해놓고 commit 하는 경우가 많습니다. 그도 그럴 것이, commit을 한다는 자체가 중앙 저장소에 내가 만든 기능을 공개한다는 뜻이기 때문입니다. 그래서 개발자가 자신만의 version history를 가질 수 없고, commit한 내용에 실수가 있을 시에 다른 개발자에게 바로 영향을 미치게 됩니다. ( 물론, branch를 따서 관리하는 방법도 있지만, 수백명의 개발자의 branch를 따로 만들어주고 관리하는 것은 굉장히 어렵습니다. )
반면, git은 개발자가 자신만의 commit history를 가질 수 있고, 개발자와 서버의 저장소는 독립적으로 관리 가능합니다. 여기서 독립적으로 관리한다는 말은 개발자의 commit이 바로 서버에 영향을 미치지 않는다는 것입니다. 개발자는 마음대로 commit하다가 자신이 원하는 순간에 서버에 변경 내역(commit history)을 보낼 수 있으며, 서버의 통합 관리자는 관리자가 원하는 순간에 각 개발자의 commit history를 가져올 수 있습니다.
통합 관리자가 각 개발자의 commit history를 가져온다는 것은, 각 개발자가 완성한 commit histroy에 대해서 통합 관리자가 차후에 아무때나 가져와 적용할 수 있다는 뜻입니다. 통합 관리자가 각 개발자의 commit history를 가져오기 전에 이미 각 개발자는 자신의 저장소와 서버의 저장소간 통합을 마친 상태이므로 통합 관리자는 별다른 어려움 없이 commit history를 가져올 수 있습니다. ( 여기서 별다른 어려움이 없다는 말은 merge conflicts가 일어나지 않는다는 말입니다. 다른 말로 Fast forward merge 라고 합니다. 클릭하면 커지는 아래 그림 참조. )
Figure 1. git repository의 commit history
이렇게 git은 서버 저장소와 개발자 저장소가 독립적으로 commit history를 가져갈 수 있기 때문에 매우 유연한 방식으로 source를 운영할 수 있으며, 이러한 유연성이 git의 가장 큰 장점입니다. 이 유연성을 바탕으로 바로 우리의 목적인 "소스를 최신으로 유지하면서도 개발자들이 원하는 때에 원하는 만큼 수정할 수 있는 방법"을 달성할 수 있는 것입니다.
따라서 svn과 다르게 git은 굉장히 다양한 방식으로 소스를 관리할 수 있으며, open source projects에서 많이 사용하는 방법들에는 다음과 같은 것들이 있습니다.
위 방식들에 대한 자세한 내용은 http://git-scm.com/book 을 참고하시기 바랍니다.
git을 사용하면서 스스로에게 다음과 같은 질문을 할 때가 많았습니다.
- git이 svn 대비 장점은 무엇일까?
- 왜 많은 조직들이 svn에서 git으로 옮기려고 하는가?
그런데, 많은 open source projects 들이 git을 사용하고 있고, 소위 잘나가는 개발사들은 git을 기반으로한 source control을 사용합니다. 거기에는 나름의 이유가 있고, 그 이유를 정확히 알아야 우리가 각 project에 최적인 방법으로 source를 운용할 수 있습니다. 우리가 원하는 것은 결국 소스를 최신으로 유지하면서도 개발자들이 원하는대로 원하는 순간에 수정할 수 있는 방법을 찾는 것이고, 이를 달성하기 위해서는 분산 관리 방식의 장점을 정확히 이해하는 것부터 시작해야 할 것입니다.
svn으로 작업할 때에는 소스를 중앙 저장소에 commit 하기 전에 대부분의 기능을 완성해놓고 commit 하는 경우가 많습니다. 그도 그럴 것이, commit을 한다는 자체가 중앙 저장소에 내가 만든 기능을 공개한다는 뜻이기 때문입니다. 그래서 개발자가 자신만의 version history를 가질 수 없고, commit한 내용에 실수가 있을 시에 다른 개발자에게 바로 영향을 미치게 됩니다. ( 물론, branch를 따서 관리하는 방법도 있지만, 수백명의 개발자의 branch를 따로 만들어주고 관리하는 것은 굉장히 어렵습니다. )
반면, git은 개발자가 자신만의 commit history를 가질 수 있고, 개발자와 서버의 저장소는 독립적으로 관리 가능합니다. 여기서 독립적으로 관리한다는 말은 개발자의 commit이 바로 서버에 영향을 미치지 않는다는 것입니다. 개발자는 마음대로 commit하다가 자신이 원하는 순간에 서버에 변경 내역(commit history)을 보낼 수 있으며, 서버의 통합 관리자는 관리자가 원하는 순간에 각 개발자의 commit history를 가져올 수 있습니다.
통합 관리자가 각 개발자의 commit history를 가져온다는 것은, 각 개발자가 완성한 commit histroy에 대해서 통합 관리자가 차후에 아무때나 가져와 적용할 수 있다는 뜻입니다. 통합 관리자가 각 개발자의 commit history를 가져오기 전에 이미 각 개발자는 자신의 저장소와 서버의 저장소간 통합을 마친 상태이므로 통합 관리자는 별다른 어려움 없이 commit history를 가져올 수 있습니다. ( 여기서 별다른 어려움이 없다는 말은 merge conflicts가 일어나지 않는다는 말입니다. 다른 말로 Fast forward merge 라고 합니다. 클릭하면 커지는 아래 그림 참조. )
따라서 svn과 다르게 git은 굉장히 다양한 방식으로 소스를 관리할 수 있으며, open source projects에서 많이 사용하는 방법들에는 다음과 같은 것들이 있습니다.
위 방식들에 대한 자세한 내용은 http://git-scm.com/book 을 참고하시기 바랍니다.
피드 구독하기:
글 (Atom)