From f31170d9cd533e7f993087b573e3b68ee2466404 Mon Sep 17 00:00:00 2001 From: Changwoo Park Date: Tue, 21 Jun 2011 01:08:45 +0800 Subject: [PATCH 1/5] initial translation. --- index.html | 853 +---------------------------------------------------- 1 file changed, 1 insertion(+), 852 deletions(-) diff --git a/index.html b/index.html index 12d19aa..b41331f 100644 --- a/index.html +++ b/index.html @@ -1,852 +1 @@ - - - - - - - Why Git is Better Than X - - - - - - - - - - - - -
- -
- - -
-

Why Git is Better than X

- 		- - where "x" is one of -
-
- -
-
- This site is here because I seem to - be spending a lot of time lately defending Gitsters against - charges of fanboyism, bandwagonism - and koolaid-thirst. So, here is why people are switching to Git from - X, and why you should too. Just click on a reason to view it. -
- -
- Expand all | - Collapse all -
-
- -
-
- hg - bzr - svn - perforce -
- -

- Cheap Local Branching -

-
- -
- Probably Git's most compelling feature that really makes it stand - apart from nearly every other SCM out there is its branching - model. It is completely different from all of the models I'm - comparing it to here, most of which recommend that the best branch - is basically a clone of the repository in a new directory. -
- -
- Git does not work like that. Git will allow you to have multiple - local branches that can be entirely independent of each other and - the creation, merging and deletion of those lines of development - take seconds. -
- - -
- This means that you can do things like: -
    -
  • Create a branch to try out an idea, commit - a few times, switch back to where you branched from, apply a patch, - switch back to where you are experimenting, then merge it in. -
    • -
  • Have a branch that always contains only what goes to production, - another that you merge work into for testing and several smaller - ones for day to day work -
    • -
  • Create new branches for each new feature you're working on, so - you can seamlessly switch back and forth between them, then delete - each branch when that feature gets merged into your main line. -
    • -
  • Create a branch to experiment in, realize it's not going to - work and just delete it, abandoning the work—with nobody else - ever seeing it (even if you've pushed other branches in the meantime) -
    • -
-
- - branches flowchart - -
- Importantly, when you push to a remote repository, you do not - have to push all of your branches. You can only share one of your - branches and not all of them. This tends to free people to try - new ideas without worrying about having to plan how and when they - are going to merge it in or share it with others. -
- -
- You can find ways to do some of this with other systems, but the work - involved is much more difficult and error-prone. Git makes this - process incredibly easy and it changes the way most developers - work when they learn it. -
- - - - -
- jamis twitter - trevorturk twitter - thillerson twitter - boblmartens twitter - mathie twitter -
-
-
- -
-
- svn - perforce -
-

- Everything is Local -

-
- -
- This is basically true of all the distributed SCMs, but in my - experience even more so with Git. There is very little outside - of 'fetch', 'pull' and 'push' that communicates in any way with - anything other than your hard disk. -
- -
- This not only makes most operations much faster than you may - be used to, but it also allows you to work on stuff offline. - That may not sound like a big deal, but I'm always amazed at - how often I actually do work offline. Being able to branch, - merge, commit and browse history of your project while on - the plane or train is very productive. -
- -
local repo to remote repo flowchart
- -
- Even in Mercurial, common commands like 'incoming' and 'outgoing' hit - the server, whereas with Git you can 'fetch' all the servers data - before going offline and do comparisons, merges and logs of data - that is on the server but not in your local branches yet. -
- -
- This means that it's very easy to have copies of not only your - branches, but also of everyone's branches that are working with - you in your Git repository without having to mess your own stuff - up. -
- -
-
- -
-
- bzr - svn - perforce -
- -

- Git is Fast -

