Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Пераклад раздзелу 1 #5

Open
wants to merge 7 commits into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
90 changes: 45 additions & 45 deletions book/01-introduction/sections/about-version-control.asc
Original file line number Diff line number Diff line change
@@ -1,61 +1,61 @@
=== About Version Control
=== Аб сістэме кантролю версій

(((version control)))
What is "`version control`", and why should you care?
Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later.
For the examples in this book, you will use software source code as the files being version controlled, though in reality you can do this with nearly any type of file on a computer.
(((кантроль версій)))
Што такое «сістэма кантролю версій» і чаму гэта важна?
Сістэма кантролю версій -- гэта сістэма, якая запісвае змены ў файл або набор файлаў на працягу часу і якая дазваляе вярнуцца пазней да пэўнай версіі.
Для кантролю версій файлаў у гэтай кнізе ў якасці прыкладу будзе выкарыстоўвацца зыходны код праграмнага забеспячэння, хоць на самай справе вы можаце выкарыстоўваць кантроль версій амаль што для любых тыпаў файлаў.

If you are a graphic or web designer and want to keep every version of an image or layout (which you would most certainly want to), a Version Control System (VCS) is a very wise thing to use.
It allows you to revert selected files back to a previous state, revert the entire project back to a previous state, compare changes over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more.
Using a VCS also generally means that if you screw things up or lose files, you can easily recover.
In addition, you get all this for very little overhead.
Калі вы графічны або web-дызайнер і хочаце захаваць кожную версію малюнка або макета (хутчэй за ўсё, захочаце), сістэма кантролю версій (далей СКВ) -- як раз тое, што трэба.
Яна дазваляе вярнуць файлы да стану, у якім яны былі да зменаў, вярнуць праект да зыходнага стану, убачыць змены, убачыць хто апошні нешта мяняў і выклікаў праблему, хто паставіў задачу і калі, а так сама многае іншае.
Выкарыстанне СКВ таксама значыць, што вы спакойна можаце ўсё выправіць калі страцілі файлы ці нешта зламалі.
У дадатак да ўсяго, вы атрымаеце ўсё гэта без якіх-небудзь дадатковых намаганняў.

==== Local Version Control Systems
==== Лакальныя сістэмы кантролю версій

(((version control,local)))
Many people's version-control method of choice is to copy files into another directory (perhaps a time-stamped directory, if they're clever).
This approach is very common because it is so simple, but it is also incredibly error prone.
It is easy to forget which directory you're in and accidentally write to the wrong file or copy over files you don't mean to.
(((кантроль версій,лакальны)))
Многія людзі ў якасці метаду кантролю версій ўжываюць капіраванне файлаў у асобны каталог (магчыма нават, каталог з адзнакай па часе, калі яны дастаткова кемлівыя).
Дадзены падыход вельмі распаўсюджаны з-за яго прастаты, аднак ён неверагодна моцна схільны з'яўленню памылак.
Можна лёгка забыцца у якім каталогу вы знаходзіцеся і выпадкова змяніць не той файл або скапіяваць не тыя файлы, якія вы хацелі.

To deal with this issue, programmers long ago developed local VCSs that had a simple database that kept all the changes to files under revision control.
Для таго, каб вырашыць гэтую праблему, праграмісты даўным-даўно распрацавалі лакальныя СКВ з простай базай дадзеных, якая захоўвае запісы аб усіх зменах у файлах, ажыццяўляючы тым самым кантроль рэвізій.

.Local version control
image::images/local.png[Local version control diagram]
.Лакальны кантроль версій
image::images/local.png["Дыяграма лакальнага кантролю версій"]

One of the most popular VCS tools was a system called RCS, which is still distributed with many computers today.
https://www.gnu.org/software/rcs/[RCS] works by keeping patch sets (that is, the differences between files) in a special format on disk; it can then re-create what any file looked like at any point in time by adding up all the patches.
Адной з папулярных СКВ была сістэма RCS, якая і сёння распаўсюджваецца з многімі кампутарамі.
https://www.gnu.org/software/rcs/[RCS] захоўвае на дыску наборы патчаў (адрозненняў паміж файламі) у спэцыяльным фармаце, ужываючы якія яна можа аднаўляць стан кожнага файла ў зададзены момант часу.

