diff --git a/index.html b/index.html index 12d19aa..fd414e0 100644 --- a/index.html +++ b/index.html @@ -5,7 +5,7 @@ - Why Git is Better Than X + Почему Git лучше чем X @@ -59,7 +59,7 @@
-

Why Git is Better than X

+

Почему Git лучше чем X

- 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, которая ставит его в сторону + по сравнению почти со всеми остальными системами управлением версиями, + это модель ветвления. Она полностью отличается от всех моделей, + сравниваемых здесь, большинство из которых рекомендуют, + что лучшая ветка, это копия репозитория в новом каталоге.
- 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: + Это означает что вы можете:
    -
  • 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) +
  • Создать ветку для экспериментов, понять, что это не будет работать + и просто удалить ветку—и никто другой это не увидит + (даже если вы в это время выложили другие ветки).
@@ -141,18 +142,18 @@

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 делает этот процесс невероятно простым и освоив его, + разработчик меняет свой подход к работе.
@@ -174,40 +175,38 @@

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. + В основном это верно для всех распределённых систем управления версиями, + но по моему опыту, ещё более для 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' и 'outgoing' взаимодействуют с сервером, + в то время как с Git вы можете получить (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. + Это значит, что очень просто иметь копии не только ваших веток, + но и ветки всех, кто с вами работает в одном репозитории, без беспорядка в ваших материалах.
@@ -221,34 +220,29 @@

- 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 все операции выполняются локально, что даёт ему фору перед SVN и Perforce, + обеим из которых требуется подключение к сети для определенных операций. + Так или иначе, даже сравнивая с распределенными СУВ, которые выполняют операции локально, Git довольно быстр.
- 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 создавался для работы над ядром Linux, + а значит, что нужно было справляться с большими репозиториями с первого дня. + Как дополнение, 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... + Ниже приводится ряд тестов, которые я выполнил с тремя копиями исходного кода проекта Django + в трёх различных СУВ: Git, Mercurial и Bazaar. + Также я протестировал кое-что из этого в SVN, но поверьте мне, она медленнее— + возьмите показатели Bazaar и добавьте к ним задержки сети...
@@ -275,10 +269,11 @@

- 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 намного быстрее). +
@@ -289,61 +284,61 @@

- + - + - + - + - + - + - + - + - + - + @@ -351,24 +346,21 @@

Bzr
InitInit (Создание репозитория) 0.024s 0.059s 0.600s
AddAdd (Добавление) 8.535s 0.368s 2.381s
StatusStatus (Состояние) 0.451s 1.946s 14.744s
DiffDiff (Отличия) 0.543s 2.189s 14.248s
TagTag (Метка) 0.056s 1.201s 1.892s
LogLog (История) 0.711s 2.650s 9.055s
Commit (Large)Commit (Большой коммит) 12.480s 12.500s 23.002s
Commit (Small)Commit (Маленький коммит) 0.086s 0.517s 1.139s
Branch (Cold)Branch (Холодное) 1.161s 94.681s 82.249s
Branch (Hot)Branch (Горячее) 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 файлов. Для большинства повседневных задач, операции добавления + во всех этих системах займут доли секунды. Все другие операции из теста + (возможно кроме большого коммита) лучше отражают то, что вы будете делать день ото дня.
- 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
    • @@ -388,20 +380,19 @@