- -
-
- Git is fast. Everyone—even most of the hard core users of these - other systems—generally give Git this title. With Git, all - operations are performed locally giving it a bit of a leg up on - SVN and Perforce, both of which require network access for certain operations. - However, even compared to the other DSCMs that also perform operations - locally, Git is pretty fast. -
- -
- Part of this is likely because it was built to work on the Linux - kernel, which means that it has had to deal effectively with large - repositories from day one. Additionally, Git is written in C, reducing the - overhead of runtimes associated with higher-level languages. - Another reason that Git is so fast is that the primary developers - have made this a design goal of the application. -
- -
- The following are a number of benchmarks that I performed on three - copies of the Django source code repository in 3 different SCMs: - Git, Mercurial and Bazaar. I also tested some of this stuff in SVN, - but trust me, it's slower—basically take the Bazaar numbers and - then add network latency... -
- - - - -
- init benchmarks - - add benchmarks - - status benchmarks - - diff benchmarks - - branching benchmarks -
- tag benchmarks - - log benchmarks - - large commit benchmarks - - small commit benchmarks -
- -
- The end result was that for everything but adding new files, Git - was fastest. (Also really large commits, which Hg was basically the - same at, but the commit I tested was so large that you're unlikely - to ever do anything like it—normal commits are much faster in Git.) -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
GitHgBzr
Init0.024s0.059s0.600s
Add8.535s0.368s2.381s
Status0.451s1.946s14.744s
Diff0.543s2.189s14.248s
Tag0.056s1.201s1.892s
Log0.711s2.650s9.055s
Commit (Large)12.480s12.500s23.002s
Commit (Small)0.086s0.517s1.139s
Branch (Cold)1.161s94.681s82.249s
Branch (Hot)0.070s12.300s39.411s
- -
- The cold and hot branching numbers are the numbers for the first - and second times that I branched a repo—the second number being - a branch with a hot disk cache. -
- -
- It should be noted that although the 'add' numbers are much slower, - this was for a massive add operation—over 2000 files. For the - majority of what most people do on a daily basis, add ops in any - of these systems will only take a fraction of a second. All of the - other ops tested here (except for the large commit, possibly) are - more indicative of things you might actually do day to day. -
- - -
- These numbers are really not difficult to recreate, simply clone the Django - project in each of the systems and try out the same commands in each. -
    -
  • git clone git://github.com/brosner/django.git dj-git
    • -
  • hg clone http://hg.dpaste.com/django/trunk dj-hg
    • -
  • bzr branch lp:django dj-bzr
    • -
  • svn checkout http://code.djangoproject.com/svn/django/trunk dj-svn
    • -
-
- -
- - -
- -
-
- svn -
- -

- Git is Small -

- -
-
- Git is really good at conserving disk space. Your Git directory will - (in general) barely be larger than an SVN checkout—in some cases - actually smaller (apparently a lot can go in those .svn dirs). -
- -
- The following numbers were taken from clones of the Django project - in each of its semi-official Git mirrors at the same point in - its history. -
- - - - - - - - - - - - - - - - - - - - - - - -
GitHgBzrSVN
Repo Alone24M34M45M
Entire Directory43M53M64M61M
- -
-
- -
-
- hg - bzr - svn - perforce -
- -

- The Staging Area -

-
-
- Unlike the other systems, Git has what it calls the "staging area" - or "index". This is an intermediate area that you can setup what - you want your commit to look like before you commit it. -
-
- The cool thing about the staging area, and what sets Git apart - from all these other tools, is that you can easily stage some of - your files as you finish them and then commit them without committing - all the modified files in your working directory, or having to list - them on the command line during the commit -
-
add commit workflow diagram
- -
- This also allows you to stage only portions of a modified file. Gone are - the days of making two logically unrelated modifications to a file before - you realized that you forgot to commit one of them. Now you can just stage - the change you need for the current commit and stage the other change for - the next commit. This feature scales up to as many different changes to - your file as you need. -
- -
- Of course, Git also makes it pretty easy to ignore this feature - if you don't want that kind of control—just slap a '-a' to your - commit command in order to add all changes to all files to the staging area. -
- -
commit only workflow diagram
-
-
- -
-
- svn - perforce -
- -

- Distributed -

- -
- -
- One of the coolest features of any of the Distributed SCMs, Git included, is that it's - distributed. This means that instead of doing a "checkout" of the current tip of - the source code, you do a "clone" of the entire repository. -
-
- This means that even - if you're using a centralized workflow, every user has what is essentially a full - backup of the main server, each of which could be pushed up to replace the main server - in the event of a crash or corruption. There is basically no single point of failure - with Git unless there is only a single point. -
- -
- This does not slow things down much, either. On average, an SVN checkout is only marginally - faster than any of the DSCMs. Of the DSCMs I tested, Git was the fastest. -
- - - -
- cloning benchmarks - - - - - - - - - - - - - - - - - - -
Git1m 59s
Hg2m 24s
Bzr5m 11s
SVN1m 4s
-
- -
-
- - -
-
- svn - perforce -
- -

- Any Workflow -

- -
- -
- One of the amazing things about Git is that because of its distributed - nature and super branching system, you can easily implement pretty - much any workflow you can think of relatively easily. -
- -

Subversion-Style Workflow

- - -
- A very common Git workflow, especially from people transitioning - from a centralized system, is a centralized workflow. Git will - not allow you to push if someone has pushed since the last time - you fetched, so a centralized model where all developers push to - the same server works just fine. -
- -
subversion-style workflow

- -

Integration Manager Workflow

- -
- Another common Git workflow is where there is an integration - manager—a single person who commits to the 'blessed' repository, - and then a number of developers who clone from that repository, - push to their own independent repositories and ask the integrator - to pull in their changes. This is the type of development model - you often see with open source or GitHub repositories. -
- -
integration manager workflow

- -

Dictator and Lieutenants Workflow

- -
- For more massive projects, you can setup your developers similar to - the way the Linux kernel is run, where people are in charge of a - specific subsystem of the project ('lieutenants') and merge in all - changes that have to do with that subsystem. Then another integrator - (the 'dictator') can pull changes from only his/her lieutenants and - push those to the 'blessed' repository that everyone then clones from - again. -
- -
dictator and lieutenants workflow

- -
- Again, Git is entirely flexible about this, so you can mix and - match and choose the workflow that is right for you. -
- -
-
- - -
-
- hg - svn - perforce -
- -

- GitHub -

- -
- - octocat - -
- I may be biased here, given that I work for - GitHub, - but I added this section anyway because so many people say that - GitHub itself was specifically why they chose Git. -
- -
- GitHub is a reason to use Git for many people because it is more - like a social network for code than a simple hosting site. People - find other developers or projects that are similar to the things - they are doing, and can easily fork and contribute, creating a very - vibrant community around Git and the projects that people use it - for. -
- -
- There exist other services, both for Git and for the other SCMs, - but few are user-oriented or socially - targeted, and none have anywhere near the user-base. - This social aspect of GitHub is killer, and this in combination of the above features - make working with Git and GitHub a great combination for rapidly - developing open source projects. -
- -
- This type of community is simply not available with any of the other SCMs. -
- -
-
- - - - - - - -
-
- perforce -
- -

- Easy to Learn -

- -
-
- This did not used to be true—early in Git's life, it was not really - an SCM so much as a bunch of tools that let you do versioned filesystem - work in a distributed manner. However, today, the command set and - learning curve of Git are pretty similar to any other SCM, and even - better than some. -
- -
- Since this is difficult to prove objectively without some sort of - study, I'll just show the difference between the default 'help' menu for the - Mercurial and Git commands. I've highlighted the commands that are - identical (or nearly) between the two systems. (In Hg, if you type 'hg help', you - get a list of 40-some commands.) -
- - - -
- -

Mercurial Help

-
-add        add the specified files ...
-annotate   show changeset informati...
-clone      make a copy of an existi...
-commit     commit the specified fil...
-diff       diff repository (or sele...
-export     dump the header and diff...
-init       create a new repository ...
-log        show revision history of...
-merge      merge working directory ...
-parents    show the parents of the ...
-pull       pull changes from the sp...
-push       push changes to the spec...
-remove     remove the specified fil...
-serve      export the repository vi...
-status     show changed files in th...
-update     update working directory
-
- - 		- -

Git Help

-
-add        Add file contents to the index
-bisect     Find the change that introduce...
-branch     List, create, or delete branches
-checkout   Checkout a branch or paths to ...
-clone      Clone a repository into a new ...
-commit     Record changes to the repository
-diff       Show changes between commits, ...
-fetch      Download objects and refs from...
-grep       Print lines matching a pattern
-init       Create an empty git repository
-log        Show commit logs
-merge      Join two or more development h...
-mv         Move or rename a file, a direc...
-pull       Fetch from and merge with anot...
-push       Update remote refs along with ...
-rebase     Forward-port local commits to ...
-reset      Reset current HEAD to the spec...
-rm         Remove files from the working ...
-show       Show various types of objects
-status     Show the working tree status
-tag        Create, list, delete or verify...
-
-
- -
- Prior to Git 1.6, all of the Git commands used to be in the executable - path, which was very confusing to people. Although Git still recognizes - all of those commands, the only command in the path is now 'git'. - So, if you look at Mercurial and Git, Git has a nearly identical - command set and help system—there is very little difference from - a beginning UI perspective today. -
- -
- These days it's pretty hard to argue that Mercurial or Bazaar is any - easier to learn than Git is. -
- -
- -
- - - - -
-
- Expand all | - Collapse all -
-
- -
- This site is built and maintained by Scott Chacon, a - GitHubber.
- - If you disagree with anything on the site and you have a good reason, please - email me so I can fix it.
- - The source for this site is on GitHub—feel - free to send patches if you want to improve it.
-
- -
- Also in : - German, - Spanish, - French, - Italian, - Lolcat, - Dutch, - Norwegian, - Portuguese, - Swedish, - Simplified and - Traditional Chinese -
- -
- Valid XHTML -
-
- - - - - - - - + Why Git is Better Than X

Why Git is Better than X

 where "x" is one of
This site is here because I seem to be spending a lot of time lately defending Gitsters against charges of fanboyism, bandwagonism and koolaid-thirst. So, here is why people are switching to Git from X, and why you should too. Just click on a reason to view it.
최근 나는 슈퍼 울트라 극성주의자들로부터 Gitster들을 옹호하는데 지쳐서 이 사이트를 만들었다. 나는 사람들이 왜 Git으로 갈아타는지를 정리했다. 클릭해보라.
모두 펴기 | 모두 숨기기
hg bzr svn perforce

Cheap Local Branching/값 싼 브랜칭

Probably Git's most compelling feature that really makes it stand apart from nearly every other SCM out there is its branching model. It is completely different from all of the models I'm comparing it to here, most of which recommend that the best branch is basically a clone of the repository in a new directory.
다른 SCM에 비해 Git의 가장 큰 특징은 아마도 브랜치 모델일 것이다. Git은 내가 여기서 비교하고자 하는 다른 모델들과는 완전히 다르다. 대부분이 권장하는 궁극의 브랜치는 새 디렉토리로 레파지토리를 통째로 복사하는 것이다.
Git does not work like that. Git will allow you to have multiple local branches that can be entirely independent of each other and the creation, merging and deletion of those lines of development take seconds.
하지만 Git은 그렇게 동작하지 않는다. Git에서는 여러 개의 로컬 브랜치를 가질수 있으며 그 로컬 브랜치들은 서로 완벽하게 독립적이기 때문에 개발 중 수행하는 생성, 머지, 삭제 명령도 독립적으로 수행된다.
This means that you can do things like:
Git으로는 다음과 같은 일들을 할 수 있다:
  • Create a branch to try out an idea, commit a few times, switch back to where you branched from, apply a patch, switch back to where you are experimenting, then merge it in.
    아이디어를 실험하기 위해 브랜치를 만들고, 몇 번 커밋을 하고, 원래 것으로 돌아가, 패치를 적용한다. 다시 실험중인 브랜치로 돌아가 그것을 머지한다.
  • Have a branch that always contains only what goes to production, another that you merge work into for testing and several smaller ones for day to day work
    제품으로 출시하기 위한 브랜치는 하나만 가질 수 있고 그외 다른 목적의 브랜치를 만들 수 있다. 테스트나 일상적인 업무를 위한 브랜치를 만들어 작업하고 그 것을 머지한다.
  • Create new branches for each new feature you're working on, so you can seamlessly switch back and forth between them, then delete each branch when that feature gets merged into your main line.
    당신이 만들고 있는 이슈마다 브랜치를 새로 만들고 그 브랜치들 사이들 오가며 작업할 수 있다. 그리고 그 브랜치를 마스터 브랜치로 머지한 후에 그 브랜치들을 삭제한다.
  • Create a branch to experiment in, realize it's not going to work and just delete it, abandoning the work—with nobody else ever seeing it (even if you've pushed other branches in the meantime)
    실험용 브랜치를 만들고 쓸모가 없으면 바로 삭제한다. (그 동안 다른 브랜치들을 푸시했었더라도) 실험은 버려졌기 때문에 아무도 모른다.
branches flowchart
Importantly, when you push to a remote repository, you do not have to push all of your branches. You can only share one of your branches and not all of them. This tends to free people to try new ideas without worrying about having to plan how and when they are going to merge it in or share it with others.
중요한 것은 원격의 레파지토리에 푸시할 때 가지고 있는 브랜치 전부를 푸시하지 않는 점이다. 가지고 있는 브랜치들 중 하나만 공유할 수 있다. 그래서 사람들은 언제, 어떻게 브랜치를 머지하고 공유해야 할지에 대한 고민없이 쉽게 새로운 아이디어를 실험할 수 있다.
You can find ways to do some of this with other systems, but the work involved is much more difficult and error-prone. Git makes this process incredibly easy and it changes the way most developers work when they learn it.
다른 시스템과 함께 Git을 사용할 방법이 있지만 매우 어렵고 에러나기 쉽다. Git을 배우면 이 과정이 매우 쉬워지고 일하는 방식도 변화한다.
jamis twitter trevorturk twitter thillerson twitter boblmartens twitter mathie twitter
svn perforce

Everything is Local/역사는 로컬에서

This is basically true of all the distributed SCMs, but in my experience even more so with Git. There is very little outside of 'fetch', 'pull' and 'push' that communicates in any way with anything other than your hard disk.
이 것은 모든 분산 SCM에도 해당하는 이야기지만 나는 주로 Git을 많이 사용한다. Git은 외부 요소가 매우 적다. 내 하드디스크 세상 밖으로 소통하는 방법은 'fetch', 'pull', 'push'밖에 없다.
This not only makes most operations much faster than you may be used to, but it also allows you to work on stuff offline. That may not sound like a big deal, but I'm always amazed at how often I actually do work offline. Being able to branch, merge, commit and browse history of your project while on the plane or train is very productive.
이 것은 우리가 해왔던 것 보다 모든 명령의 수행 속도를 빠르게 해줄뿐만 아니라 오프라인에서도 작업할 수 있도록 해준다. 실제로 아무것도 아닐 것 같지만 나는 내가 자주 오프라인으로 작업하고 있는 것을 발견하곤 항상 매우 놀란다. 비행기나 기차안에서도 오프라인으로 브랜치, 머지, 커밋하고 프로젝트의 히스토리를 살펴볼 수 있다는 것은 매우 생산적이다.
local repo to remote repo flowchart
Even in Mercurial, common commands like 'incoming' and 'outgoing' hit the server, whereas with Git you can 'fetch' all the servers data before going offline and do comparisons, merges and logs of data that is on the server but not in your local branches yet.
Mercurial은 incoming과 outouing같은 명령어로 서버와 통신하는 반면 로컬 브랜치에는 없고 서버에만 있는 데이터를 fetch한다. fetch를 한 후에는 오프라인으로도 서버에 있는 데이터와 비교, 머지, 로그 등의 일을 할 수 있다.
This means that it's very easy to have copies of not only your branches, but also of everyone's branches that are working with you in your Git repository without having to mess your own stuff up.
즉, Git 레파지토리에 있는 작업물들을 헝클지도 않으면서 나과 나와 함께 일하는 동료들은 모두 자신만의 브랜치를 매우 쉽게 만들 수 있다.
bzr svn perforce

Git is Fast/Git은 빠르다

Git is fast. Everyone—even most of the hard core users of these other systems—generally give Git this title. With Git, all operations are performed locally giving it a bit of a leg up on SVN and Perforce, both of which require network access for certain operations. However, even compared to the other DSCMs that also perform operations locally, Git is pretty fast.
모두가 Git의 장점으로 'Git은 빠르다'라고 내세운다. 다른 SCM의 하드코어 사용자들 조차도 이점을 강조한다. Git의 모든 오퍼레이션은 로컬에서 수행된다. 네트워크가 필요한 SVN과 Perforce에 날개를 단 셈이다. 게다가 Git은 로컬에서 명령을 수행하는 다른 DSCM과 비교해도 빠르다.
Part of this is likely because it was built to work on the Linux kernel, which means that it has had to deal effectively with large repositories from day one. Additionally, Git is written in C, reducing the overhead of runtimes associated with higher-level languages. Another reason that Git is so fast is that the primary developers have made this a design goal of the application.
처음 개발할때 부터 리눅스 커널에 사용할 목적이 였기 때문에 규모가 큰 레파지토리일 수록 더욱 효과적이다. 게다가 Git은 C로 작성되어 고수준 언어가 만들어내는 오버헤드도 없다. Git을 만든 선구자들은 '빠른 것'을 설계 목표중 하나로 삼았다.
The following are a number of benchmarks that I performed on three copies of the Django source code repository in 3 different SCMs: Git, Mercurial and Bazaar. I also tested some of this stuff in SVN, but trust me, it's slower—basically take the Bazaar numbers and then add network latency...
나는 몇 가지 벤치마크 테스트를 진행했다. Git, Mercurial, Bazaar 이렇게 세가지 SCM에 각각 Django source code를 올려놓고 테스트를 했다. 나는 또한 SVN으로도 이 중 몇가지 테스트를 진행했다. 내가 장담컨데 SVN은 느리다. 기본적으로 Bazaar의 결과에 네트워크 레이턴시(Latency)를 더해야 한다.
init benchmarks add benchmarks status benchmarks diff benchmarks branching benchmarks
tag benchmarks log benchmarks large commit benchmarks small commit benchmarks
The end result was that for everything but adding new files, Git was fastest. (Also really large commits, which Hg was basically the same at, but the commit I tested was so large that you're unlikely to ever do anything like it—normal commits are much faster in Git.)
결론부터 말하자면 파일을 새로 추가하는 경우를 제외하면 Git은 항상 빠르다.(물론 정말정말 큰 데이터를 커밋하는 경우는 Hg가 제일 빠르다. 그러나 내가 테스트한 크기조차도 보통은 경험할 수 없다. 그러니까 대부분의 경우는 Git이 더 빠르다.)
Git Hg Bzr
Init 0.024s 0.059s 0.600s
Add 8.535s 0.368s 2.381s
Status 0.451s 1.946s 14.744s
Diff 0.543s 2.189s 14.248s
Tag 0.056s 1.201s 1.892s
Log 0.711s 2.650s 9.055s
Commit (Large) 12.480s 12.500s 23.002s
Commit (Small) 0.086s 0.517s 1.139s
Branch (Cold) 1.161s 94.681s 82.249s
Branch (Hot) 0.070s 12.300s 39.411s
The cold and hot branching numbers are the numbers for the first and second times that I branched a repo—the second number being a branch with a hot disk cache.
이건 먼소린지..ㅋㅋㅋ
It should be noted that although the 'add' numbers are much slower, this was for a massive add operation—over 2000 files. For the majority of what most people do on a daily basis, add ops in any of these systems will only take a fraction of a second. All of the other ops tested here (except for the large commit, possibly) are more indicative of things you might actually do day to day.
테스트 결과를 보면 'add'의 경우는 매우 느리지만 이 것은 파일 2000개가 넘는 경우에나 해당된다. 대부분의 사람들은 하루를 기준으로 일을 한다. 이런 경우의 'add'는 순식간에 이루어진다. 여기서 진행한 다른(라지 커밋은 제외한) 테스트 결과들은 우리가 날마다 실제로 하는 패턴들이다.
These numbers are really not difficult to recreate, simply clone the Django project in each of the systems and try out the same commands in each.
이 테스트를 재현하는 것은 어렵지 않다. 단순히 각 시스템마다 다음과 같은 명령어를 수행하여 Django 프로젝트의 클론을 만들면 된다.
  • git clone git://github.com/brosner/django.git dj-git
  • hg clone http://hg.dpaste.com/django/trunk dj-hg
  • bzr branch lp:django dj-bzr
  • svn checkout http://code.djangoproject.com/svn/django/trunk dj-svn
svn

Git is Small/Git은 작다.

Git is really good at conserving disk space. Your Git directory will (in general) barely be larger than an SVN checkout—in some cases actually smaller (apparently a lot can go in those .svn dirs).
Git은 디스크 공간을 적게 차지한다. Git 디렉토리는 일반적으로 SVN checkout한 것보다 별반 차이 없다. 어떤 경우에는 SVN의 것보다 작다(.svn 디렉토리에는 뭔가 무진장 많다는 것만은 분명이다.).
The following numbers were taken from clones of the Django project in each of its semi-official Git mirrors at the same point in its history.
다음은 Django project의 클론에 대한 것이다. 동일한 리비전(at the same point in its history)을 기준으로 비공식(semi-official) Git 미러를 통해 만들었다.
Git Hg Bzr SVN
Repo Alone 24M 34M 45M
Entire Directory 43M 53M 64M 61M
hg bzr svn perforce

The Staging Area

Unlike the other systems, Git has what it calls the "staging area" or "index". This is an intermediate area that you can setup what you want your commit to look like before you commit it.
다른 시스템과 달리 Git은 "staging area" 혹은 "index"라고 부르는 것이 있다. 커밋할 것 같은 파일을 넣고 관리하는 일종의 중간 영역이다.
The cool thing about the staging area, and what sets Git apart from all these other tools, is that you can easily stage some of your files as you finish them and then commit them without committing all the modified files in your working directory, or having to list them on the command line during the commit
staging area가 멋있는 점은 일을 끝내자 마자 쉽게 파일을 스테이지할 수 있고 커밋할 때 워킹 디렉토리에서 수정된 모든 파일을 커밋되지 않는다는 점이다. 또한 커밋할 때까지 명령어로 staging area를 관리할 수 있다.
add commit workflow diagram
This also allows you to stage only portions of a modified file. Gone are the days of making two logically unrelated modifications to a file before you realized that you forgot to commit one of them. Now you can just stage the change you need for the current commit and stage the other change for the next commit. This feature scales up to as many different changes to your file as you need.
우리는 수정한 파일의 일부만 스테이지할 수도 있다. 무언가 빼먹고 커밋하기 전에 논리적으로 무관한 파일을 걸러낼 필요가 없어졌다. 지금은 그냥 지금 커밋하는데 필요한 파일을 스테이지하고 다음 커밋에 필요한 다른 파일들은 다음에 스테이지한다. 이 기능은 그때 그때 상황에 맞추어 필요한 만큼 사용한다.
Of course, Git also makes it pretty easy to ignore this feature if you don't want that kind of control—just slap a '-a' to your commit command in order to add all changes to all files to the staging area.
물론 Git은 이 기능을 생략할 수 있는 방법도 제공한다. 커밋 명렁어에 '-a' 옵션을 추가하는 것만으로 쉽게 수정된 모든 파일이 스테이징 영역에 자동으로 추가된다.
commit only workflow diagram
svn perforce

Distributed/분산

One of the coolest features of any of the Distributed SCMs, Git included, is that it's distributed. This means that instead of doing a "checkout" of the current tip of the source code, you do a "clone" of the entire repository.
Git을 포함한 모든 분산 SCM의 가장 큰 특징은 역시 분산된다는 점이다. 이 것은 최신 소스코드를 체크아웃하지 않고 레파지토리 전체를 복사하는 것(Clone)을 말한다.
This means that even if you're using a centralized workflow, every user has what is essentially a full backup of the main server, each of which could be pushed up to replace the main server in the event of a crash or corruption. There is basically no single point of failure with Git unless there is only a single point.
이 것은 잘 정리된 워크플로우 없이도 모든 사용자가 메인서버의 풀백업을 가지게 된다는 것을 말한다. 그래서 메인서버에 문제가 생겼을때 누구나 메인서버에 푸시할 수 있다.
This does not slow things down much, either. On average, an SVN checkout is only marginally faster than any of the DSCMs. Of the DSCMs I tested, Git was the fastest.
성능도 빠르다. 보통 SVN은 체크아웃에서만 다른 DSCM들보다 조금 빠르다. (적어도 내가 테스트해본) DSCM들 중에서는 Git이 가장 빠르다.
cloning benchmarks
Git 1m 59s
Hg 2m 24s
Bzr 5m 11s
SVN 1m 4s
svn perforce

Any Workflow/워크플로우는 Git하기 나름

One of the amazing things about Git is that because of its distributed nature and super branching system, you can easily implement pretty much any workflow you can think of relatively easily.
Git이 대단한 점은 또 있다. Git은 슈퍼 브랜치 시스템이고 분산 생태계라는 점 때문에 우리가 생각할 수 있는 모든 워크플로우를 쉽게 구현할 수 있다.

Subversion-Style Workflow/Subversion 스타일

A very common Git workflow, especially from people transitioning from a centralized system, is a centralized workflow. Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.
매우 일반적으로 사용되는 Git 워크플로우로 중앙집중식(centralized workflow)이 있다. 특히 Subversion같은 중앙집중식(centralized) 시스템를 사용하다가 넘어온 사람들이 사용한다. 내가 마지막으로 fecth한 후에 아무도 푸시하지 못하도록 할 수 있다. 그래서 모든 개발자가 같은 서버에 푸시하는 centralized 모델도 가능하다.
subversion-style workflow

Integration Manager Workflow/오픈소스 스타일

Another common Git workflow is where there is an integration manager—a single person who commits to the 'blessed' repository, and then a number of developers who clone from that repository, push to their own independent repositories and ask the integrator to pull in their changes. This is the type of development model you often see with open source or GitHub repositories.
또 자주 사용되는 워크플로우로 Integration Manager가 있는 유형이 있다. Integration Manager 한 사람만이 신성한 레파지토리(역자주- 메인 레파지토리)에 커밋할 수 있고 다른 개발자들은 그 레파지토리를 복제한다. 개발자들은 각자의 레파지토리에 커밋하고 관리자에게 자신의 코드를 풀(pull)하도록 요청한다. 이 것은 오픈소스나 GitHub 레파지토리에서 자주 사용되는 개발 모델이다.
integration manager workflow

Dictator and Lieutenants Workflow/Linux 형

For more massive projects, you can setup your developers similar to the way the Linux kernel is run, where people are in charge of a specific subsystem of the project ('lieutenants') and merge in all changes that have to do with that subsystem. Then another integrator (the 'dictator') can pull changes from only his/her lieutenants and push those to the 'blessed' repository that everyone then clones from again.
Linux kernel 개발에서 사용하는 모델을 사용할 수 있다. 프로젝트의 특정한 서브시스템('lieutenants')을 담당하는 사람들은 그 서브시스템에서 일어나는 모든 변화를 관리한다. 'dictator'라고 부르는 또 다른 형태의 관리자는 자신의 'lieutenants'에서 발생한 수정내역을 가져다가 신성한 레파지토리에 다시 푸시한다. 그리고 모든 사람들은 이 신성한 레파지토리에서 다시 복제(Clone)한다. 이 것은 리눅스 커널같은 규모가 큰 프로젝트에서 사용된다.
dictator and lieutenants workflow

Again, Git is entirely flexible about this, so you can mix and match and choose the workflow that is right for you.
다시말해서 Git은 매우 유연하다. 이 워크플로우들 중에서 딱 맞는 것을 골라 쓸 수도 있고 섞어서 자신에게 적합한 워크플로우를 만들어 쓸 수도 있다.
hg svn perforce

GitHub

octocat
I may be biased here, given that I work for GitHub, but I added this section anyway because so many people say that GitHub itself was specifically why they chose Git.
GitHub라는 단락을 추가한 것이 내가 GitHub에서 일하기 때문에 생긴 편견일 수도 있다. 그러나 너무 많은 사람들이 Git을 선택한 이유로 GitHub를 강조하고 있기 때문에 추가했다.
GitHub is a reason to use Git for many people because it is more like a social network for code than a simple hosting site. People find other developers or projects that are similar to the things they are doing, and can easily fork and contribute, creating a very vibrant community around Git and the projects that people use it for.
GitHub는 많은 사람들이 Git을 사용하는 이유중 하나다. GitHub는 단순히 호스팅 사이트를 제공하는 것이 아니라 코드를 위한 소셜 네트워크를 제공한다. 사람들은 자신이 하고 있는 일과 유사한 개발자나 프로젝트를 찾는다. 그리고 Git이나 Git을 사용하는 프로젝트와 관련된 매우 활발한 커뮤니티를 만들어서 쉽게 프로젝트를 복제(fork)하거나 참여할(contribute) 수 있다.
There exist other services, both for Git and for the other SCMs, but few are user-oriented or socially targeted, and none have anywhere near the user-base. This social aspect of GitHub is killer, and this in combination of the above features make working with Git and GitHub a great combination for rapidly developing open source projects.
Git과 다른 SCM을 모두 다루는 서비스들도 있지만 이렇게 사용자 중심이면서 소셜을 타깃으로 하는 서비스는 드문데다가 전적으로 사용자에 기반하는 시스템은 없다. GitHub가 소셜이라는 것은 정말 끈내준다. Git과 GitHub을 함께 사용하면 지금까지 설명한 것들이 잘 어우러져서 정말 오픈소스 프로젝트를 빠르게 개발할 수 있다.
This type of community is simply not available with any of the other SCMs.
다른 SCM에는 이런 형태의 커뮤니티가 없다.
perforce

Easy to Learn/배우기 쉽다

This did not used to be true—early in Git's life, it was not really an SCM so much as a bunch of tools that let you do versioned filesystem work in a distributed manner. However, today, the command set and learning curve of Git are pretty similar to any other SCM, and even better than some.
초창기 Git은 배우기 쉽지 않았다. 그때는 정말이지 분산 SCM을 할 수 있는 툴이 별로 없었다. 그러나 오늘날 Git의 learning curve는 다른 SCM들과 비슷할 뿐만 아니라 심지어 더 쉬운 경우도 있다.
Since this is difficult to prove objectively without some sort of study, I'll just show the difference between the default 'help' menu for the Mercurial and Git commands. I've highlighted the commands that are identical (or nearly) between the two systems. (In Hg, if you type 'hg help', you get a list of 40-some commands.)
ㅇㅇ 객관적으로 증명하는 것이 어렵기 때문에 나는 Mercurial과 Git의 기본적인 'help' 메뉴의 차이를 비교 설명하려한다. 두 시스템이 가지고 있는 정말(혹은 거의) 똑같은 명령어는 다른색으로 표기했다. (Hg의 경우 만약 'hg help'라고 명령어를 실행하면 40여 개의 명령어를 볼 수 있다.)

Mercurial Help

add        add the specified files ...
annotate   show changeset informati...
clone      make a copy of an existi...
commit     commit the specified fil...
diff       diff repository (or sele...
export     dump the header and diff...
init       create a new repository ...
log        show revision history of...
merge      merge working directory ...
parents    show the parents of the ...
pull       pull changes from the sp...
push       push changes to the spec...
remove     remove the specified fil...
serve      export the repository vi...
status     show changed files in th...
update     update working directory

Git Help

add        Add file contents to the index
bisect     Find the change that introduce...
branch     List, create, or delete branches
checkout   Checkout a branch or paths to ...
clone      Clone a repository into a new ...
commit     Record changes to the repository
diff       Show changes between commits, ...
fetch      Download objects and refs from...
grep       Print lines matching a pattern
init       Create an empty git repository
log        Show commit logs
merge      Join two or more development h...
mv         Move or rename a file, a direc...
pull       Fetch from and merge with anot...
push       Update remote refs along with ...
rebase     Forward-port local commits to ...
reset      Reset current HEAD to the spec...
rm         Remove files from the working ...
show       Show various types of objects
status     Show the working tree status
tag        Create, list, delete or verify...
Prior to Git 1.6, all of the Git commands used to be in the executable path, which was very confusing to people. Although Git still recognizes all of those commands, the only command in the path is now 'git'. So, if you look at Mercurial and Git, Git has a nearly identical command set and help system—there is very little difference from a beginning UI perspective today.
Git 1.6 이전에, 모든 Git 명령어들은 각각의 실행 프로그램으로 돼있어서 실행 경로에 등록되면(역자주 - 환경변수 'PATH') 사람들이 매우 헷갈려 했었다. Git은 그 명령어들을 아직도 가지고 있지만 이제는 'git'만 실행할 수 있으면 된다. 그래서 만약 Mercurial과 Git을 보면 명령어들과 도움말이 서로 거의 동일하다. 요즘은 UI 관점에서 시작된 매우 작은 차이가 있을 뿐이다.
These days it's pretty hard to argue that Mercurial or Bazaar is any easier to learn than Git is.
그래서요즘은 Mercurial이나 Bazaar가 Git보다 배우기 쉽다고 주장하기 어렵다.
Expand all | Collapse all
This site is built and maintained by Scott Chacon, a GitHubber.
If you disagree with anything on the site and you have a good reason, please email me so I can fix it.
The source for this site is on GitHub—feel free to send patches if you want to improve it.
이 사이트는 GitHubber인 Scott Chacon가 만들고 관리하고 있습니다.
만약 이 사이트가 마음에 들지 않을때 타당한 이유를 저에게 보내주시면 수정하겠습니다. 이 사이트의 소스는 GitHub에있습니다. 이 사이트에 개선할 것이 있으면 주저하지 말고 패치를 보내주세요.
Also in : German, Spanish, French, Italian, Lolcat, Dutch, Norwegian, Portuguese, Swedish, Simplified and Traditional Chinese
Valid XHTML
\ No newline at end of file From 13f4f59bafb0b009331e879a62208d19cecf94e1 Mon Sep 17 00:00:00 2001 From: Changwoo Park Date: Tue, 28 Jun 2011 22:32:13 +0800 Subject: [PATCH 2/5] improved sentence. but a section remained. --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index b41331f..ecb89b5 100644 --- a/index.html +++ b/index.html @@ -1 +1 @@ - Why Git is Better Than X

Why Git is Better than X

 where "x" is one of
This site is here because I seem to be spending a lot of time lately defending Gitsters against charges of fanboyism, bandwagonism and koolaid-thirst. So, here is why people are switching to Git from X, and why you should too. Just click on a reason to view it.
최근 나는 슈퍼 울트라 극성주의자들로부터 Gitster들을 옹호하는데 지쳐서 이 사이트를 만들었다. 나는 사람들이 왜 Git으로 갈아타는지를 정리했다. 클릭해보라.
모두 펴기 | 모두 숨기기
hg bzr svn perforce

Cheap Local Branching/값 싼 브랜칭

Probably Git's most compelling feature that really makes it stand apart from nearly every other SCM out there is its branching model. It is completely different from all of the models I'm comparing it to here, most of which recommend that the best branch is basically a clone of the repository in a new directory.
다른 SCM에 비해 Git의 가장 큰 특징은 아마도 브랜치 모델일 것이다. Git은 내가 여기서 비교하고자 하는 다른 모델들과는 완전히 다르다. 대부분이 권장하는 궁극의 브랜치는 새 디렉토리로 레파지토리를 통째로 복사하는 것이다.
Git does not work like that. Git will allow you to have multiple local branches that can be entirely independent of each other and the creation, merging and deletion of those lines of development take seconds.
하지만 Git은 그렇게 동작하지 않는다. Git에서는 여러 개의 로컬 브랜치를 가질수 있으며 그 로컬 브랜치들은 서로 완벽하게 독립적이기 때문에 개발 중 수행하는 생성, 머지, 삭제 명령도 독립적으로 수행된다.
This means that you can do things like:
Git으로는 다음과 같은 일들을 할 수 있다:
  • Create a branch to try out an idea, commit a few times, switch back to where you branched from, apply a patch, switch back to where you are experimenting, then merge it in.
    아이디어를 실험하기 위해 브랜치를 만들고, 몇 번 커밋을 하고, 원래 것으로 돌아가, 패치를 적용한다. 다시 실험중인 브랜치로 돌아가 그것을 머지한다.
  • Have a branch that always contains only what goes to production, another that you merge work into for testing and several smaller ones for day to day work
    제품으로 출시하기 위한 브랜치는 하나만 가질 수 있고 그외 다른 목적의 브랜치를 만들 수 있다. 테스트나 일상적인 업무를 위한 브랜치를 만들어 작업하고 그 것을 머지한다.
  • Create new branches for each new feature you're working on, so you can seamlessly switch back and forth between them, then delete each branch when that feature gets merged into your main line.
    당신이 만들고 있는 이슈마다 브랜치를 새로 만들고 그 브랜치들 사이들 오가며 작업할 수 있다. 그리고 그 브랜치를 마스터 브랜치로 머지한 후에 그 브랜치들을 삭제한다.
  • Create a branch to experiment in, realize it's not going to work and just delete it, abandoning the work—with nobody else ever seeing it (even if you've pushed other branches in the meantime)
    실험용 브랜치를 만들고 쓸모가 없으면 바로 삭제한다. (그 동안 다른 브랜치들을 푸시했었더라도) 실험은 버려졌기 때문에 아무도 모른다.
branches flowchart
Importantly, when you push to a remote repository, you do not have to push all of your branches. You can only share one of your branches and not all of them. This tends to free people to try new ideas without worrying about having to plan how and when they are going to merge it in or share it with others.
중요한 것은 원격의 레파지토리에 푸시할 때 가지고 있는 브랜치 전부를 푸시하지 않는 점이다. 가지고 있는 브랜치들 중 하나만 공유할 수 있다. 그래서 사람들은 언제, 어떻게 브랜치를 머지하고 공유해야 할지에 대한 고민없이 쉽게 새로운 아이디어를 실험할 수 있다.
You can find ways to do some of this with other systems, but the work involved is much more difficult and error-prone. Git makes this process incredibly easy and it changes the way most developers work when they learn it.
다른 시스템과 함께 Git을 사용할 방법이 있지만 매우 어렵고 에러나기 쉽다. Git을 배우면 이 과정이 매우 쉬워지고 일하는 방식도 변화한다.
jamis twitter trevorturk twitter thillerson twitter boblmartens twitter mathie twitter
svn perforce

Everything is Local/역사는 로컬에서

This is basically true of all the distributed SCMs, but in my experience even more so with Git. There is very little outside of 'fetch', 'pull' and 'push' that communicates in any way with anything other than your hard disk.
이 것은 모든 분산 SCM에도 해당하는 이야기지만 나는 주로 Git을 많이 사용한다. Git은 외부 요소가 매우 적다. 내 하드디스크 세상 밖으로 소통하는 방법은 'fetch', 'pull', 'push'밖에 없다.
This not only makes most operations much faster than you may be used to, but it also allows you to work on stuff offline. That may not sound like a big deal, but I'm always amazed at how often I actually do work offline. Being able to branch, merge, commit and browse history of your project while on the plane or train is very productive.
이 것은 우리가 해왔던 것 보다 모든 명령의 수행 속도를 빠르게 해줄뿐만 아니라 오프라인에서도 작업할 수 있도록 해준다. 실제로 아무것도 아닐 것 같지만 나는 내가 자주 오프라인으로 작업하고 있는 것을 발견하곤 항상 매우 놀란다. 비행기나 기차안에서도 오프라인으로 브랜치, 머지, 커밋하고 프로젝트의 히스토리를 살펴볼 수 있다는 것은 매우 생산적이다.
local repo to remote repo flowchart
Even in Mercurial, common commands like 'incoming' and 'outgoing' hit the server, whereas with Git you can 'fetch' all the servers data before going offline and do comparisons, merges and logs of data that is on the server but not in your local branches yet.
Mercurial은 incoming과 outouing같은 명령어로 서버와 통신하는 반면 로컬 브랜치에는 없고 서버에만 있는 데이터를 fetch한다. fetch를 한 후에는 오프라인으로도 서버에 있는 데이터와 비교, 머지, 로그 등의 일을 할 수 있다.
This means that it's very easy to have copies of not only your branches, but also of everyone's branches that are working with you in your Git repository without having to mess your own stuff up.
즉, Git 레파지토리에 있는 작업물들을 헝클지도 않으면서 나과 나와 함께 일하는 동료들은 모두 자신만의 브랜치를 매우 쉽게 만들 수 있다.
bzr svn perforce

Git is Fast/Git은 빠르다

Git is fast. Everyone—even most of the hard core users of these other systems—generally give Git this title. With Git, all operations are performed locally giving it a bit of a leg up on SVN and Perforce, both of which require network access for certain operations. However, even compared to the other DSCMs that also perform operations locally, Git is pretty fast.
모두가 Git의 장점으로 'Git은 빠르다'라고 내세운다. 다른 SCM의 하드코어 사용자들 조차도 이점을 강조한다. Git의 모든 오퍼레이션은 로컬에서 수행된다. 네트워크가 필요한 SVN과 Perforce에 날개를 단 셈이다. 게다가 Git은 로컬에서 명령을 수행하는 다른 DSCM과 비교해도 빠르다.
Part of this is likely because it was built to work on the Linux kernel, which means that it has had to deal effectively with large repositories from day one. Additionally, Git is written in C, reducing the overhead of runtimes associated with higher-level languages. Another reason that Git is so fast is that the primary developers have made this a design goal of the application.
처음 개발할때 부터 리눅스 커널에 사용할 목적이 였기 때문에 규모가 큰 레파지토리일 수록 더욱 효과적이다. 게다가 Git은 C로 작성되어 고수준 언어가 만들어내는 오버헤드도 없다. Git을 만든 선구자들은 '빠른 것'을 설계 목표중 하나로 삼았다.
The following are a number of benchmarks that I performed on three copies of the Django source code repository in 3 different SCMs: Git, Mercurial and Bazaar. I also tested some of this stuff in SVN, but trust me, it's slower—basically take the Bazaar numbers and then add network latency...
나는 몇 가지 벤치마크 테스트를 진행했다. Git, Mercurial, Bazaar 이렇게 세가지 SCM에 각각 Django source code를 올려놓고 테스트를 했다. 나는 또한 SVN으로도 이 중 몇가지 테스트를 진행했다. 내가 장담컨데 SVN은 느리다. 기본적으로 Bazaar의 결과에 네트워크 레이턴시(Latency)를 더해야 한다.
init benchmarks add benchmarks status benchmarks diff benchmarks branching benchmarks
tag benchmarks log benchmarks large commit benchmarks small commit benchmarks
The end result was that for everything but adding new files, Git was fastest. (Also really large commits, which Hg was basically the same at, but the commit I tested was so large that you're unlikely to ever do anything like it—normal commits are much faster in Git.)
결론부터 말하자면 파일을 새로 추가하는 경우를 제외하면 Git은 항상 빠르다.(물론 정말정말 큰 데이터를 커밋하는 경우는 Hg가 제일 빠르다. 그러나 내가 테스트한 크기조차도 보통은 경험할 수 없다. 그러니까 대부분의 경우는 Git이 더 빠르다.)
Git Hg Bzr
Init 0.024s 0.059s 0.600s
Add 8.535s 0.368s 2.381s
Status 0.451s 1.946s 14.744s
Diff 0.543s 2.189s 14.248s
Tag 0.056s 1.201s 1.892s
Log 0.711s 2.650s 9.055s
Commit (Large) 12.480s 12.500s 23.002s
Commit (Small) 0.086s 0.517s 1.139s
Branch (Cold) 1.161s 94.681s 82.249s
Branch (Hot) 0.070s 12.300s 39.411s
The cold and hot branching numbers are the numbers for the first and second times that I branched a repo—the second number being a branch with a hot disk cache.
이건 먼소린지..ㅋㅋㅋ
It should be noted that although the 'add' numbers are much slower, this was for a massive add operation—over 2000 files. For the majority of what most people do on a daily basis, add ops in any of these systems will only take a fraction of a second. All of the other ops tested here (except for the large commit, possibly) are more indicative of things you might actually do day to day.
테스트 결과를 보면 'add'의 경우는 매우 느리지만 이 것은 파일 2000개가 넘는 경우에나 해당된다. 대부분의 사람들은 하루를 기준으로 일을 한다. 이런 경우의 'add'는 순식간에 이루어진다. 여기서 진행한 다른(라지 커밋은 제외한) 테스트 결과들은 우리가 날마다 실제로 하는 패턴들이다.
These numbers are really not difficult to recreate, simply clone the Django project in each of the systems and try out the same commands in each.
이 테스트를 재현하는 것은 어렵지 않다. 단순히 각 시스템마다 다음과 같은 명령어를 수행하여 Django 프로젝트의 클론을 만들면 된다.
  • git clone git://github.com/brosner/django.git dj-git
  • hg clone http://hg.dpaste.com/django/trunk dj-hg
  • bzr branch lp:django dj-bzr
  • svn checkout http://code.djangoproject.com/svn/django/trunk dj-svn
svn

Git is Small/Git은 작다.

Git is really good at conserving disk space. Your Git directory will (in general) barely be larger than an SVN checkout—in some cases actually smaller (apparently a lot can go in those .svn dirs).
Git은 디스크 공간을 적게 차지한다. Git 디렉토리는 일반적으로 SVN checkout한 것보다 별반 차이 없다. 어떤 경우에는 SVN의 것보다 작다(.svn 디렉토리에는 뭔가 무진장 많다는 것만은 분명이다.).
The following numbers were taken from clones of the Django project in each of its semi-official Git mirrors at the same point in its history.
다음은 Django project의 클론에 대한 것이다. 동일한 리비전(at the same point in its history)을 기준으로 비공식(semi-official) Git 미러를 통해 만들었다.
Git Hg Bzr SVN
Repo Alone 24M 34M 45M
Entire Directory 43M 53M 64M 61M
hg bzr svn perforce

The Staging Area

Unlike the other systems, Git has what it calls the "staging area" or "index". This is an intermediate area that you can setup what you want your commit to look like before you commit it.
다른 시스템과 달리 Git은 "staging area" 혹은 "index"라고 부르는 것이 있다. 커밋할 것 같은 파일을 넣고 관리하는 일종의 중간 영역이다.
The cool thing about the staging area, and what sets Git apart from all these other tools, is that you can easily stage some of your files as you finish them and then commit them without committing all the modified files in your working directory, or having to list them on the command line during the commit
staging area가 멋있는 점은 일을 끝내자 마자 쉽게 파일을 스테이지할 수 있고 커밋할 때 워킹 디렉토리에서 수정된 모든 파일을 커밋되지 않는다는 점이다. 또한 커밋할 때까지 명령어로 staging area를 관리할 수 있다.
add commit workflow diagram
This also allows you to stage only portions of a modified file. Gone are the days of making two logically unrelated modifications to a file before you realized that you forgot to commit one of them. Now you can just stage the change you need for the current commit and stage the other change for the next commit. This feature scales up to as many different changes to your file as you need.
우리는 수정한 파일의 일부만 스테이지할 수도 있다. 무언가 빼먹고 커밋하기 전에 논리적으로 무관한 파일을 걸러낼 필요가 없어졌다. 지금은 그냥 지금 커밋하는데 필요한 파일을 스테이지하고 다음 커밋에 필요한 다른 파일들은 다음에 스테이지한다. 이 기능은 그때 그때 상황에 맞추어 필요한 만큼 사용한다.
Of course, Git also makes it pretty easy to ignore this feature if you don't want that kind of control—just slap a '-a' to your commit command in order to add all changes to all files to the staging area.
물론 Git은 이 기능을 생략할 수 있는 방법도 제공한다. 커밋 명렁어에 '-a' 옵션을 추가하는 것만으로 쉽게 수정된 모든 파일이 스테이징 영역에 자동으로 추가된다.
commit only workflow diagram
svn perforce

Distributed/분산

One of the coolest features of any of the Distributed SCMs, Git included, is that it's distributed. This means that instead of doing a "checkout" of the current tip of the source code, you do a "clone" of the entire repository.
Git을 포함한 모든 분산 SCM의 가장 큰 특징은 역시 분산된다는 점이다. 이 것은 최신 소스코드를 체크아웃하지 않고 레파지토리 전체를 복사하는 것(Clone)을 말한다.
This means that even if you're using a centralized workflow, every user has what is essentially a full backup of the main server, each of which could be pushed up to replace the main server in the event of a crash or corruption. There is basically no single point of failure with Git unless there is only a single point.
이 것은 잘 정리된 워크플로우 없이도 모든 사용자가 메인서버의 풀백업을 가지게 된다는 것을 말한다. 그래서 메인서버에 문제가 생겼을때 누구나 메인서버에 푸시할 수 있다.
This does not slow things down much, either. On average, an SVN checkout is only marginally faster than any of the DSCMs. Of the DSCMs I tested, Git was the fastest.
성능도 빠르다. 보통 SVN은 체크아웃에서만 다른 DSCM들보다 조금 빠르다. (적어도 내가 테스트해본) DSCM들 중에서는 Git이 가장 빠르다.
cloning benchmarks
Git 1m 59s
Hg 2m 24s
Bzr 5m 11s
SVN 1m 4s
svn perforce

Any Workflow/워크플로우는 Git하기 나름

One of the amazing things about Git is that because of its distributed nature and super branching system, you can easily implement pretty much any workflow you can think of relatively easily.
Git이 대단한 점은 또 있다. Git은 슈퍼 브랜치 시스템이고 분산 생태계라는 점 때문에 우리가 생각할 수 있는 모든 워크플로우를 쉽게 구현할 수 있다.

Subversion-Style Workflow/Subversion 스타일

A very common Git workflow, especially from people transitioning from a centralized system, is a centralized workflow. Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.
매우 일반적으로 사용되는 Git 워크플로우로 중앙집중식(centralized workflow)이 있다. 특히 Subversion같은 중앙집중식(centralized) 시스템를 사용하다가 넘어온 사람들이 사용한다. 내가 마지막으로 fecth한 후에 아무도 푸시하지 못하도록 할 수 있다. 그래서 모든 개발자가 같은 서버에 푸시하는 centralized 모델도 가능하다.
subversion-style workflow

Integration Manager Workflow/오픈소스 스타일

Another common Git workflow is where there is an integration manager—a single person who commits to the 'blessed' repository, and then a number of developers who clone from that repository, push to their own independent repositories and ask the integrator to pull in their changes. This is the type of development model you often see with open source or GitHub repositories.
또 자주 사용되는 워크플로우로 Integration Manager가 있는 유형이 있다. Integration Manager 한 사람만이 신성한 레파지토리(역자주- 메인 레파지토리)에 커밋할 수 있고 다른 개발자들은 그 레파지토리를 복제한다. 개발자들은 각자의 레파지토리에 커밋하고 관리자에게 자신의 코드를 풀(pull)하도록 요청한다. 이 것은 오픈소스나 GitHub 레파지토리에서 자주 사용되는 개발 모델이다.
integration manager workflow

Dictator and Lieutenants Workflow/Linux 형

For more massive projects, you can setup your developers similar to the way the Linux kernel is run, where people are in charge of a specific subsystem of the project ('lieutenants') and merge in all changes that have to do with that subsystem. Then another integrator (the 'dictator') can pull changes from only his/her lieutenants and push those to the 'blessed' repository that everyone then clones from again.
Linux kernel 개발에서 사용하는 모델을 사용할 수 있다. 프로젝트의 특정한 서브시스템('lieutenants')을 담당하는 사람들은 그 서브시스템에서 일어나는 모든 변화를 관리한다. 'dictator'라고 부르는 또 다른 형태의 관리자는 자신의 'lieutenants'에서 발생한 수정내역을 가져다가 신성한 레파지토리에 다시 푸시한다. 그리고 모든 사람들은 이 신성한 레파지토리에서 다시 복제(Clone)한다. 이 것은 리눅스 커널같은 규모가 큰 프로젝트에서 사용된다.
dictator and lieutenants workflow

Again, Git is entirely flexible about this, so you can mix and match and choose the workflow that is right for you.
다시말해서 Git은 매우 유연하다. 이 워크플로우들 중에서 딱 맞는 것을 골라 쓸 수도 있고 섞어서 자신에게 적합한 워크플로우를 만들어 쓸 수도 있다.
hg svn perforce

GitHub

octocat
I may be biased here, given that I work for GitHub, but I added this section anyway because so many people say that GitHub itself was specifically why they chose Git.
GitHub라는 단락을 추가한 것이 내가 GitHub에서 일하기 때문에 생긴 편견일 수도 있다. 그러나 너무 많은 사람들이 Git을 선택한 이유로 GitHub를 강조하고 있기 때문에 추가했다.
GitHub is a reason to use Git for many people because it is more like a social network for code than a simple hosting site. People find other developers or projects that are similar to the things they are doing, and can easily fork and contribute, creating a very vibrant community around Git and the projects that people use it for.
GitHub는 많은 사람들이 Git을 사용하는 이유중 하나다. GitHub는 단순히 호스팅 사이트를 제공하는 것이 아니라 코드를 위한 소셜 네트워크를 제공한다. 사람들은 자신이 하고 있는 일과 유사한 개발자나 프로젝트를 찾는다. 그리고 Git이나 Git을 사용하는 프로젝트와 관련된 매우 활발한 커뮤니티를 만들어서 쉽게 프로젝트를 복제(fork)하거나 참여할(contribute) 수 있다.
There exist other services, both for Git and for the other SCMs, but few are user-oriented or socially targeted, and none have anywhere near the user-base. This social aspect of GitHub is killer, and this in combination of the above features make working with Git and GitHub a great combination for rapidly developing open source projects.
Git과 다른 SCM을 모두 다루는 서비스들도 있지만 이렇게 사용자 중심이면서 소셜을 타깃으로 하는 서비스는 드문데다가 전적으로 사용자에 기반하는 시스템은 없다. GitHub가 소셜이라는 것은 정말 끈내준다. Git과 GitHub을 함께 사용하면 지금까지 설명한 것들이 잘 어우러져서 정말 오픈소스 프로젝트를 빠르게 개발할 수 있다.
This type of community is simply not available with any of the other SCMs.
다른 SCM에는 이런 형태의 커뮤니티가 없다.
perforce

Easy to Learn/배우기 쉽다

This did not used to be true—early in Git's life, it was not really an SCM so much as a bunch of tools that let you do versioned filesystem work in a distributed manner. However, today, the command set and learning curve of Git are pretty similar to any other SCM, and even better than some.
초창기 Git은 배우기 쉽지 않았다. 그때는 정말이지 분산 SCM을 할 수 있는 툴이 별로 없었다. 그러나 오늘날 Git의 learning curve는 다른 SCM들과 비슷할 뿐만 아니라 심지어 더 쉬운 경우도 있다.
Since this is difficult to prove objectively without some sort of study, I'll just show the difference between the default 'help' menu for the Mercurial and Git commands. I've highlighted the commands that are identical (or nearly) between the two systems. (In Hg, if you type 'hg help', you get a list of 40-some commands.)
ㅇㅇ 객관적으로 증명하는 것이 어렵기 때문에 나는 Mercurial과 Git의 기본적인 'help' 메뉴의 차이를 비교 설명하려한다. 두 시스템이 가지고 있는 정말(혹은 거의) 똑같은 명령어는 다른색으로 표기했다. (Hg의 경우 만약 'hg help'라고 명령어를 실행하면 40여 개의 명령어를 볼 수 있다.)

Mercurial Help

add        add the specified files ...
annotate   show changeset informati...
clone      make a copy of an existi...
commit     commit the specified fil...
diff       diff repository (or sele...
export     dump the header and diff...
init       create a new repository ...
log        show revision history of...
merge      merge working directory ...
parents    show the parents of the ...
pull       pull changes from the sp...
push       push changes to the spec...
remove     remove the specified fil...
serve      export the repository vi...
status     show changed files in th...
update     update working directory

Git Help

add        Add file contents to the index
bisect     Find the change that introduce...
branch     List, create, or delete branches
checkout   Checkout a branch or paths to ...
clone      Clone a repository into a new ...
commit     Record changes to the repository
diff       Show changes between commits, ...
fetch      Download objects and refs from...
grep       Print lines matching a pattern
init       Create an empty git repository
log        Show commit logs
merge      Join two or more development h...
mv         Move or rename a file, a direc...
pull       Fetch from and merge with anot...
push       Update remote refs along with ...
rebase     Forward-port local commits to ...
reset      Reset current HEAD to the spec...
rm         Remove files from the working ...
show       Show various types of objects
status     Show the working tree status
tag        Create, list, delete or verify...
Prior to Git 1.6, all of the Git commands used to be in the executable path, which was very confusing to people. Although Git still recognizes all of those commands, the only command in the path is now 'git'. So, if you look at Mercurial and Git, Git has a nearly identical command set and help system—there is very little difference from a beginning UI perspective today.
Git 1.6 이전에, 모든 Git 명령어들은 각각의 실행 프로그램으로 돼있어서 실행 경로에 등록되면(역자주 - 환경변수 'PATH') 사람들이 매우 헷갈려 했었다. Git은 그 명령어들을 아직도 가지고 있지만 이제는 'git'만 실행할 수 있으면 된다. 그래서 만약 Mercurial과 Git을 보면 명령어들과 도움말이 서로 거의 동일하다. 요즘은 UI 관점에서 시작된 매우 작은 차이가 있을 뿐이다.
These days it's pretty hard to argue that Mercurial or Bazaar is any easier to learn than Git is.
그래서요즘은 Mercurial이나 Bazaar가 Git보다 배우기 쉽다고 주장하기 어렵다.
Expand all | Collapse all
This site is built and maintained by Scott Chacon, a GitHubber.
If you disagree with anything on the site and you have a good reason, please email me so I can fix it.
The source for this site is on GitHub—feel free to send patches if you want to improve it.
이 사이트는 GitHubber인 Scott Chacon가 만들고 관리하고 있습니다.
만약 이 사이트가 마음에 들지 않을때 타당한 이유를 저에게 보내주시면 수정하겠습니다. 이 사이트의 소스는 GitHub에있습니다. 이 사이트에 개선할 것이 있으면 주저하지 말고 패치를 보내주세요.
Also in : German, Spanish, French, Italian, Lolcat, Dutch, Norwegian, Portuguese, Swedish, Simplified and Traditional Chinese
Valid XHTML
\ No newline at end of file + Why Git is Better Than X

Why Git is Better than X

 where "x" is one of
최근 나는 슈퍼 울트라 극성주의자fanboyism, bandwagonism and koolaid-thirst들로부터 Gitster들을 옹호하는데 지쳐서 이 사이트를 만들었다. 나는 사람들이 왜 Git으로 갈아타는지를 정리했다. 클릭해보라.
모두 펴기 | 모두 숨기기
hg bzr svn perforce

값 싼 브랜칭

다른 SCM에 비해 Git의 가장 큰 특징은 아마도 브랜치 모델일 것이다. Git은 내가 여기서 비교하고자 하는 다른 모델들과는 완전히 다르다. 대부분이 권장하는 궁극의 브랜치는 새 디렉토리로 레파지토리를 통째로 복사하는 것이다.
하지만 Git은 그렇게 동작하지 않는다. Git에서는 여러 개의 로컬 브랜치를 가질수 있으며 그 로컬 브랜치들은 서로 완벽하게 독립적이기 때문에 개발 중 수행하는 생성, 머지, 삭제 명령도 독립적으로 수행된다.
Git으로는 다음과 같은 일들을 할 수 있다:
  • 아이디어를 실험하기 위해 브랜치를 만들고, 몇 번 커밋을 하고, 원래 것으로 돌아가, 패치를 적용한다. 다시 실험중인 브랜치로 돌아가 그것을 머지한다.
  • 제품으로 출시하기 위한 브랜치는 하나만 가질 수 있지만 그외 다른 목적의 브랜치는 마음것 만들 수 있다. 테스트나 일상적인 업무를 위한 브랜치를 만들어 작업하고 그 것을 머지한다.
  • 당신이 만들고 있는 이슈마다 브랜치를 새로 만들고 그 브랜치들 사이들 오가며 작업할 수 있다. 그리고 그 브랜치를 마스터 브랜치로 머지한 후에 그 브랜치들을 삭제한다.
  • 실험용 브랜치를 만들고 쓸모가 없으면 바로 삭제한다. (그 동안 다른 브랜치들을 푸시했었더라도) 실험은 버려졌기 때문에 아무도 모른다.
branches flowchart
중요한 것은 원격의 레파지토리에 푸시할 때 가지고 있는 브랜치 전부를 푸시하지 않는 점이다. 가지고 있는 브랜치들 중 하나만 공유할 수 있다. 그래서 사람들은 언제, 어떻게 브랜치를 머지하고 공유해야 할지에 대한 고민없이 쉽게 새로운 아이디어를 실험할 수 있다.
다른 시스템과 함께 Git을 사용할 방법이 있지만 매우 어렵고 에러나기 쉽다. Git을 배우면 이 과정이 매우 쉬워지고 일하는 방식도 변화한다.
jamis twitter trevorturk twitter thillerson twitter boblmartens twitter mathie twitter
svn perforce

역사는 로컬에서

이 것은 모든 분산 SCM에도 해당하는 이야기지만 나는 주로 Git을 많이 사용한다. Git은 외부 요소가 매우 적다. 내 하드디스크 세상 밖으로 소통하는 방법은 'fetch', 'pull', 'push'밖에 없다.
이 것은 우리가 해왔던 것 보다 모든 명령의 수행 속도를 빠르게 해줄뿐만 아니라 오프라인에서도 작업할 수 있도록 해준다. 실제로 아무것도 아닐 것 같지만 나는 내가 자주 오프라인으로 작업하고 있는 것을 발견하곤 항상 매우 놀란다. 비행기나 기차안에서도 오프라인으로 브랜치, 머지, 커밋하고 프로젝트의 히스토리를 살펴볼 수 있다는 것은 매우 생산적이다.
local repo to remote repo flowchart
심지어 Mercurial은 incoming과 outouing같은 명령어는 서버와 통신해야 한다. 하지만 Git은 서버에 있는 데이터를 로컬 브랜치로 fetch한다. fetch를 한 후에 오프라인으로도 서버에 있는 데이터와 비교, 머지, 로그 등의 일을 할 수 있다.
즉, Git 레파지토리에 있는 작업물들을 헝클지도 않으면서 나와 함께 일하는 동료들은 모두 자신만의 브랜치를 매우 쉽게 만들 수 있다.
bzr svn perforce

Git is Fast/Git은 빠르다

모두가 Git의 장점으로 'Git은 빠르다'라고 내세운다. 다른 SCM의 맹신자들도 Git이 빠르다고 인정한다. Git의 모든 오퍼레이션은 로컬에서 수행된다. 네트워크가 필요한 SVN과 Perforce이 뛸 때 날고 있는 셈이다. 게다가 Git은 로컬에서 명령을 수행하는 다른 DSCM과 비교해도 빠르다.
처음 개발할때 부터 리눅스 커널에 사용할 목적이 였기 때문에 규모가 큰 레파지토리일 수록 더욱 효과적이다. 게다가 Git은 C로 작성돼있어서 고수준 언어가 만들어내는 오버헤드도 없다. Git을 만든 선구자들은 '빠른 것'을 설계 목표중 하나로 삼았다.
나는 몇 가지 벤치마크 테스트를 진행했다. Git, Mercurial, Bazaar 이렇게 세가지 SCM에 각각 Django source code를 올려놓고 테스트를 했다. 나는 또한 SVN으로도 이 중 몇가지 테스트를 진행했다. 내가 장담컨데 SVN은 느리다. 기본적으로 Bazaar의 결과에 네트워크 레이턴시(Latency)를 더해야 한다.
init benchmarks add benchmarks status benchmarks diff benchmarks branching benchmarks
tag benchmarks log benchmarks large commit benchmarks small commit benchmarks
결론부터 말하자면 파일을 새로 추가하는 경우를 제외하면 Git은 항상 빠르다.(물론 정말정말 큰 데이터를 커밋하는 경우는 Hg가 제일 빠르다. 그러나 내가 테스트한 크기조차도 보통은 경험할 수 없다. 그러니까 대부분의 경우는 Git이 더 빠르다.)
Git Hg Bzr
Init 0.024s 0.059s 0.600s
Add 8.535s 0.368s 2.381s
Status 0.451s 1.946s 14.744s
Diff 0.543s 2.189s 14.248s
Tag 0.056s 1.201s 1.892s
Log 0.711s 2.650s 9.055s
Commit (Large) 12.480s 12.500s 23.002s
Commit (Small) 0.086s 0.517s 1.139s
Branch (Cold) 1.161s 94.681s 82.249s
Branch (Hot) 0.070s 12.300s 39.411s
The cold and hot branching numbers are the numbers for the first and second times that I branched a repo—the second number being a branch with a hot disk cache.
이건 먼소린지..ㅋㅋㅋ
테스트 결과에서 'add'의 경우는 매우 느리다. 하지만 이 것은 파일 2000개가 넘는 경우에나 해당된다. 대부분의 사람들은 하루를 기준으로 일을 하는데 보통 'add'는 순식간에 이루어진다. 여기서 진행한 다른(라지 커밋은 제외한) 테스트 결과들은 우리가 날마다 실제로 하는 패턴들이다.
이 테스트를 재현하는 것은 어렵지 않다. 단순히 각 시스템마다 다음과 같은 명령어를 수행하여 Django 프로젝트의 클론을 만들면 된다.
  • git clone git://github.com/brosner/django.git dj-git
  • hg clone http://hg.dpaste.com/django/trunk dj-hg
  • bzr branch lp:django dj-bzr
  • svn checkout http://code.djangoproject.com/svn/django/trunk dj-svn
svn

Git은 작다.

Git은 디스크 공간을 적게 차지한다. Git 디렉토리는 일반적으로 SVN checkout한 것보다 별반 차이 없다. 어떤 경우에는 SVN의 것보다 작다(.svn 디렉토리에는 뭔가 무진장 많다는 것만은 분명이다.).
다음은 Django project의 클론에 대한 것이다. 동일한 버전을 기준으로 비공식(semi-official) Git 미러를 통해 만들었다.
Git Hg Bzr SVN
Repo Alone 24M 34M 45M
Entire Directory 43M 53M 64M 61M
hg bzr svn perforce

Staging 영역

다른 시스템과 달리 Git은 "staging area" 혹은 "index"라고 부르는 것이 있다. 커밋할 것 같은 파일을 넣고 관리하는 일종의 중간 영역이다.
staging area가 멋있는 점은 일을 끝내자 마자 쉽게 파일을 스테이지할 수 있고 커밋할 때 워킹 디렉토리에서 수정된 모든 파일을 커밋되지 않는다는 점이다. 또한 커밋할 때까지 명령어로 staging area를 관리할 수 있다.
add commit workflow diagram
우리는 수정한 파일의 일부만 스테이지할 수도 있다. 무언가 빼먹고 커밋하기 전에 논리적으로 무관한 파일을 걸러낼 필요가 없어졌다. 지금은 그냥 지금 커밋하는데 필요한 파일을 스테이지하고 다음 커밋에 필요한 다른 파일들은 다음에 스테이지한다. 이 기능은 그때 그때 상황에 맞추어 필요한 만큼 사용한다.
물론 Git은 이 기능을 건너 뛰는 방법도 제공한다. 커밋 명렁어에 '-a' 옵션을 추가하는 것만으로 쉽게 수정된 모든 파일이 스테이징 영역에 자동으로 추가된다.
commit only workflow diagram
svn perforce

분산

Git을 포함한 모든 분산 SCM의 가장 큰 특징은 당연히 분산된다는 점이다. 이 것은 최신 소스코드를 체크아웃하지 않고 레파지토리 전체를 복사하는 것(Clone)을 말한다.
잘 정리된 워크플로우 없이도 모든 사용자가 메인서버의 풀백업을 가질 수 있다. 그래서 메인서버에 문제가 생겼을때 누구나 메인서버에 푸시할 수 있다.
성능도 빠르다. 보통 SVN은 체크아웃에서만 다른 DSCM들보다 조금 빠르다. (적어도 내가 테스트해본) DSCM들 중에서는 Git이 가장 빠르다.
cloning benchmarks
Git 1m 59s
Hg 2m 24s
Bzr 5m 11s
SVN 1m 4s
svn perforce

워크플로우는 Git하기 나름

Git이 대단한 점은 또 있다. Git은 슈퍼 브랜칭 시스템이고 분산 생태계라는 점 때문에 우리가 생각할 수 있는 모든 워크플로우를 쉽게 구현할 수 있다.

Subversion-Style Workflow

매우 일반적으로 사용되는 Git 워크플로우로 중앙집중식centralized workflow이 있다. 특히 Subversion같은 중앙집중식 시스템를 사용하다가 넘어온 사람들이 사용한다. 내가 마지막으로 fecth한 후에 아무도 푸시하지 못하도록 할 수 있다. 그래서 모든 개발자가 같은 서버에 푸시하는 중앙집중식 모델도 가능하다.
subversion-style workflow

Integration Manager Workflow

또 자주 사용되는 워크플로우로 Integration Manager가 있는 유형이 있다. Integration Manager 한 사람만이 신성한 레파지토리(역자주- 메인 레파지토리)에 커밋할 수 있고 다른 개발자들은 그 레파지토리를 복제한다. 개발자들은 각자의 레파지토리에 커밋하고 관리자에게 자신의 코드를 풀(pull)하도록 요청한다. 이 것은 오픈소스나 GitHub 레파지토리에서 자주 사용되는 개발 모델이다.
integration manager workflow

Dictator and Lieutenants Workflow

Linux kernel 개발에서 사용하는 모델을 사용할 수 있다. 프로젝트의 특정한 서브시스템('lieutenants')을 담당하는 사람들은 그 서브시스템에서 일어나는 모든 변화를 관리한다. 'dictator'라고 부르는 또 다른 형태의 관리자는 자신의 'lieutenants'에서 발생한 수정내역을 가져다가 신성한 레파지토리에 다시 푸시한다. 그리고 모든 사람들은 이 신성한 레파지토리에서 다시 복제(Clone)한다. 이 것은 리눅스 커널같은 규모가 큰 프로젝트에서 사용된다.
dictator and lieutenants workflow

다시말해서 Git은 매우 유연하다. 이 워크플로우들 중에서 딱 맞는 것을 골라 쓸 수도 있고 섞어서 자신에게 적합한 워크플로우를 만들어 쓸 수도 있다.
hg svn perforce

GitHub

octocat
GitHub라는 단락을 추가한 것이 내가 GitHub에서 일하기 때문에 생긴 편견일 수도 있다. 그러나 너무나 많은 사람들이 Git을 선택한 이유로 GitHub를 들고 있기 때문에 추가했다.
GitHub는 많은 사람들이 Git을 사용하는 이유중 하나다. GitHub는 단순히 호스팅 사이트를 제공하는 것이 아니라 코드를 위한 소셜 네트워크를 제공한다. 사람들은 자신이 하고 있는 일과 유사한 개발자나 프로젝트를 찾는다. 그리고 Git이나 Git을 사용하는 프로젝트와 관련된 매우 활발한 커뮤니티를 만들어서 쉽게 프로젝트를 복제(fork)하거나 참여할(contribute) 수 있다.
Git과 다른 SCM을 모두 다루는 서비스들도 있지만 이렇게 사용자 중심이면서 소셜을 타깃으로 하는 서비스는 드문데다가 전적으로 사용자에 기반하는 시스템은 없다. GitHub가 소셜이라는 것은 정말 끈내준다. Git과 GitHub을 함께 사용하면 지금까지 설명한 것들이 잘 어우러져서 정말 오픈소스 프로젝트를 빠르게 개발할 수 있다.
다른 SCM에는 이런 형태의 커뮤니티가 없다.
perforce

Easy to Learn/배우기 쉽다

초창기 Git은 배우기 쉽지 않았다. 그때는 정말이지 분산 SCM을 할 수 있는 툴이 별로 없었다. 그러나 오늘날 Git의 learning curve는 다른 SCM들과 비슷할 뿐만 아니라 심지어 더 쉬운 경우도 있다.
객관적으로 증명하려면 연구라도 해야 하기 때문에 나는 Mercurial과 Git의 기본적인 'help' 메뉴의 차이를 비교 설명하려한다. 두 시스템이 가지고 있는 정말(혹은 거의) 똑같은 명령어는 다른색으로 표기했다. ('hg help'라고 명령어를 실행하면 40여 개의 명령어를 볼 수 있다.)

Mercurial Help

add        add the specified files ...
annotate   show changeset informati...
clone      make a copy of an existi...
commit     commit the specified fil...
diff       diff repository (or sele...
export     dump the header and diff...
init       create a new repository ...
log        show revision history of...
merge      merge working directory ...
parents    show the parents of the ...
pull       pull changes from the sp...
push       push changes to the spec...
remove     remove the specified fil...
serve      export the repository vi...
status     show changed files in th...
update     update working directory

Git Help

add        Add file contents to the index
bisect     Find the change that introduce...
branch     List, create, or delete branches
checkout   Checkout a branch or paths to ...
clone      Clone a repository into a new ...
commit     Record changes to the repository
diff       Show changes between commits, ...
fetch      Download objects and refs from...
grep       Print lines matching a pattern
init       Create an empty git repository
log        Show commit logs
merge      Join two or more development h...
mv         Move or rename a file, a direc...
pull       Fetch from and merge with anot...
push       Update remote refs along with ...
rebase     Forward-port local commits to ...
reset      Reset current HEAD to the spec...
rm         Remove files from the working ...
show       Show various types of objects
status     Show the working tree status
tag        Create, list, delete or verify...
Git 1.6 이전에, 모든 Git 명령어들은 각각의 실행 프로그램으로 돼있었다. 그래서 실행 경로에 등록하면(역자주 - 환경변수 'PATH') 사람들은 매우 헷갈려 했었다. Git은 그 명령어들을 아직도 가지고 있지만 이제는 'git'만 실행할 수 있으면 된다. 그래서 Mercurial과 Git을 보면 명령어들과 도움말이 서로 거의 동일하다. 요즘은 UI 관점에서 시작된 매우 작은 차이가 있을 뿐이다.
요즘은 Mercurial이나 Bazaar가 Git보다 배우기 쉽다고 주장하기 어렵다.
Expand all | Collapse all
이 사이트는 GitHubber인 Scott Chacon가 만들고 관리하고 있습니다.
만약 이 사이트가 마음에 들지 않을때 타당한 이유를 저에게 보내주시면 수정하겠습니다. 이 사이트의 소스는 GitHub에있습니다. 이 사이트에 개선할 것이 있으면 주저하지 말고 패치를 보내주세요. 이 사이트의 한글버전은 박창우가 하고 있습니다.
Also in : German, Spanish, French, Italian, Lolcat, Dutch, Norwegian, Portuguese, Swedish, Simplified and Traditional Chinese
Valid XHTML
\ No newline at end of file From 7f29b3f66e25c8def1060d9721b59bef8eb4fab3 Mon Sep 17 00:00:00 2001 From: Changwoo Park Date: Wed, 29 Jun 2011 09:25:31 +0800 Subject: [PATCH 3/5] complete translation --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index ecb89b5..d7dd4ee 100644 --- a/index.html +++ b/index.html @@ -1 +1 @@ - Why Git is Better Than X

Why Git is Better than X

 where "x" is one of
최근 나는 슈퍼 울트라 극성주의자fanboyism, bandwagonism and koolaid-thirst들로부터 Gitster들을 옹호하는데 지쳐서 이 사이트를 만들었다. 나는 사람들이 왜 Git으로 갈아타는지를 정리했다. 클릭해보라.
모두 펴기 | 모두 숨기기
hg bzr svn perforce

값 싼 브랜칭

다른 SCM에 비해 Git의 가장 큰 특징은 아마도 브랜치 모델일 것이다. Git은 내가 여기서 비교하고자 하는 다른 모델들과는 완전히 다르다. 대부분이 권장하는 궁극의 브랜치는 새 디렉토리로 레파지토리를 통째로 복사하는 것이다.
하지만 Git은 그렇게 동작하지 않는다. Git에서는 여러 개의 로컬 브랜치를 가질수 있으며 그 로컬 브랜치들은 서로 완벽하게 독립적이기 때문에 개발 중 수행하는 생성, 머지, 삭제 명령도 독립적으로 수행된다.
Git으로는 다음과 같은 일들을 할 수 있다:
  • 아이디어를 실험하기 위해 브랜치를 만들고, 몇 번 커밋을 하고, 원래 것으로 돌아가, 패치를 적용한다. 다시 실험중인 브랜치로 돌아가 그것을 머지한다.
  • 제품으로 출시하기 위한 브랜치는 하나만 가질 수 있지만 그외 다른 목적의 브랜치는 마음것 만들 수 있다. 테스트나 일상적인 업무를 위한 브랜치를 만들어 작업하고 그 것을 머지한다.
  • 당신이 만들고 있는 이슈마다 브랜치를 새로 만들고 그 브랜치들 사이들 오가며 작업할 수 있다. 그리고 그 브랜치를 마스터 브랜치로 머지한 후에 그 브랜치들을 삭제한다.
  • 실험용 브랜치를 만들고 쓸모가 없으면 바로 삭제한다. (그 동안 다른 브랜치들을 푸시했었더라도) 실험은 버려졌기 때문에 아무도 모른다.
branches flowchart
중요한 것은 원격의 레파지토리에 푸시할 때 가지고 있는 브랜치 전부를 푸시하지 않는 점이다. 가지고 있는 브랜치들 중 하나만 공유할 수 있다. 그래서 사람들은 언제, 어떻게 브랜치를 머지하고 공유해야 할지에 대한 고민없이 쉽게 새로운 아이디어를 실험할 수 있다.
다른 시스템과 함께 Git을 사용할 방법이 있지만 매우 어렵고 에러나기 쉽다. Git을 배우면 이 과정이 매우 쉬워지고 일하는 방식도 변화한다.
jamis twitter trevorturk twitter thillerson twitter boblmartens twitter mathie twitter
svn perforce

역사는 로컬에서

이 것은 모든 분산 SCM에도 해당하는 이야기지만 나는 주로 Git을 많이 사용한다. Git은 외부 요소가 매우 적다. 내 하드디스크 세상 밖으로 소통하는 방법은 'fetch', 'pull', 'push'밖에 없다.
이 것은 우리가 해왔던 것 보다 모든 명령의 수행 속도를 빠르게 해줄뿐만 아니라 오프라인에서도 작업할 수 있도록 해준다. 실제로 아무것도 아닐 것 같지만 나는 내가 자주 오프라인으로 작업하고 있는 것을 발견하곤 항상 매우 놀란다. 비행기나 기차안에서도 오프라인으로 브랜치, 머지, 커밋하고 프로젝트의 히스토리를 살펴볼 수 있다는 것은 매우 생산적이다.
local repo to remote repo flowchart
심지어 Mercurial은 incoming과 outouing같은 명령어는 서버와 통신해야 한다. 하지만 Git은 서버에 있는 데이터를 로컬 브랜치로 fetch한다. fetch를 한 후에 오프라인으로도 서버에 있는 데이터와 비교, 머지, 로그 등의 일을 할 수 있다.
즉, Git 레파지토리에 있는 작업물들을 헝클지도 않으면서 나와 함께 일하는 동료들은 모두 자신만의 브랜치를 매우 쉽게 만들 수 있다.
bzr svn perforce

Git is Fast/Git은 빠르다

모두가 Git의 장점으로 'Git은 빠르다'라고 내세운다. 다른 SCM의 맹신자들도 Git이 빠르다고 인정한다. Git의 모든 오퍼레이션은 로컬에서 수행된다. 네트워크가 필요한 SVN과 Perforce이 뛸 때 날고 있는 셈이다. 게다가 Git은 로컬에서 명령을 수행하는 다른 DSCM과 비교해도 빠르다.
처음 개발할때 부터 리눅스 커널에 사용할 목적이 였기 때문에 규모가 큰 레파지토리일 수록 더욱 효과적이다. 게다가 Git은 C로 작성돼있어서 고수준 언어가 만들어내는 오버헤드도 없다. Git을 만든 선구자들은 '빠른 것'을 설계 목표중 하나로 삼았다.
나는 몇 가지 벤치마크 테스트를 진행했다. Git, Mercurial, Bazaar 이렇게 세가지 SCM에 각각 Django source code를 올려놓고 테스트를 했다. 나는 또한 SVN으로도 이 중 몇가지 테스트를 진행했다. 내가 장담컨데 SVN은 느리다. 기본적으로 Bazaar의 결과에 네트워크 레이턴시(Latency)를 더해야 한다.
init benchmarks add benchmarks status benchmarks diff benchmarks branching benchmarks
tag benchmarks log benchmarks large commit benchmarks small commit benchmarks
결론부터 말하자면 파일을 새로 추가하는 경우를 제외하면 Git은 항상 빠르다.(물론 정말정말 큰 데이터를 커밋하는 경우는 Hg가 제일 빠르다. 그러나 내가 테스트한 크기조차도 보통은 경험할 수 없다. 그러니까 대부분의 경우는 Git이 더 빠르다.)
Git Hg Bzr
Init 0.024s 0.059s 0.600s
Add 8.535s 0.368s 2.381s
Status 0.451s 1.946s 14.744s
Diff 0.543s 2.189s 14.248s
Tag 0.056s 1.201s 1.892s
Log 0.711s 2.650s 9.055s
Commit (Large) 12.480s 12.500s 23.002s
Commit (Small) 0.086s 0.517s 1.139s
Branch (Cold) 1.161s 94.681s 82.249s
Branch (Hot) 0.070s 12.300s 39.411s
The cold and hot branching numbers are the numbers for the first and second times that I branched a repo—the second number being a branch with a hot disk cache.
이건 먼소린지..ㅋㅋㅋ
테스트 결과에서 'add'의 경우는 매우 느리다. 하지만 이 것은 파일 2000개가 넘는 경우에나 해당된다. 대부분의 사람들은 하루를 기준으로 일을 하는데 보통 'add'는 순식간에 이루어진다. 여기서 진행한 다른(라지 커밋은 제외한) 테스트 결과들은 우리가 날마다 실제로 하는 패턴들이다.
이 테스트를 재현하는 것은 어렵지 않다. 단순히 각 시스템마다 다음과 같은 명령어를 수행하여 Django 프로젝트의 클론을 만들면 된다.
  • git clone git://github.com/brosner/django.git dj-git
  • hg clone http://hg.dpaste.com/django/trunk dj-hg
  • bzr branch lp:django dj-bzr
  • svn checkout http://code.djangoproject.com/svn/django/trunk dj-svn
svn

Git은 작다.

Git은 디스크 공간을 적게 차지한다. Git 디렉토리는 일반적으로 SVN checkout한 것보다 별반 차이 없다. 어떤 경우에는 SVN의 것보다 작다(.svn 디렉토리에는 뭔가 무진장 많다는 것만은 분명이다.).
다음은 Django project의 클론에 대한 것이다. 동일한 버전을 기준으로 비공식(semi-official) Git 미러를 통해 만들었다.
Git Hg Bzr SVN
Repo Alone 24M 34M 45M
Entire Directory 43M 53M 64M 61M
hg bzr svn perforce

Staging 영역

다른 시스템과 달리 Git은 "staging area" 혹은 "index"라고 부르는 것이 있다. 커밋할 것 같은 파일을 넣고 관리하는 일종의 중간 영역이다.
staging area가 멋있는 점은 일을 끝내자 마자 쉽게 파일을 스테이지할 수 있고 커밋할 때 워킹 디렉토리에서 수정된 모든 파일을 커밋되지 않는다는 점이다. 또한 커밋할 때까지 명령어로 staging area를 관리할 수 있다.
add commit workflow diagram
우리는 수정한 파일의 일부만 스테이지할 수도 있다. 무언가 빼먹고 커밋하기 전에 논리적으로 무관한 파일을 걸러낼 필요가 없어졌다. 지금은 그냥 지금 커밋하는데 필요한 파일을 스테이지하고 다음 커밋에 필요한 다른 파일들은 다음에 스테이지한다. 이 기능은 그때 그때 상황에 맞추어 필요한 만큼 사용한다.
물론 Git은 이 기능을 건너 뛰는 방법도 제공한다. 커밋 명렁어에 '-a' 옵션을 추가하는 것만으로 쉽게 수정된 모든 파일이 스테이징 영역에 자동으로 추가된다.
commit only workflow diagram
svn perforce

분산

Git을 포함한 모든 분산 SCM의 가장 큰 특징은 당연히 분산된다는 점이다. 이 것은 최신 소스코드를 체크아웃하지 않고 레파지토리 전체를 복사하는 것(Clone)을 말한다.
잘 정리된 워크플로우 없이도 모든 사용자가 메인서버의 풀백업을 가질 수 있다. 그래서 메인서버에 문제가 생겼을때 누구나 메인서버에 푸시할 수 있다.
성능도 빠르다. 보통 SVN은 체크아웃에서만 다른 DSCM들보다 조금 빠르다. (적어도 내가 테스트해본) DSCM들 중에서는 Git이 가장 빠르다.
cloning benchmarks
Git 1m 59s
Hg 2m 24s
Bzr 5m 11s
SVN 1m 4s
svn perforce

워크플로우는 Git하기 나름

Git이 대단한 점은 또 있다. Git은 슈퍼 브랜칭 시스템이고 분산 생태계라는 점 때문에 우리가 생각할 수 있는 모든 워크플로우를 쉽게 구현할 수 있다.

Subversion-Style Workflow

매우 일반적으로 사용되는 Git 워크플로우로 중앙집중식centralized workflow이 있다. 특히 Subversion같은 중앙집중식 시스템를 사용하다가 넘어온 사람들이 사용한다. 내가 마지막으로 fecth한 후에 아무도 푸시하지 못하도록 할 수 있다. 그래서 모든 개발자가 같은 서버에 푸시하는 중앙집중식 모델도 가능하다.
subversion-style workflow

Integration Manager Workflow

또 자주 사용되는 워크플로우로 Integration Manager가 있는 유형이 있다. Integration Manager 한 사람만이 신성한 레파지토리(역자주- 메인 레파지토리)에 커밋할 수 있고 다른 개발자들은 그 레파지토리를 복제한다. 개발자들은 각자의 레파지토리에 커밋하고 관리자에게 자신의 코드를 풀(pull)하도록 요청한다. 이 것은 오픈소스나 GitHub 레파지토리에서 자주 사용되는 개발 모델이다.
integration manager workflow

Dictator and Lieutenants Workflow

Linux kernel 개발에서 사용하는 모델을 사용할 수 있다. 프로젝트의 특정한 서브시스템('lieutenants')을 담당하는 사람들은 그 서브시스템에서 일어나는 모든 변화를 관리한다. 'dictator'라고 부르는 또 다른 형태의 관리자는 자신의 'lieutenants'에서 발생한 수정내역을 가져다가 신성한 레파지토리에 다시 푸시한다. 그리고 모든 사람들은 이 신성한 레파지토리에서 다시 복제(Clone)한다. 이 것은 리눅스 커널같은 규모가 큰 프로젝트에서 사용된다.
dictator and lieutenants workflow

다시말해서 Git은 매우 유연하다. 이 워크플로우들 중에서 딱 맞는 것을 골라 쓸 수도 있고 섞어서 자신에게 적합한 워크플로우를 만들어 쓸 수도 있다.
hg svn perforce

GitHub

octocat
GitHub라는 단락을 추가한 것이 내가 GitHub에서 일하기 때문에 생긴 편견일 수도 있다. 그러나 너무나 많은 사람들이 Git을 선택한 이유로 GitHub를 들고 있기 때문에 추가했다.
GitHub는 많은 사람들이 Git을 사용하는 이유중 하나다. GitHub는 단순히 호스팅 사이트를 제공하는 것이 아니라 코드를 위한 소셜 네트워크를 제공한다. 사람들은 자신이 하고 있는 일과 유사한 개발자나 프로젝트를 찾는다. 그리고 Git이나 Git을 사용하는 프로젝트와 관련된 매우 활발한 커뮤니티를 만들어서 쉽게 프로젝트를 복제(fork)하거나 참여할(contribute) 수 있다.
Git과 다른 SCM을 모두 다루는 서비스들도 있지만 이렇게 사용자 중심이면서 소셜을 타깃으로 하는 서비스는 드문데다가 전적으로 사용자에 기반하는 시스템은 없다. GitHub가 소셜이라는 것은 정말 끈내준다. Git과 GitHub을 함께 사용하면 지금까지 설명한 것들이 잘 어우러져서 정말 오픈소스 프로젝트를 빠르게 개발할 수 있다.
다른 SCM에는 이런 형태의 커뮤니티가 없다.
perforce

Easy to Learn/배우기 쉽다

초창기 Git은 배우기 쉽지 않았다. 그때는 정말이지 분산 SCM을 할 수 있는 툴이 별로 없었다. 그러나 오늘날 Git의 learning curve는 다른 SCM들과 비슷할 뿐만 아니라 심지어 더 쉬운 경우도 있다.
객관적으로 증명하려면 연구라도 해야 하기 때문에 나는 Mercurial과 Git의 기본적인 'help' 메뉴의 차이를 비교 설명하려한다. 두 시스템이 가지고 있는 정말(혹은 거의) 똑같은 명령어는 다른색으로 표기했다. ('hg help'라고 명령어를 실행하면 40여 개의 명령어를 볼 수 있다.)

Mercurial Help

add        add the specified files ...
annotate   show changeset informati...
clone      make a copy of an existi...
commit     commit the specified fil...
diff       diff repository (or sele...
export     dump the header and diff...
init       create a new repository ...
log        show revision history of...
merge      merge working directory ...
parents    show the parents of the ...
pull       pull changes from the sp...
push       push changes to the spec...
remove     remove the specified fil...
serve      export the repository vi...
status     show changed files in th...
update     update working directory

Git Help

add        Add file contents to the index
bisect     Find the change that introduce...
branch     List, create, or delete branches
checkout   Checkout a branch or paths to ...
clone      Clone a repository into a new ...
commit     Record changes to the repository
diff       Show changes between commits, ...
fetch      Download objects and refs from...
grep       Print lines matching a pattern
init       Create an empty git repository
log        Show commit logs
merge      Join two or more development h...
mv         Move or rename a file, a direc...
pull       Fetch from and merge with anot...
push       Update remote refs along with ...
rebase     Forward-port local commits to ...
reset      Reset current HEAD to the spec...
rm         Remove files from the working ...
show       Show various types of objects
status     Show the working tree status
tag        Create, list, delete or verify...
Git 1.6 이전에, 모든 Git 명령어들은 각각의 실행 프로그램으로 돼있었다. 그래서 실행 경로에 등록하면(역자주 - 환경변수 'PATH') 사람들은 매우 헷갈려 했었다. Git은 그 명령어들을 아직도 가지고 있지만 이제는 'git'만 실행할 수 있으면 된다. 그래서 Mercurial과 Git을 보면 명령어들과 도움말이 서로 거의 동일하다. 요즘은 UI 관점에서 시작된 매우 작은 차이가 있을 뿐이다.
요즘은 Mercurial이나 Bazaar가 Git보다 배우기 쉽다고 주장하기 어렵다.
Expand all | Collapse all
이 사이트는 GitHubber인 Scott Chacon가 만들고 관리하고 있습니다.
만약 이 사이트가 마음에 들지 않을때 타당한 이유를 저에게 보내주시면 수정하겠습니다. 이 사이트의 소스는 GitHub에있습니다. 이 사이트에 개선할 것이 있으면 주저하지 말고 패치를 보내주세요. 이 사이트의 한글버전은 박창우가 하고 있습니다.
Also in : German, Spanish, French, Italian, Lolcat, Dutch, Norwegian, Portuguese, Swedish, Simplified and Traditional Chinese
Valid XHTML
\ No newline at end of file + Why Git is Better Than X

Why Git is Better than X

 where "x" is one of
최근 나는 슈퍼 울트라 극성주의자fanboyism, bandwagonism and koolaid-thirst들로부터 Gitster들을 옹호하는데 지쳐서 이 사이트를 만들었다. 나는 사람들이 왜 Git으로 갈아타는지를 정리했다. 클릭해보라.
모두 펴기 | 모두 숨기기
hg bzr svn perforce

값 싼 브랜칭

다른 SCM에 비해 Git의 가장 큰 특징은 아마도 브랜치 모델일 것이다. Git은 내가 여기서 비교하고자 하는 다른 모델들과는 완전히 다르다. 대부분이 권장하는 궁극의 브랜치는 새 디렉토리로 레파지토리를 통째로 복사하는 것이다.
하지만 Git은 그렇게 동작하지 않는다. Git에서는 여러 개의 로컬 브랜치를 가질수 있으며 그 로컬 브랜치들은 서로 완벽하게 독립적이기 때문에 개발 중 수행하는 생성, 머지, 삭제 명령도 독립적으로 수행된다.
Git으로는 다음과 같은 일들을 할 수 있다:
  • 아이디어를 실험하기 위해 브랜치를 만들고, 몇 번 커밋을 하고, 원래 것으로 돌아가, 패치를 적용한다. 다시 실험중인 브랜치로 돌아가 그것을 머지한다.
  • 제품으로 출시하기 위한 브랜치는 하나만 가질 수 있지만 그외 다른 목적의 브랜치는 마음것 만들 수 있다. 테스트나 일상적인 업무를 위한 브랜치를 만들어 작업하고 그 것을 머지한다.
  • 당신이 만들고 있는 이슈마다 브랜치를 새로 만들고 그 브랜치들 사이들 오가며 작업할 수 있다. 그리고 그 브랜치를 마스터 브랜치로 머지한 후에 그 브랜치들을 삭제한다.
  • 실험용 브랜치를 만들고 쓸모가 없으면 바로 삭제한다. (그 동안 다른 브랜치들을 푸시했었더라도) 실험은 버려졌기 때문에 아무도 모른다.
branches flowchart
중요한 것은 원격의 레파지토리에 푸시할 때 가지고 있는 브랜치 전부를 푸시하지 않는 점이다. 가지고 있는 브랜치들 중 하나만 공유할 수 있다. 그래서 사람들은 언제, 어떻게 브랜치를 머지하고 공유해야 할지에 대한 고민없이 쉽게 새로운 아이디어를 실험할 수 있다.
다른 시스템과 함께 Git을 사용할 방법이 있지만 매우 어렵고 에러나기 쉽다. Git을 배우면 이 과정이 매우 쉬워지고 일하는 방식도 변화한다.
jamis twitter trevorturk twitter thillerson twitter boblmartens twitter mathie twitter
svn perforce

역사는 로컬에서

이 것은 모든 분산 SCM에도 해당하는 이야기지만 나는 주로 Git을 많이 사용한다. Git은 외부 요소가 매우 적다. 내 하드디스크 세상 밖으로 소통하는 방법은 'fetch', 'pull', 'push'밖에 없다.
이 것은 우리가 해왔던 것 보다 모든 명령의 수행 속도를 빠르게 해줄뿐만 아니라 오프라인에서도 작업할 수 있도록 해준다. 실제로 아무것도 아닐 것 같지만 나는 내가 자주 오프라인으로 작업하고 있는 것을 발견하곤 항상 매우 놀란다. 비행기나 기차안에서도 오프라인으로 브랜치, 머지, 커밋하고 프로젝트의 히스토리를 살펴볼 수 있다는 것은 매우 생산적이다.
local repo to remote repo flowchart
심지어 Mercurial은 incoming과 outouing같은 명령어는 서버와 통신해야 한다. 하지만 Git은 서버에 있는 데이터를 로컬 브랜치로 fetch한다. fetch를 한 후에 오프라인으로도 서버에 있는 데이터와 비교, 머지, 로그 등의 일을 할 수 있다.
즉, Git 레파지토리에 있는 작업물들을 헝클지도 않으면서 나와 함께 일하는 동료들은 모두 자신만의 브랜치를 매우 쉽게 만들 수 있다.
bzr svn perforce

Git is Fast/Git은 빠르다

모두가 Git의 장점으로 'Git은 빠르다'라고 내세운다. 다른 SCM의 맹신자들도 Git이 빠르다고 인정한다. Git의 모든 오퍼레이션은 로컬에서 수행된다. 네트워크가 필요한 SVN과 Perforce이 뛸 때 날고 있는 셈이다. 게다가 Git은 로컬에서 명령을 수행하는 다른 DSCM과 비교해도 빠르다.
처음 개발할때 부터 리눅스 커널에 사용할 목적이 였기 때문에 규모가 큰 레파지토리일 수록 더욱 효과적이다. 게다가 Git은 C로 작성돼있어서 고수준 언어가 만들어내는 오버헤드도 없다. Git을 만든 선구자들은 '빠른 것'을 설계 목표중 하나로 삼았다.
나는 몇 가지 벤치마크 테스트를 진행했다. Git, Mercurial, Bazaar 이렇게 세가지 SCM에 각각 Django source code를 올려놓고 테스트를 했다. 나는 또한 SVN으로도 이 중 몇가지 테스트를 진행했다. 내가 장담컨데 SVN은 느리다. 기본적으로 Bazaar의 결과에 네트워크 레이턴시(Latency)를 더해야 한다.
init benchmarks add benchmarks status benchmarks diff benchmarks branching benchmarks
tag benchmarks log benchmarks large commit benchmarks small commit benchmarks
결론부터 말하자면 파일을 새로 추가하는 경우를 제외하면 Git은 항상 빠르다.(물론 정말정말 큰 데이터를 커밋하는 경우는 Hg가 제일 빠르다. 그러나 내가 테스트한 크기조차도 보통은 경험할 수 없다. 그러니까 대부분의 경우는 Git이 더 빠르다.)
Git Hg Bzr
Init 0.024s 0.059s 0.600s
Add 8.535s 0.368s 2.381s
Status 0.451s 1.946s 14.744s
Diff 0.543s 2.189s 14.248s
Tag 0.056s 1.201s 1.892s
Log 0.711s 2.650s 9.055s
Commit (Large) 12.480s 12.500s 23.002s
Commit (Small) 0.086s 0.517s 1.139s
Branch (Cold) 1.161s 94.681s 82.249s
Branch (Hot) 0.070s 12.300s 39.411s
The cold and hot branching numbers are the numbers for the first and second times that I branched a repo—the second number being a branch with a hot disk cache.
코드 브랜칭과 핫 브랜칭에 대한 결과는 내가 처음 브랜치를 만들 었을 때와 두번째 만들 었을 때를 의미한다. 핫 브랜칭은 핫 디스크 캐시를 이용한 것이다.
테스트 결과에서 'add'의 경우는 매우 느리다. 하지만 이 것은 파일 2000개가 넘는 경우에나 해당된다. 대부분의 사람들은 하루를 기준으로 일을 하는데 보통 'add'는 순식간에 이루어진다. 여기서 진행한 다른(라지 커밋은 제외한) 테스트 결과들은 우리가 날마다 실제로 하는 패턴들이다.
이 테스트를 재현하는 것은 어렵지 않다. 단순히 각 시스템마다 다음과 같은 명령어를 수행하여 Django 프로젝트의 클론을 만들면 된다.
  • git clone git://github.com/brosner/django.git dj-git
  • hg clone http://hg.dpaste.com/django/trunk dj-hg
  • bzr branch lp:django dj-bzr
  • svn checkout http://code.djangoproject.com/svn/django/trunk dj-svn
svn

Git은 작다.

Git은 디스크 공간을 적게 차지한다. Git 디렉토리는 일반적으로 SVN checkout한 것보다 별반 차이 없다. 어떤 경우에는 SVN의 것보다 작다(.svn 디렉토리에는 뭔가 무진장 많다는 것만은 분명이다.).
다음은 Django project의 클론에 대한 것이다. 동일한 버전을 기준으로 비공식(semi-official) Git 미러를 통해 만들었다.
Git Hg Bzr SVN
Repo Alone 24M 34M 45M
Entire Directory 43M 53M 64M 61M
hg bzr svn perforce

Staging 영역

다른 시스템과 달리 Git은 "staging area" 혹은 "index"라고 부르는 것이 있다. 커밋할 것 같은 파일을 넣고 관리하는 일종의 중간 영역이다.
staging area가 멋있는 점은 일을 끝내자 마자 쉽게 파일을 스테이지할 수 있고 커밋할 때 워킹 디렉토리에서 수정된 모든 파일을 커밋되지 않는다는 점이다. 또한 커밋할 때까지 명령어로 staging area를 관리할 수 있다.
add commit workflow diagram
우리는 수정한 파일의 일부만 스테이지할 수도 있다. 무언가 빼먹고 커밋하기 전에 논리적으로 무관한 파일을 걸러낼 필요가 없어졌다. 지금은 그냥 지금 커밋하는데 필요한 파일을 스테이지하고 다음 커밋에 필요한 다른 파일들은 다음에 스테이지한다. 이 기능은 그때 그때 상황에 맞추어 필요한 만큼 사용한다.
물론 Git은 이 기능을 건너 뛰는 방법도 제공한다. 커밋 명렁어에 '-a' 옵션을 추가하는 것만으로 쉽게 수정된 모든 파일이 스테이징 영역에 자동으로 추가된다.
commit only workflow diagram
svn perforce

분산

Git을 포함한 모든 분산 SCM의 가장 큰 특징은 당연히 분산된다는 점이다. 이 것은 최신 소스코드를 체크아웃하지 않고 레파지토리 전체를 복사하는 것(Clone)을 말한다.
잘 정리된 워크플로우 없이도 모든 사용자가 메인서버의 풀백업을 가질 수 있다. 그래서 메인서버에 문제가 생겼을때 누구나 메인서버에 푸시할 수 있다.
성능도 빠르다. 보통 SVN은 체크아웃에서만 다른 DSCM들보다 조금 빠르다. (적어도 내가 테스트해본) DSCM들 중에서는 Git이 가장 빠르다.
cloning benchmarks
Git 1m 59s
Hg 2m 24s
Bzr 5m 11s
SVN 1m 4s
svn perforce

워크플로우는 Git하기 나름

Git이 대단한 점은 또 있다. Git은 슈퍼 브랜칭 시스템이고 분산 생태계라는 점 때문에 우리가 생각할 수 있는 모든 워크플로우를 쉽게 구현할 수 있다.

Subversion-Style Workflow

매우 일반적으로 사용되는 Git 워크플로우로 중앙집중식centralized workflow이 있다. 특히 Subversion같은 중앙집중식 시스템를 사용하다가 넘어온 사람들이 사용한다. 내가 마지막으로 fecth한 후에 아무도 푸시하지 못하도록 할 수 있다. 그래서 모든 개발자가 같은 서버에 푸시하는 중앙집중식 모델도 가능하다.
subversion-style workflow

Integration Manager Workflow

또 자주 사용되는 워크플로우로 Integration Manager가 있는 유형이 있다. Integration Manager 한 사람만이 신성한 레파지토리(역자주- 메인 레파지토리)에 커밋할 수 있고 다른 개발자들은 그 레파지토리를 복제한다. 개발자들은 각자의 레파지토리에 커밋하고 관리자에게 자신의 코드를 풀(pull)하도록 요청한다. 이 것은 오픈소스나 GitHub 레파지토리에서 자주 사용되는 개발 모델이다.
integration manager workflow

Dictator and Lieutenants Workflow

Linux kernel 개발에서 사용하는 모델을 사용할 수 있다. 프로젝트의 특정한 서브시스템('lieutenants')을 담당하는 사람들은 그 서브시스템에서 일어나는 모든 변화를 관리한다. 'dictator'라고 부르는 또 다른 형태의 관리자는 자신의 'lieutenants'에서 발생한 수정내역을 가져다가 신성한 레파지토리에 다시 푸시한다. 그리고 모든 사람들은 이 신성한 레파지토리에서 다시 복제(Clone)한다. 이 것은 리눅스 커널같은 규모가 큰 프로젝트에서 사용된다.
dictator and lieutenants workflow

다시말해서 Git은 매우 유연하다. 이 워크플로우들 중에서 딱 맞는 것을 골라 쓸 수도 있고 섞어서 자신에게 적합한 워크플로우를 만들어 쓸 수도 있다.
hg svn perforce

GitHub

octocat
GitHub라는 단락을 추가한 것이 내가 GitHub에서 일하기 때문에 생긴 편견일 수도 있다. 그러나 너무나 많은 사람들이 Git을 선택한 이유로 GitHub를 들고 있기 때문에 추가했다.
GitHub는 많은 사람들이 Git을 사용하는 이유중 하나다. GitHub는 단순히 호스팅 사이트를 제공하는 것이 아니라 코드를 위한 소셜 네트워크를 제공한다. 사람들은 자신이 하고 있는 일과 유사한 개발자나 프로젝트를 찾는다. 그리고 Git이나 Git을 사용하는 프로젝트와 관련된 매우 활발한 커뮤니티를 만들어서 쉽게 프로젝트를 복제(fork)하거나 참여할(contribute) 수 있다.
Git과 다른 SCM을 모두 다루는 서비스들도 있지만 이렇게 사용자 중심이면서 소셜을 타깃으로 하는 서비스는 드문데다가 전적으로 사용자에 기반하는 시스템은 없다. GitHub가 소셜이라는 것은 정말 끈내준다. Git과 GitHub을 함께 사용하면 지금까지 설명한 것들이 잘 어우러져서 정말 오픈소스 프로젝트를 빠르게 개발할 수 있다.
다른 SCM에는 이런 형태의 커뮤니티가 없다.
perforce

Easy to Learn/배우기 쉽다

초창기 Git은 배우기 쉽지 않았다. 그때는 정말이지 분산 SCM을 할 수 있는 툴이 별로 없었다. 그러나 오늘날 Git의 learning curve는 다른 SCM들과 비슷할 뿐만 아니라 심지어 더 쉬운 경우도 있다.
객관적으로 증명하려면 연구라도 해야 하기 때문에 나는 Mercurial과 Git의 기본적인 'help' 메뉴의 차이를 비교 설명하려한다. 두 시스템이 가지고 있는 정말(혹은 거의) 똑같은 명령어는 다른색으로 표기했다. ('hg help'라고 명령어를 실행하면 40여 개의 명령어를 볼 수 있다.)

Mercurial Help

add        add the specified files ...
annotate   show changeset informati...
clone      make a copy of an existi...
commit     commit the specified fil...
diff       diff repository (or sele...
export     dump the header and diff...
init       create a new repository ...
log        show revision history of...
merge      merge working directory ...
parents    show the parents of the ...
pull       pull changes from the sp...
push       push changes to the spec...
remove     remove the specified fil...
serve      export the repository vi...
status     show changed files in th...
update     update working directory

Git Help

add        Add file contents to the index
bisect     Find the change that introduce...
branch     List, create, or delete branches
checkout   Checkout a branch or paths to ...
clone      Clone a repository into a new ...
commit     Record changes to the repository
diff       Show changes between commits, ...
fetch      Download objects and refs from...
grep       Print lines matching a pattern
init       Create an empty git repository
log        Show commit logs
merge      Join two or more development h...
mv         Move or rename a file, a direc...
pull       Fetch from and merge with anot...
push       Update remote refs along with ...
rebase     Forward-port local commits to ...
reset      Reset current HEAD to the spec...
rm         Remove files from the working ...
show       Show various types of objects
status     Show the working tree status
tag        Create, list, delete or verify...
Git 1.6 이전에, 모든 Git 명령어들은 각각의 실행 프로그램으로 돼있었다. 그래서 실행 경로에 등록하면(역자주 - 환경변수 'PATH') 사람들은 매우 헷갈려 했었다. Git은 그 명령어들을 아직도 가지고 있지만 이제는 'git'만 실행할 수 있으면 된다. 그래서 Mercurial과 Git을 보면 명령어들과 도움말이 서로 거의 동일하다. 요즘은 UI 관점에서 시작된 매우 작은 차이가 있을 뿐이다.
요즘은 Mercurial이나 Bazaar가 Git보다 배우기 쉽다고 주장하기 어렵다.
Expand all | Collapse all
이 사이트는 GitHubber인 Scott Chacon가 만들고 관리하고 있습니다.
만약 이 사이트가 마음에 들지 않을때 타당한 이유를 저에게 보내주시면 수정하겠습니다. 이 사이트의 소스는 GitHub에있습니다. 이 사이트에 개선할 것이 있으면 주저하지 말고 패치를 보내주세요. 이 사이트의 한글버전은 박창우가 하고 있습니다.
Also in : German, Spanish, French, Italian, Lolcat, Dutch, Norwegian, Portuguese, Swedish, Simplified and Traditional Chinese
Valid XHTML
\ No newline at end of file From 767657b375c4dc44150f670df1f9c26312a53edd Mon Sep 17 00:00:00 2001 From: Changwoo Park Date: Wed, 29 Jun 2011 11:53:25 +0800 Subject: [PATCH 4/5] changed newline, mac to unix --- index.html | 723 ++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 722 insertions(+), 1 deletion(-) diff --git a/index.html b/index.html index d7dd4ee..7f279b0 100644 --- a/index.html +++ b/index.html @@ -1 +1,722 @@ - Why Git is Better Than X

Why Git is Better than X

 where "x" is one of
최근 나는 슈퍼 울트라 극성주의자fanboyism, bandwagonism and koolaid-thirst들로부터 Gitster들을 옹호하는데 지쳐서 이 사이트를 만들었다. 나는 사람들이 왜 Git으로 갈아타는지를 정리했다. 클릭해보라.
모두 펴기 | 모두 숨기기
hg bzr svn perforce

값 싼 브랜칭

다른 SCM에 비해 Git의 가장 큰 특징은 아마도 브랜치 모델일 것이다. Git은 내가 여기서 비교하고자 하는 다른 모델들과는 완전히 다르다. 대부분이 권장하는 궁극의 브랜치는 새 디렉토리로 레파지토리를 통째로 복사하는 것이다.
하지만 Git은 그렇게 동작하지 않는다. Git에서는 여러 개의 로컬 브랜치를 가질수 있으며 그 로컬 브랜치들은 서로 완벽하게 독립적이기 때문에 개발 중 수행하는 생성, 머지, 삭제 명령도 독립적으로 수행된다.
Git으로는 다음과 같은 일들을 할 수 있다:
  • 아이디어를 실험하기 위해 브랜치를 만들고, 몇 번 커밋을 하고, 원래 것으로 돌아가, 패치를 적용한다. 다시 실험중인 브랜치로 돌아가 그것을 머지한다.
  • 제품으로 출시하기 위한 브랜치는 하나만 가질 수 있지만 그외 다른 목적의 브랜치는 마음것 만들 수 있다. 테스트나 일상적인 업무를 위한 브랜치를 만들어 작업하고 그 것을 머지한다.
  • 당신이 만들고 있는 이슈마다 브랜치를 새로 만들고 그 브랜치들 사이들 오가며 작업할 수 있다. 그리고 그 브랜치를 마스터 브랜치로 머지한 후에 그 브랜치들을 삭제한다.
  • 실험용 브랜치를 만들고 쓸모가 없으면 바로 삭제한다. (그 동안 다른 브랜치들을 푸시했었더라도) 실험은 버려졌기 때문에 아무도 모른다.
branches flowchart
중요한 것은 원격의 레파지토리에 푸시할 때 가지고 있는 브랜치 전부를 푸시하지 않는 점이다. 가지고 있는 브랜치들 중 하나만 공유할 수 있다. 그래서 사람들은 언제, 어떻게 브랜치를 머지하고 공유해야 할지에 대한 고민없이 쉽게 새로운 아이디어를 실험할 수 있다.
다른 시스템과 함께 Git을 사용할 방법이 있지만 매우 어렵고 에러나기 쉽다. Git을 배우면 이 과정이 매우 쉬워지고 일하는 방식도 변화한다.
jamis twitter trevorturk twitter thillerson twitter boblmartens twitter mathie twitter
svn perforce

역사는 로컬에서

이 것은 모든 분산 SCM에도 해당하는 이야기지만 나는 주로 Git을 많이 사용한다. Git은 외부 요소가 매우 적다. 내 하드디스크 세상 밖으로 소통하는 방법은 'fetch', 'pull', 'push'밖에 없다.
이 것은 우리가 해왔던 것 보다 모든 명령의 수행 속도를 빠르게 해줄뿐만 아니라 오프라인에서도 작업할 수 있도록 해준다. 실제로 아무것도 아닐 것 같지만 나는 내가 자주 오프라인으로 작업하고 있는 것을 발견하곤 항상 매우 놀란다. 비행기나 기차안에서도 오프라인으로 브랜치, 머지, 커밋하고 프로젝트의 히스토리를 살펴볼 수 있다는 것은 매우 생산적이다.
local repo to remote repo flowchart
심지어 Mercurial은 incoming과 outouing같은 명령어는 서버와 통신해야 한다. 하지만 Git은 서버에 있는 데이터를 로컬 브랜치로 fetch한다. fetch를 한 후에 오프라인으로도 서버에 있는 데이터와 비교, 머지, 로그 등의 일을 할 수 있다.
즉, Git 레파지토리에 있는 작업물들을 헝클지도 않으면서 나와 함께 일하는 동료들은 모두 자신만의 브랜치를 매우 쉽게 만들 수 있다.
bzr svn perforce

Git is Fast/Git은 빠르다

모두가 Git의 장점으로 'Git은 빠르다'라고 내세운다. 다른 SCM의 맹신자들도 Git이 빠르다고 인정한다. Git의 모든 오퍼레이션은 로컬에서 수행된다. 네트워크가 필요한 SVN과 Perforce이 뛸 때 날고 있는 셈이다. 게다가 Git은 로컬에서 명령을 수행하는 다른 DSCM과 비교해도 빠르다.
처음 개발할때 부터 리눅스 커널에 사용할 목적이 였기 때문에 규모가 큰 레파지토리일 수록 더욱 효과적이다. 게다가 Git은 C로 작성돼있어서 고수준 언어가 만들어내는 오버헤드도 없다. Git을 만든 선구자들은 '빠른 것'을 설계 목표중 하나로 삼았다.
나는 몇 가지 벤치마크 테스트를 진행했다. Git, Mercurial, Bazaar 이렇게 세가지 SCM에 각각 Django source code를 올려놓고 테스트를 했다. 나는 또한 SVN으로도 이 중 몇가지 테스트를 진행했다. 내가 장담컨데 SVN은 느리다. 기본적으로 Bazaar의 결과에 네트워크 레이턴시(Latency)를 더해야 한다.
init benchmarks add benchmarks status benchmarks diff benchmarks branching benchmarks
tag benchmarks log benchmarks large commit benchmarks small commit benchmarks
결론부터 말하자면 파일을 새로 추가하는 경우를 제외하면 Git은 항상 빠르다.(물론 정말정말 큰 데이터를 커밋하는 경우는 Hg가 제일 빠르다. 그러나 내가 테스트한 크기조차도 보통은 경험할 수 없다. 그러니까 대부분의 경우는 Git이 더 빠르다.)
Git Hg Bzr
Init 0.024s 0.059s 0.600s
Add 8.535s 0.368s 2.381s
Status 0.451s 1.946s 14.744s
Diff 0.543s 2.189s 14.248s
Tag 0.056s 1.201s 1.892s
Log 0.711s 2.650s 9.055s
Commit (Large) 12.480s 12.500s 23.002s
Commit (Small) 0.086s 0.517s 1.139s
Branch (Cold) 1.161s 94.681s 82.249s
Branch (Hot) 0.070s 12.300s 39.411s
The cold and hot branching numbers are the numbers for the first and second times that I branched a repo—the second number being a branch with a hot disk cache.
코드 브랜칭과 핫 브랜칭에 대한 결과는 내가 처음 브랜치를 만들 었을 때와 두번째 만들 었을 때를 의미한다. 핫 브랜칭은 핫 디스크 캐시를 이용한 것이다.
테스트 결과에서 'add'의 경우는 매우 느리다. 하지만 이 것은 파일 2000개가 넘는 경우에나 해당된다. 대부분의 사람들은 하루를 기준으로 일을 하는데 보통 'add'는 순식간에 이루어진다. 여기서 진행한 다른(라지 커밋은 제외한) 테스트 결과들은 우리가 날마다 실제로 하는 패턴들이다.
이 테스트를 재현하는 것은 어렵지 않다. 단순히 각 시스템마다 다음과 같은 명령어를 수행하여 Django 프로젝트의 클론을 만들면 된다.
  • git clone git://github.com/brosner/django.git dj-git
  • hg clone http://hg.dpaste.com/django/trunk dj-hg
  • bzr branch lp:django dj-bzr
  • svn checkout http://code.djangoproject.com/svn/django/trunk dj-svn
svn

Git은 작다.

Git은 디스크 공간을 적게 차지한다. Git 디렉토리는 일반적으로 SVN checkout한 것보다 별반 차이 없다. 어떤 경우에는 SVN의 것보다 작다(.svn 디렉토리에는 뭔가 무진장 많다는 것만은 분명이다.).
다음은 Django project의 클론에 대한 것이다. 동일한 버전을 기준으로 비공식(semi-official) Git 미러를 통해 만들었다.
Git Hg Bzr SVN
Repo Alone 24M 34M 45M
Entire Directory 43M 53M 64M 61M
hg bzr svn perforce

Staging 영역

다른 시스템과 달리 Git은 "staging area" 혹은 "index"라고 부르는 것이 있다. 커밋할 것 같은 파일을 넣고 관리하는 일종의 중간 영역이다.
staging area가 멋있는 점은 일을 끝내자 마자 쉽게 파일을 스테이지할 수 있고 커밋할 때 워킹 디렉토리에서 수정된 모든 파일을 커밋되지 않는다는 점이다. 또한 커밋할 때까지 명령어로 staging area를 관리할 수 있다.
add commit workflow diagram
우리는 수정한 파일의 일부만 스테이지할 수도 있다. 무언가 빼먹고 커밋하기 전에 논리적으로 무관한 파일을 걸러낼 필요가 없어졌다. 지금은 그냥 지금 커밋하는데 필요한 파일을 스테이지하고 다음 커밋에 필요한 다른 파일들은 다음에 스테이지한다. 이 기능은 그때 그때 상황에 맞추어 필요한 만큼 사용한다.
물론 Git은 이 기능을 건너 뛰는 방법도 제공한다. 커밋 명렁어에 '-a' 옵션을 추가하는 것만으로 쉽게 수정된 모든 파일이 스테이징 영역에 자동으로 추가된다.
commit only workflow diagram
svn perforce

분산

Git을 포함한 모든 분산 SCM의 가장 큰 특징은 당연히 분산된다는 점이다. 이 것은 최신 소스코드를 체크아웃하지 않고 레파지토리 전체를 복사하는 것(Clone)을 말한다.
잘 정리된 워크플로우 없이도 모든 사용자가 메인서버의 풀백업을 가질 수 있다. 그래서 메인서버에 문제가 생겼을때 누구나 메인서버에 푸시할 수 있다.
성능도 빠르다. 보통 SVN은 체크아웃에서만 다른 DSCM들보다 조금 빠르다. (적어도 내가 테스트해본) DSCM들 중에서는 Git이 가장 빠르다.
cloning benchmarks
Git 1m 59s
Hg 2m 24s
Bzr 5m 11s
SVN 1m 4s
svn perforce

워크플로우는 Git하기 나름

Git이 대단한 점은 또 있다. Git은 슈퍼 브랜칭 시스템이고 분산 생태계라는 점 때문에 우리가 생각할 수 있는 모든 워크플로우를 쉽게 구현할 수 있다.

Subversion-Style Workflow

매우 일반적으로 사용되는 Git 워크플로우로 중앙집중식centralized workflow이 있다. 특히 Subversion같은 중앙집중식 시스템를 사용하다가 넘어온 사람들이 사용한다. 내가 마지막으로 fecth한 후에 아무도 푸시하지 못하도록 할 수 있다. 그래서 모든 개발자가 같은 서버에 푸시하는 중앙집중식 모델도 가능하다.
subversion-style workflow

Integration Manager Workflow

또 자주 사용되는 워크플로우로 Integration Manager가 있는 유형이 있다. Integration Manager 한 사람만이 신성한 레파지토리(역자주- 메인 레파지토리)에 커밋할 수 있고 다른 개발자들은 그 레파지토리를 복제한다. 개발자들은 각자의 레파지토리에 커밋하고 관리자에게 자신의 코드를 풀(pull)하도록 요청한다. 이 것은 오픈소스나 GitHub 레파지토리에서 자주 사용되는 개발 모델이다.
integration manager workflow

Dictator and Lieutenants Workflow

Linux kernel 개발에서 사용하는 모델을 사용할 수 있다. 프로젝트의 특정한 서브시스템('lieutenants')을 담당하는 사람들은 그 서브시스템에서 일어나는 모든 변화를 관리한다. 'dictator'라고 부르는 또 다른 형태의 관리자는 자신의 'lieutenants'에서 발생한 수정내역을 가져다가 신성한 레파지토리에 다시 푸시한다. 그리고 모든 사람들은 이 신성한 레파지토리에서 다시 복제(Clone)한다. 이 것은 리눅스 커널같은 규모가 큰 프로젝트에서 사용된다.
dictator and lieutenants workflow

다시말해서 Git은 매우 유연하다. 이 워크플로우들 중에서 딱 맞는 것을 골라 쓸 수도 있고 섞어서 자신에게 적합한 워크플로우를 만들어 쓸 수도 있다.
hg svn perforce

GitHub

octocat
GitHub라는 단락을 추가한 것이 내가 GitHub에서 일하기 때문에 생긴 편견일 수도 있다. 그러나 너무나 많은 사람들이 Git을 선택한 이유로 GitHub를 들고 있기 때문에 추가했다.
GitHub는 많은 사람들이 Git을 사용하는 이유중 하나다. GitHub는 단순히 호스팅 사이트를 제공하는 것이 아니라 코드를 위한 소셜 네트워크를 제공한다. 사람들은 자신이 하고 있는 일과 유사한 개발자나 프로젝트를 찾는다. 그리고 Git이나 Git을 사용하는 프로젝트와 관련된 매우 활발한 커뮤니티를 만들어서 쉽게 프로젝트를 복제(fork)하거나 참여할(contribute) 수 있다.
Git과 다른 SCM을 모두 다루는 서비스들도 있지만 이렇게 사용자 중심이면서 소셜을 타깃으로 하는 서비스는 드문데다가 전적으로 사용자에 기반하는 시스템은 없다. GitHub가 소셜이라는 것은 정말 끈내준다. Git과 GitHub을 함께 사용하면 지금까지 설명한 것들이 잘 어우러져서 정말 오픈소스 프로젝트를 빠르게 개발할 수 있다.
다른 SCM에는 이런 형태의 커뮤니티가 없다.
perforce

Easy to Learn/배우기 쉽다

초창기 Git은 배우기 쉽지 않았다. 그때는 정말이지 분산 SCM을 할 수 있는 툴이 별로 없었다. 그러나 오늘날 Git의 learning curve는 다른 SCM들과 비슷할 뿐만 아니라 심지어 더 쉬운 경우도 있다.
객관적으로 증명하려면 연구라도 해야 하기 때문에 나는 Mercurial과 Git의 기본적인 'help' 메뉴의 차이를 비교 설명하려한다. 두 시스템이 가지고 있는 정말(혹은 거의) 똑같은 명령어는 다른색으로 표기했다. ('hg help'라고 명령어를 실행하면 40여 개의 명령어를 볼 수 있다.)

Mercurial Help

add        add the specified files ...
annotate   show changeset informati...
clone      make a copy of an existi...
commit     commit the specified fil...
diff       diff repository (or sele...
export     dump the header and diff...
init       create a new repository ...
log        show revision history of...
merge      merge working directory ...
parents    show the parents of the ...
pull       pull changes from the sp...
push       push changes to the spec...
remove     remove the specified fil...
serve      export the repository vi...
status     show changed files in th...
update     update working directory

Git Help

add        Add file contents to the index
bisect     Find the change that introduce...
branch     List, create, or delete branches
checkout   Checkout a branch or paths to ...
clone      Clone a repository into a new ...
commit     Record changes to the repository
diff       Show changes between commits, ...
fetch      Download objects and refs from...
grep       Print lines matching a pattern
init       Create an empty git repository
log        Show commit logs
merge      Join two or more development h...
mv         Move or rename a file, a direc...
pull       Fetch from and merge with anot...
push       Update remote refs along with ...
rebase     Forward-port local commits to ...
reset      Reset current HEAD to the spec...
rm         Remove files from the working ...
show       Show various types of objects
status     Show the working tree status
tag        Create, list, delete or verify...
Git 1.6 이전에, 모든 Git 명령어들은 각각의 실행 프로그램으로 돼있었다. 그래서 실행 경로에 등록하면(역자주 - 환경변수 'PATH') 사람들은 매우 헷갈려 했었다. Git은 그 명령어들을 아직도 가지고 있지만 이제는 'git'만 실행할 수 있으면 된다. 그래서 Mercurial과 Git을 보면 명령어들과 도움말이 서로 거의 동일하다. 요즘은 UI 관점에서 시작된 매우 작은 차이가 있을 뿐이다.
요즘은 Mercurial이나 Bazaar가 Git보다 배우기 쉽다고 주장하기 어렵다.
Expand all | Collapse all
이 사이트는 GitHubber인 Scott Chacon가 만들고 관리하고 있습니다.
만약 이 사이트가 마음에 들지 않을때 타당한 이유를 저에게 보내주시면 수정하겠습니다. 이 사이트의 소스는 GitHub에있습니다. 이 사이트에 개선할 것이 있으면 주저하지 말고 패치를 보내주세요. 이 사이트의 한글버전은 박창우가 하고 있습니다.
Also in : German, Spanish, French, Italian, Lolcat, Dutch, Norwegian, Portuguese, Swedish, Simplified and Traditional Chinese
Valid XHTML
\ No newline at end of file + + + + + + + Why Git is Better Than X + + + + + + + + + + + + +
+ +
+ + +
+

Why Git is Better than X

+ 		+ + where "x" is one of +
+
+ +
+
+ 최근 나는 슈퍼 울트라 극성주의자fanboyism, bandwagonism and koolaid-thirst들로부터 Gitster들을 옹호하는데 지쳐서 이 사이트를 만들었다. 나는 사람들이 왜 Git으로 갈아타는지를 정리했다. 클릭해보라. + +
+ +
+ 모두 펴기 | + 모두 숨기기 +
+
+ +
+
+ hg + bzr + svn + perforce +
+ +

+ 값 싼 브랜칭 +

+
+ +
+ 다른 SCM에 비해 Git의 가장 큰 특징은 아마도 브랜치 모델일 것이다. Git은 내가 여기서 비교하고자 하는 다른 모델들과는 완전히 다르다. 대부분이 권장하는 궁극의 브랜치는 새 디렉토리로 레파지토리를 통째로 복사하는 것이다. +
+ +
+ 하지만 Git은 그렇게 동작하지 않는다. Git에서는 여러 개의 로컬 브랜치를 가질수 있으며 그 로컬 브랜치들은 서로 완벽하게 독립적이기 때문에 개발 중 수행하는 생성, 머지, 삭제 명령도 독립적으로 수행된다. +
+ + +
+ Git으로는 다음과 같은 일들을 할 수 있다: +
    +
  • 아이디어를 실험하기 위해 브랜치를 만들고, 몇 번 커밋을 하고, 원래 것으로 돌아가, 패치를 적용한다. 다시 실험중인 브랜치로 돌아가 그것을 머지한다. +
    • +
  • 제품으로 출시하기 위한 브랜치는 하나만 가질 수 있지만 그외 다른 목적의 브랜치는 마음것 만들 수 있다. 테스트나 일상적인 업무를 위한 브랜치를 만들어 작업하고 그 것을 머지한다. +
    • +
  • 당신이 만들고 있는 이슈마다 브랜치를 새로 만들고 그 브랜치들 사이들 오가며 작업할 수 있다. 그리고 그 브랜치를 마스터 브랜치로 머지한 후에 그 브랜치들을 삭제한다. +
    • +
  • 실험용 브랜치를 만들고 쓸모가 없으면 바로 삭제한다. (그 동안 다른 브랜치들을 푸시했었더라도) 실험은 버려졌기 때문에 아무도 모른다. +
    • +
+
+ + branches flowchart + +
+ 중요한 것은 원격의 레파지토리에 푸시할 때 가지고 있는 브랜치 전부를 푸시하지 않는 점이다. 가지고 있는 브랜치들 중 하나만 공유할 수 있다. 그래서 사람들은 언제, 어떻게 브랜치를 머지하고 공유해야 할지에 대한 고민없이 쉽게 새로운 아이디어를 실험할 수 있다. +
+ +
+ 다른 시스템과 함께 Git을 사용할 방법이 있지만 매우 어렵고 에러나기 쉽다. Git을 배우면 이 과정이 매우 쉬워지고 일하는 방식도 변화한다. +
+ + + + +
+ jamis twitter + trevorturk twitter + thillerson twitter + boblmartens twitter + mathie twitter +
+
+
+ +
+
+ svn + perforce +
+

+ 역사는 로컬에서 +

+
+ +
+ 이 것은 모든 분산 SCM에도 해당하는 이야기지만 나는 주로 Git을 많이 사용한다. Git은 외부 요소가 매우 적다. 내 하드디스크 세상 밖으로 소통하는 방법은 'fetch', 'pull', 'push'밖에 없다. +
+ +
+ 이 것은 우리가 해왔던 것 보다 모든 명령의 수행 속도를 빠르게 해줄뿐만 아니라 오프라인에서도 작업할 수 있도록 해준다. 실제로 아무것도 아닐 것 같지만 나는 내가 자주 오프라인으로 작업하고 있는 것을 발견하곤 항상 매우 놀란다. 비행기나 기차안에서도 오프라인으로 브랜치, 머지, 커밋하고 프로젝트의 히스토리를 살펴볼 수 있다는 것은 매우 생산적이다. +
+ +
local repo to remote repo flowchart
+ +
+ 심지어 Mercurial은 incoming과 outouing같은 명령어는 서버와 통신해야 한다. 하지만 Git은 서버에 있는 데이터를 로컬 브랜치로 fetch한다. fetch를 한 후에 오프라인으로도 서버에 있는 데이터와 비교, 머지, 로그 등의 일을 할 수 있다. +
+ +
+ 즉, Git 레파지토리에 있는 작업물들을 헝클지도 않으면서 나와 함께 일하는 동료들은 모두 자신만의 브랜치를 매우 쉽게 만들 수 있다. +
+ +
+
+ +
+
+ bzr + svn + perforce +
+ +

+ Git is Fast/Git은 빠르다 +

+ +
+
+ 모두가 Git의 장점으로 'Git은 빠르다'라고 내세운다. 다른 SCM의 맹신자들도 Git이 빠르다고 인정한다. Git의 모든 오퍼레이션은 로컬에서 수행된다. 네트워크가 필요한 SVN과 Perforce이 뛸 때 날고 있는 셈이다. 게다가 Git은 로컬에서 명령을 수행하는 다른 DSCM과 비교해도 빠르다. +
+ +
+ 처음 개발할때 부터 리눅스 커널에 사용할 목적이 였기 때문에 규모가 큰 레파지토리일 수록 더욱 효과적이다. 게다가 Git은 C로 작성돼있어서 고수준 언어가 만들어내는 오버헤드도 없다. Git을 만든 선구자들은 '빠른 것'을 설계 목표중 하나로 삼았다. +
+ +
+ 나는 몇 가지 벤치마크 테스트를 진행했다. Git, Mercurial, Bazaar 이렇게 세가지 SCM에 각각 Django source code를 올려놓고 테스트를 했다. 나는 또한 SVN으로도 이 중 몇가지 테스트를 진행했다. 내가 장담컨데 SVN은 느리다. 기본적으로 Bazaar의 결과에 네트워크 레이턴시(Latency)를 더해야 한다. +
+ + + + +
+ init benchmarks + + add benchmarks + + status benchmarks + + diff benchmarks + + branching benchmarks +
+ tag benchmarks + + log benchmarks + + large commit benchmarks + + small commit benchmarks +
+ +
+ 결론부터 말하자면 파일을 새로 추가하는 경우를 제외하면 Git은 항상 빠르다.(물론 정말정말 큰 데이터를 커밋하는 경우는 Hg가 제일 빠르다. 그러나 내가 테스트한 크기조차도 보통은 경험할 수 없다. 그러니까 대부분의 경우는 Git이 더 빠르다.) +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
GitHgBzr
Init0.024s0.059s0.600s
Add8.535s0.368s2.381s
Status0.451s1.946s14.744s
Diff0.543s2.189s14.248s
Tag0.056s1.201s1.892s
Log0.711s2.650s9.055s
Commit (Large)12.480s12.500s23.002s
Commit (Small)0.086s0.517s1.139s
Branch (Cold)1.161s94.681s82.249s
Branch (Hot)0.070s12.300s39.411s
+ +
+ The cold and hot branching numbers are the numbers for the first + and second times that I branched a repo—the second number being + a branch with a hot disk cache. +
+ 코드 브랜칭과 핫 브랜칭에 대한 결과는 내가 처음 브랜치를 만들 었을 때와 두번째 만들 었을 때를 의미한다. 핫 브랜칭은 핫 디스크 캐시를 이용한 것이다. +
+ +
+
+ 테스트 결과에서 'add'의 경우는 매우 느리다. 하지만 이 것은 파일 2000개가 넘는 경우에나 해당된다. 대부분의 사람들은 하루를 기준으로 일을 하는데 보통 'add'는 순식간에 이루어진다. 여기서 진행한 다른(라지 커밋은 제외한) 테스트 결과들은 우리가 날마다 실제로 하는 패턴들이다. +
+ + +
+ 이 테스트를 재현하는 것은 어렵지 않다. 단순히 각 시스템마다 다음과 같은 명령어를 수행하여 Django 프로젝트의 클론을 만들면 된다. +
    +
  • git clone git://github.com/brosner/django.git dj-git
    • +
  • hg clone http://hg.dpaste.com/django/trunk dj-hg
    • +
  • bzr branch lp:django dj-bzr
    • +
  • svn checkout http://code.djangoproject.com/svn/django/trunk dj-svn
    • +
+
+ +
+ + +
+ +
+
+ svn +
+ +

+ Git은 작다. +

+ +
+
+ Git은 디스크 공간을 적게 차지한다. Git 디렉토리는 일반적으로 SVN checkout한 것보다 별반 차이 없다. 어떤 경우에는 SVN의 것보다 작다(.svn 디렉토리에는 뭔가 무진장 많다는 것만은 분명이다.). +
+ +
+ 다음은 Django project의 클론에 대한 것이다. 동일한 버전을 기준으로 비공식(semi-official) Git 미러를 통해 만들었다. +
+ + + + + + + + + + + + + + + + + + + + + + + +
GitHgBzrSVN
Repo Alone24M34M45M
Entire Directory43M53M64M61M
+ +
+
+ +
+
+ hg + bzr + svn + perforce +
+ +

+ Staging 영역 +

+
+
+ 다른 시스템과 달리 Git은 "staging area" 혹은 "index"라고 부르는 것이 있다. 커밋할 것 같은 파일을 넣고 관리하는 일종의 중간 영역이다. +
+
+ staging area가 멋있는 점은 일을 끝내자 마자 쉽게 파일을 스테이지할 수 있고 커밋할 때 워킹 디렉토리에서 수정된 모든 파일을 커밋되지 않는다는 점이다. 또한 커밋할 때까지 명령어로 staging area를 관리할 수 있다. +
+
add commit workflow diagram
+ +
+ 우리는 수정한 파일의 일부만 스테이지할 수도 있다. 무언가 빼먹고 커밋하기 전에 논리적으로 무관한 파일을 걸러낼 필요가 없어졌다. 지금은 그냥 지금 커밋하는데 필요한 파일을 스테이지하고 다음 커밋에 필요한 다른 파일들은 다음에 스테이지한다. 이 기능은 그때 그때 상황에 맞추어 필요한 만큼 사용한다. +
+ +
+ 물론 Git은 이 기능을 건너 뛰는 방법도 제공한다. 커밋 명렁어에 '-a' 옵션을 추가하는 것만으로 쉽게 수정된 모든 파일이 스테이징 영역에 자동으로 추가된다. +
+ +
commit only workflow diagram
+
+
+ +
+
+ svn + perforce +
+ +

+ 분산 +

+ +
+ +
+ Git을 포함한 모든 분산 SCM의 가장 큰 특징은 당연히 분산된다는 점이다. 이 것은 최신 소스코드를 체크아웃하지 않고 레파지토리 전체를 복사하는 것(Clone)을 말한다. +
+
+ 잘 정리된 워크플로우 없이도 모든 사용자가 메인서버의 풀백업을 가질 수 있다. 그래서 메인서버에 문제가 생겼을때 누구나 메인서버에 푸시할 수 있다. +
+ +
+ 성능도 빠르다. 보통 SVN은 체크아웃에서만 다른 DSCM들보다 조금 빠르다. (적어도 내가 테스트해본) DSCM들 중에서는 Git이 가장 빠르다. +
+ + + +
+ cloning benchmarks + + + + + + + + + + + + + + + + + + +
Git1m 59s
Hg2m 24s
Bzr5m 11s
SVN1m 4s
+
+ +
+
+ + +
+
+ svn + perforce +
+ +

+ 워크플로우는 Git하기 나름 +

+
+ +
+ Git이 대단한 점은 또 있다. Git은 슈퍼 브랜칭 시스템이고 분산 생태계라는 점 때문에 우리가 생각할 수 있는 모든 워크플로우를 쉽게 구현할 수 있다. +
+ +

Subversion-Style Workflow

+ + +
+ 매우 일반적으로 사용되는 Git 워크플로우로 중앙집중식centralized workflow이 있다. 특히 Subversion같은 중앙집중식 시스템를 사용하다가 넘어온 사람들이 사용한다. 내가 마지막으로 fecth한 후에 아무도 푸시하지 못하도록 할 수 있다. 그래서 모든 개발자가 같은 서버에 푸시하는 중앙집중식 모델도 가능하다. +
+ +
subversion-style workflow

+ +

Integration Manager Workflow

+ +
+ 또 자주 사용되는 워크플로우로 Integration Manager가 있는 유형이 있다. Integration Manager 한 사람만이 신성한 레파지토리(역자주- 메인 레파지토리)에 커밋할 수 있고 다른 개발자들은 그 레파지토리를 복제한다. 개발자들은 각자의 레파지토리에 커밋하고 관리자에게 자신의 코드를 풀(pull)하도록 요청한다. 이 것은 오픈소스나 GitHub 레파지토리에서 자주 사용되는 개발 모델이다. +
+ +
integration manager workflow

+ +

Dictator and Lieutenants Workflow

+ +
+ Linux kernel 개발에서 사용하는 모델을 사용할 수 있다. 프로젝트의 특정한 서브시스템('lieutenants')을 담당하는 사람들은 그 서브시스템에서 일어나는 모든 변화를 관리한다. 'dictator'라고 부르는 또 다른 형태의 관리자는 자신의 'lieutenants'에서 발생한 수정내역을 가져다가 신성한 레파지토리에 다시 푸시한다. 그리고 모든 사람들은 이 신성한 레파지토리에서 다시 복제(Clone)한다. 이 것은 리눅스 커널같은 규모가 큰 프로젝트에서 사용된다. +
+ +
dictator and lieutenants workflow

+ +
+ 다시말해서 Git은 매우 유연하다. 이 워크플로우들 중에서 딱 맞는 것을 골라 쓸 수도 있고 섞어서 자신에게 적합한 워크플로우를 만들어 쓸 수도 있다. +
+ +
+
+ + +
+
+ hg + svn + perforce +
+ +

+ GitHub +

+ +
+ + octocat + +
+ GitHub라는 단락을 추가한 것이 내가 GitHub에서 일하기 때문에 생긴 편견일 수도 있다. 그러나 너무나 많은 사람들이 Git을 선택한 이유로 GitHub를 들고 있기 때문에 추가했다. +
+ +
+ GitHub는 많은 사람들이 Git을 사용하는 이유중 하나다. GitHub는 단순히 호스팅 사이트를 제공하는 것이 아니라 코드를 위한 소셜 네트워크를 제공한다. 사람들은 자신이 하고 있는 일과 유사한 개발자나 프로젝트를 찾는다. 그리고 Git이나 Git을 사용하는 프로젝트와 관련된 매우 활발한 커뮤니티를 만들어서 쉽게 프로젝트를 복제(fork)하거나 참여할(contribute) 수 있다. +
+ +
+ Git과 다른 SCM을 모두 다루는 서비스들도 있지만 이렇게 사용자 중심이면서 소셜을 타깃으로 하는 서비스는 드문데다가 전적으로 사용자에 기반하는 시스템은 없다. GitHub가 소셜이라는 것은 정말 끈내준다. Git과 GitHub을 함께 사용하면 지금까지 설명한 것들이 잘 어우러져서 정말 오픈소스 프로젝트를 빠르게 개발할 수 있다. +
+ +
+ 다른 SCM에는 이런 형태의 커뮤니티가 없다. +
+ +
+
+ + + + + + + +
+
+ perforce +
+ +

+ Easy to Learn/배우기 쉽다 +

+ +
+
+ 초창기 Git은 배우기 쉽지 않았다. 그때는 정말이지 분산 SCM을 할 수 있는 툴이 별로 없었다. 그러나 오늘날 Git의 learning curve는 다른 SCM들과 비슷할 뿐만 아니라 심지어 더 쉬운 경우도 있다. +
+ +
+ 객관적으로 증명하려면 연구라도 해야 하기 때문에 나는 Mercurial과 Git의 기본적인 'help' 메뉴의 차이를 비교 설명하려한다. 두 시스템이 가지고 있는 정말(혹은 거의) 똑같은 명령어는 다른색으로 표기했다. ('hg help'라고 명령어를 실행하면 40여 개의 명령어를 볼 수 있다.) +
+ + + +
+ +

Mercurial Help

+
+add        add the specified files ...
+annotate   show changeset informati...
+clone      make a copy of an existi...
+commit     commit the specified fil...
+diff       diff repository (or sele...
+export     dump the header and diff...
+init       create a new repository ...
+log        show revision history of...
+merge      merge working directory ...
+parents    show the parents of the ...
+pull       pull changes from the sp...
+push       push changes to the spec...
+remove     remove the specified fil...
+serve      export the repository vi...
+status     show changed files in th...
+update     update working directory
+
+ + 		+ +

Git Help

+
+add        Add file contents to the index
+bisect     Find the change that introduce...
+branch     List, create, or delete branches
+checkout   Checkout a branch or paths to ...
+clone      Clone a repository into a new ...
+commit     Record changes to the repository
+diff       Show changes between commits, ...
+fetch      Download objects and refs from...
+grep       Print lines matching a pattern
+init       Create an empty git repository
+log        Show commit logs
+merge      Join two or more development h...
+mv         Move or rename a file, a direc...
+pull       Fetch from and merge with anot...
+push       Update remote refs along with ...
+rebase     Forward-port local commits to ...
+reset      Reset current HEAD to the spec...
+rm         Remove files from the working ...
+show       Show various types of objects
+status     Show the working tree status
+tag        Create, list, delete or verify...
+
+
+ +
+ Git 1.6 이전에, 모든 Git 명령어들은 각각의 실행 프로그램으로 돼있었다. 그래서 실행 경로에 등록하면(역자주 - 환경변수 'PATH') 사람들은 매우 헷갈려 했었다. Git은 그 명령어들을 아직도 가지고 있지만 이제는 'git'만 실행할 수 있으면 된다. 그래서 Mercurial과 Git을 보면 명령어들과 도움말이 서로 거의 동일하다. 요즘은 UI 관점에서 시작된 매우 작은 차이가 있을 뿐이다. +
+ +
+ 요즘은 Mercurial이나 Bazaar가 Git보다 배우기 쉽다고 주장하기 어렵다. +
+ +
+ +
+ + + + +
+
+ Expand all | + Collapse all +
+
+ +
+ 이 사이트는 GitHubber인 Scott Chacon가 만들고 관리하고 있습니다.
+ + 만약 이 사이트가 마음에 들지 않을때 타당한 이유를 저에게 보내주시면 수정하겠습니다. + + 이 사이트의 소스는 GitHub에있습니다. 이 사이트에 개선할 것이 있으면 주저하지 말고 패치를 보내주세요. + + 이 사이트의 한글버전은 박창우가 하고 있습니다. +
+ +
+ Also in : + German, + Spanish, + French, + Italian, + Lolcat, + Dutch, + Norwegian, + Portuguese, + Swedish, + Simplified and + Traditional Chinese +
+ +
+ Valid XHTML +
+
+ + + + + + + + From 08e3f72c10844d6040c1947ba769896da3321c49 Mon Sep 17 00:00:00 2001 From: Changwoo Park Date: Fri, 11 Nov 2011 22:18:07 +0900 Subject: [PATCH 5/5] [ko] typing correction --- index.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/index.html b/index.html index 7f279b0..366c082 100644 --- a/index.html +++ b/index.html @@ -182,7 +182,7 @@

- Git is Fast/Git은 빠르다 + Git은 빠르다

@@ -551,7 +551,7 @@

- Easy to Learn/배우기 쉽다 + 배우기 쉽다