==== Centralized Version Control Systems
==== Цэнтралізаваныя сістэмы кантролю версій

(((version control,centralized)))
The next major issue that people encounter is that they need to collaborate with developers on other systems.
To deal with this problem, Centralized Version Control Systems (CVCSs) were developed.
These systems (such as CVS, Subversion, and Perforce) have a single server that contains all the versioned files, and a number of clients that check out files from that central place. (((CVS)))(((Subversion)))(((Perforce)))
For many years, this has been the standard for version control.
(((кантроль версій,цэнтралізаваны)))
Наступная сур'ёзная праблема, з якой сутыкаюцца людзі, -- гэта неабходнасць ўзаемадзейнічаць з іншымі распрацоўшчыкамі.
Для таго, каб разабрацца з ёй, былі распрацаваны цэнтралізаваныя сістэмы кантролю версій (ЦСКВ).
Такія сістэмы, як CVS, Subversion і Perforce, выкарыстоўваюць адзіны сервер, які змяшчае ўсе версіі файлаў, і некаторую колькасць кліентаў, якія атрымліваюць файлы з гэтага цэнтралізаванага сховішча. (((CVS)))(((Subversion)))(((Perforce)))
Прымяненне ЦСКВ з'яўлялася стандартам на працягу многіх гадоў.

.Centralized version control
image::images/centralized.png[Centralized version control diagram]
.Цэнтралізаваны кантроль версій
image::images/centralized.png["Дыяграма цэнтралізаванага кантролю версій"]

This setup offers many advantages, especially over local VCSs.
For example, everyone knows to a certain degree what everyone else on the project is doing.
Administrators have fine-grained control over who can do what, and it's far easier to administer a CVCS than it is to deal with local databases on every client.
Такі падыход мае мноства пераваг, асабліва перад лакальнымі СКВ.
Напрыклад, усе распрацоўшчыкі праекта ў пэўнай ступені ведаюць, чым займаецца кожны з іх.
Адміністратары маюць поўны кантроль над тым, хто і што можа рабіць, і значна прасцей адміністраваць ЦСКВ, чым апераваць лакальнымі базамі дадзеных на кожным кліенце.

However, this setup also has some serious downsides.
The most obvious is the single point of failure that the centralized server represents.
If that server goes down for an hour, then during that hour nobody can collaborate at all or save versioned changes to anything they're working on.
If the hard disk the central database is on becomes corrupted, and proper backups haven't been kept, you lose absolutely everything -- the entire history of the project except whatever single snapshots people happen to have on their local machines.
Local VCSs suffer from this same problem -- whenever you have the entire history of the project in a single place, you risk losing everything.
Нягледзячы на ​​гэта, дадзены падыход таксама мае сур'ёзныя мінусы.
Самы відавочны мінус -- гэта адзіная кропка адмовы, прадстаўленая цэнтралізаваным серверам.
Калі гэты сервер выйдзе са строю на гадзіну, то на працягу гэтага часу ніхто не зможа выкарыстоўваць кантроль версій для захавання змяненняў, над якімі працуе, а таксама ніхто не зможа абменьвацца гэтымі зменамі з іншымі распрацоўшчыкамі.
Калі жорсткі дыск, на якім захоўваецца цэнтральная БД, пашкоджаны, а своечасовыя бэкапы адсутнічаюць, вы страціце ўсё -- усю гісторыю праекта, не лічачы адзінкавых здымкаў рэпазітара, якія захаваліся на лакальных машынах распрацоўшчыкаў.
Лакальныя СКВ пакутуюць ад той жа самай праблемы: калі ўся гісторыя праекта захоўваецца ў адным месцы, вы рызыкуеце страціць усё.

==== Distributed Version Control Systems
==== Размеркаваныя сістэмы кантролю версій