- 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— + в некоторых случаях даже меньше (очевидно, много места занимают папки .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 в каждом из его + полуофициальных Git зеркал, с одинакой точки в истории.
@@ -413,14 +404,14 @@

- + - + @@ -440,36 +431,33 @@

- 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 + Что классного в области подготовленных файлов и что отличает Git от других систем— + это возможность просто подготовить некоторые файлы, как только вы завершили работу с ними, + а затем выполнить коммит только этих файлов, а не всех измененных файлов в рабочей директории + при этом не понадобится перечислять все эти файлы во время коммита.
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. + Это также позволяет подготавливать только части измененного файла. Больше не будет так, + что вы сделали 2 несвязанных изменения и забыли отдельно сделать коммит одного из них. + Теперь можно подготовить нужное вам изменение для текущего коммита, + а другое изменение подготовить для следующего коммита. Эта возможность масштабируется + до любого количества различных изменений, которое вам потребуется.
- 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 также легко позволяет игнорировать эту возможность и позволяет добавить все изменения + во всех файлах в область подготовленных файлов.
commit only workflow diagram
@@ -483,32 +471,32 @@

- 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. -
+
+ Одна из лучших возможностей всех распределённых СУВ, включая Git, это распределённость. + Это значит, что вместо получения (checkout) текущего последнего состояния исходников, + вы получаете копию (clone) всего хранилища. +
+
+ Получается, что если даже вы будете использовать централизованный техпроцесс, + каждый пользователь будет иметь полный бэкап репозитория главного сервера, + который может легко заменить центральный репозиторий в случае его повреждения. + В Git нет единой точки отказа, если только репозиторий не один. +
+ +
+ Распределённость не сильно-то и замедляет работу. + В среднем, один checkout из SVN лишь немного быстрее, чем из любой распределённой системы управления версиями. + Из протестированных РСУВ Git был наибыстрейшим. +
SVN
Repo AloneТолько хранилище 24M 34M 45M
Entire DirectoryВся папка 43M 53M 64M
- cloning benchmarks + cloning benchmarks @@ -542,60 +530,57 @@

- 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. + 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 весьма распространен централизованный рабочий процесс, + особенно среди людей, переходящих с централизованных систем. + Git не позволит вам выкладывать изменения (push), если кто-то выложил свои + с момента последнего получения вами данных с сервера (fetch). Таким образом, + централизованная модель, в которой все разработчики выгружают на один и тот же сервер, работает на ура.
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. + Другая распространенная модель работы с Git—когда есть менеджер интеграций, + один человек, который коммитит в "священный" репозиторий, + а затем несколько разработчиков клонируют, выгружают в свои собственные независимые репозитории + и просят интегратора принять (pull) их изменения. Эту модель разработки вы часто можете видеть + в проектах с открытыми исходными кодами или в репозитариях GitHub.
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. + Для более массивных проектов вы можете организовать своих разработчиков так, + как работают разработчики ядра Linux. В этой модели есть люди, ответственные + за отдельные подсистемы проекта (менеджеры по интеграции), и собирающие (merge) все изменения, + которые необходимо делать в этой подсистеме. Затем, другой человек, (интегратор или "диктатор") может забирать + изменения (pull) только от своих менеджеров, и выгружать (push) их в "священный" репозиторий, + который затем снова клонируют все остальные.
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 совершенно гибок, поэтому вы можете + комбинировать и выбирать модели работы, которые подходят вам.
@@ -618,33 +603,30 @@

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, + но я всё равно добавил этот раздел, потому многие говорят, + что выбрали 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 для многих людей, поскольку он больше + похож на социальную сеть для кода, чем на простой хостинг. Люди находят + других разработчиков или проекты, похожие на то, что они делают сами, + и могут легко вносить вклад и заимствовать код, создавая очень живое + сообщество вокруг Git и проектов, где им пользуются.
-
- 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, так и для других СУВ, но из них лишь несколько + удобны для пользователя или социально направлены, и ни у одного из них нет подобного + круга пользователей. Этот социальный аспект GitHub — отличная приманка, и в сочетании + с вышеперечисленными возможностями, делает Git и GitHub отличным сочетанием для + быстро развивающихся проектов с открытыми исходными кодами.
- This type of community is simply not available with any of the other SCMs. -
+ Подобный тип сообщества просто не существует для других систем управления версиями. +
@@ -666,90 +648,86 @@

- 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 была не полноценной системой управления версиями, + а скорее кучей различных утилит, позволявших реализовать работу распределенной СУВ. + Однако сегодня набор команд и скорость освоения Git очень близки к любой + СУВ, и даже лучше чем у некоторых.
-
- 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.) +
+ Поскольку это трудно объективно доказать без некоторого изучения, я просто покажу + разницу в меню 'help' по командам Mercurial и Git. Я выделил команды, которые + одинаковы (или почти) в этих системах. (В Mercurial если вы наберете + 'hg help', то получите список из примерно 40 команд.)
-

Mercurial Help

+

Справка Mercurial

-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
+add        добавить указанные файлы...
+annotate   показать информацию об изменении...
+clone      создать копию существую...
+commit     коммитить указанные файлы...
+diff       показать разницу репозитория (или...
+export     вывести заголовок и измене...
+init       создать новый репозиторий...
+log        показать историю ревизий...
+merge      слияние рабочих каталогов...
+parents    показать родительские...
+pull       загрузить изменения с указ...
+push       отправить изменения на ук...
+remove     удаление указанного фай...
+serve      экспортировать хранилище в...
+status     показать измененные файлы в ...
+update     обновить рабочую директорию
-

Git Help

+

Справка Git

-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...
+add        добавить содержимое файла в индекс
+bisect     ищет изменения, которые приводя...
+branch     Просмотр списка, создание, или удаление веток
+checkout   Получить ветку или пути...
+clone      клонирует хранилище в новую ...
+commit     записывает изменения в хранилище
+diff       показывает различия между фиксациями, ...
+fetch      Скачать объекты и ссылки из...
+grep       Вывод строк совпавших с шаблоном
+init       Создание пустого хранилища
+log        просмотр журнала фиксаций
+merge      объединяет две, или больше, разрабатываемых ве...
+mv         Перемещение или переименование файла, катал...
+pull       Взять ветку и слить с другой.
+push       Обновить удалённые ссылки вместе с...
+rebase     Отправить местные коммиты на...
+reset      сброс текущего HEAD на указ...
+rm         Удалить файлы из рабочего ...
+show       Показать различные типы объектов
+status     Показать состояние рабочей папки
+tag        Создать, вывести, удалить или проверить...
-
- 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 были исполняемыми программами, что + создавало много путаницы. Git всё ещё понимает все эти команды, но теперь + единственная исполняемая команда — это 'git'. Так что если сравнить + Mercurial и Git, у Git почти идентичная система команд и справки и есть + лишь небольшая разница на начальном этапе с точки зрения пользовательского интерфейса.
-
- These days it's pretty hard to argue that Mercurial or Bazaar is any - easier to learn than Git is. +
+ В наши дни уже довольно сложно утверждать, что изучить Mercurial или Bazaar легче, чем Git.
@@ -765,24 +743,24 @@

Git Help

- 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.
+ Данный сайт разработан и поддерживается Скоттом Чаконом (Scott Chacon), пользователем + GitHub.
+ Перевод на русский язык выполнил Дмитрий Вольф.
+ Если вы несогласны с чем-либо на этом сайте и у вас есть веские основания, пожалуйста + напишите мне, чтобы я мог это исправить.
- The source for this site is on GitHub—feel - free to send patches if you want to improve it.
+ Исходные материалы данного сайта доступны на GitHub—не стесняйтесь, присылайте патчи, если желаете его улучшить.
- Also in : + Also in : + English, German, Spanish, French, diff --git a/scripts/upload.sh b/scripts/upload.sh index 1d2f189..c826648 100755 --- a/scripts/upload.sh +++ b/scripts/upload.sh @@ -1,2 +1,2 @@ # this script moves the files to my server -rsync -e ssh -av * whygitisbetterthanx.com:/u/apps/whygit/ +rsync -e ssh -av * whygitisbetterthanx.com:/u/apps/whygit-ru/