(((version control,distributed)))
This is where Distributed Version Control Systems (DVCSs) step in.
In a DVCS (such as Git, Mercurial, Bazaar or Darcs), clients don't just check out the latest snapshot of the files; rather, they fully mirror the repository, including its full history.
Thus, if any server dies, and these systems were collaborating via that server, any of the client repositories can be copied back up to the server to restore it.
Every clone is really a full backup of all the data.
(((кантроль версій,размеркаваны)))
Тут у гульню ўступаюць размеркаваныя сістэмы кантролю версій (РСКВ).
У РСКВ (такіх як Git, Mercurial, Bazaar або Darcs) кліенты не проста запампоўваюць здымак ўсіх файлаў (стан файлаў на пэўны момант часу) -- яны цалкам капіююць рэпазітар.
У гэтым выпадку, калі адзін з сервераў, праз які распрацоўшчыкі абменьваліся дадзенымі, памрэ, любы кліенцкі рэпазітар можа быць скапіяваны на іншы сервер каб не спынять працу.
Кожная копія рэпазітара з'яўляецца поўным бэкапам ўсіх дадзеных.

.Distributed version control
image::images/distributed.png[Distributed version control diagram]
.Размеркаваны кантроль версій
image::images/distributed.png["Дыяграма размеркаванага кантролю версій"]

Furthermore, many of these systems deal pretty well with having several remote repositories they can work with, so you can collaborate with different groups of people in different ways simultaneously within the same project.
This allows you to set up several types of workflows that aren't possible in centralized systems, such as hierarchical models.
Больш за тое, многія РСКВ могуць адначасова ўзаемадзейнічаць з некалькімі выдаленымі рэпазітарамі, дзякуючы гэтаму вы можаце працаваць з рознымі групамі людзей, ужываючы розныя падыходы адначасова ў рамках аднаго праекта.
Гэта дазваляе ўжываць адразу некалькі падыходаў у распрацоўцы, напрыклад, іерархічныя мадэлі, што цалкам немагчыма ў цэнтралізаваных сістэмах.
18 changes: 9 additions & 9 deletions book/01-introduction/sections/command-line.asc
Original file line number Diff line number Diff line change
@@ -1,11 +1,11 @@
=== The Command Line
=== Камандны радок

There are a lot of different ways to use Git.
There are the original command-line tools, and there are many graphical user interfaces of varying capabilities.
For this book, we will be using Git on the command line.
For one, the command line is the only place you can run _all_ Git commands -- most of the GUIs implement only a partial subset of Git functionality for simplicity.
If you know how to run the command-line version, you can probably also figure out how to run the GUI version, while the opposite is not necessarily true.
Also, while your choice of graphical client is a matter of personal taste, _all_ users will have the command-line tools installed and available.
Ёсць шмат розных спосабаў выкарыстання Git.
Акрамя арыгінальнага кліента, які мае інтэрфейс каманднага радка, існуе мноства кліентаў з графічным карыстацкім інтэрфейсам, у той ці іншай ступені рэалізуюць функцыянальнасць Git.
У рамках дадзенай кнігі мы будзем выкарыстоўваць Git у камандным радку.
З аднаго боку, камандны радок -- гэта адзінае месца, дзе вы можаце запусціць *усе* каманды Git, так як большасць кліентаў з графічным інтэрфейсам рэалізуюць для прастаты толькі некаторую частку функцыянальнасці Git.
Калі вы ведаеце, як выканаць якое-небудзь дзеянне ў камандным радку, вы, верагодна, зможаце высветліць, як тое ж самае зрабіць і ў GUI-версіі, а вось адваротнае не заўсёды дакладна.
Акрамя таго, у той час, як выбар графічнага кліента -- гэта справа асабістага густу, інструменты каманднага радка даступныя _ўсім_ карыстальнікам адразу пасля ўстаноўкі Git.

So we will expect you to know how to open Terminal in macOS or Command Prompt or PowerShell in Windows.
If you don't know what we're talking about here, you may need to stop and research that quickly so that you can follow the rest of the examples and descriptions in this book.
Таму мы мяркуем, што вы ведаеце, як адкрыць тэрмінал у Mac або камандны радок, або Powershell у Windows.
Калі вам не зразумела, пра што мы тут гаворым, то вам, магчыма, давядзецца ненадоўга перапыніцца і вывучыць гэтыя пытанні, каб вы маглі разумець прыклады і тлумачэння з гэтай кнігі.
Loading