From 98629e007d36f562d639666f8661811798630472 Mon Sep 17 00:00:00 2001 From: burlakvo Date: Tue, 22 Oct 2024 22:17:50 +0300 Subject: [PATCH 01/17] =?UTF-8?q?=D0=94=D0=BE=D0=B4=D0=B0=D1=94=20=D0=BF?= =?UTF-8?q?=D1=80=D0=B8=D0=BC=D1=96=D1=82=D0=BA=D1=83=20=D1=82=D0=B0=20?= =?UTF-8?q?=D0=B2=D0=B8=D0=BB=D1=83=D1=87=D0=B5=D0=BD=D0=BD=D1=8F=20=D0=B7?= =?UTF-8?q?=D0=B0=D0=B9=D0=B2=D0=B8=D1=85=20=D1=84=D0=B0=D0=B9=D0=BB=D1=96?= =?UTF-8?q?=D0=B2=20=D0=B4=D0=BE=20=D0=BF=D0=BB=D0=B0=D0=BD=D1=83?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- update-plan/plan.adoc | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/update-plan/plan.adoc b/update-plan/plan.adoc index 20a0335..8fc5b61 100644 --- a/update-plan/plan.adoc +++ b/update-plan/plan.adoc @@ -10,14 +10,18 @@ // Пропонований порядок роботи (продемонстрований на `book/01-introduction/sections/about-version-control.asc`): // // Спершу отримаємо всі версії цього файлу: -// +// // ---- // f=book/01-introduction/sections/about-version-control.asc // # Дивимося конфлікти // git show origin/english-version:$f > $f-old-english // git show 2.1.434:$f > $f-cur-english // git show HEAD:$f > $f-ukrainian -// git merge-file -p $f-ukrainian $f-old-english $f-cur-english > $f +// git merge-file --diff3 -p $f-ukrainian $f-old-english $f-cur-english > $f +// rm $f-ukrainian $f-old-english $f-cur-english // ---- -// +// // Виправляємо файл і робимо PR. + +.Примітка +Якщо працюєте з власним відсадком, то не забудьте стягнути гілку `english-version` з оригінального репозиторію. From b61f7168ff62694138482cc8e57130d47c51fff3 Mon Sep 17 00:00:00 2001 From: burlakvo Date: Tue, 22 Oct 2024 23:17:54 +0300 Subject: [PATCH 02/17] =?UTF-8?q?=D0=92=D0=B8=D0=BB=D1=83=D1=87=D0=B0?= =?UTF-8?q?=D1=94=20=D1=84=D0=B0=D0=B9=D0=BB=D0=B8?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .travis.yml | 34 -- .../sections/client-tfs.asc | 410 ------------------ .../sections/import-tfs.asc | 60 --- .../sections/eclipse.asc | 10 - update-plan/files.adoc | 8 +- 5 files changed, 4 insertions(+), 518 deletions(-) delete mode 100644 .travis.yml delete mode 100644 book/09-git-and-other-scms/sections/client-tfs.asc delete mode 100644 book/09-git-and-other-scms/sections/import-tfs.asc delete mode 100644 book/A-git-in-other-environments/sections/eclipse.asc diff --git a/.travis.yml b/.travis.yml deleted file mode 100644 index cd6f15a..0000000 --- a/.travis.yml +++ /dev/null @@ -1,34 +0,0 @@ -language: ruby -sudo: false -git: - depth: false -cache: bundler -before_install: - - wget https://raw.githubusercontent.com/progit/progit2-pub/master/bootstrap.sh - - sh bootstrap.sh -script: bundle exec rake book:build -after_success: bundle exec rake book:tag -deploy: - provider: releases - file_glob: true - file: - - progit*.epub - - progit*.mobi - - progit*.pdf - skip_cleanup: true - on: - tags: true - api-key: $GITHUB_API_TOKEN -branches: - only: - - master - - /^2\.1(\.\d+)+$/ - -addons: - apt: - packages: - - epubcheck -notifications: - email: - on_success: never - on_failure: always diff --git a/book/09-git-and-other-scms/sections/client-tfs.asc b/book/09-git-and-other-scms/sections/client-tfs.asc deleted file mode 100644 index f68c719..0000000 --- a/book/09-git-and-other-scms/sections/client-tfs.asc +++ /dev/null @@ -1,410 +0,0 @@ -==== Git та TFS - -(((Interoperation with other VCSs, TFS))) -(((TFS)))((("TFVC", see="TFS"))) -Git популяризується серед Windows розробників і, якщо ви пишете код "під Windows", то є велика ймовірність, що ви також використовуєте Microsoft's Team Foundation Server (TFS). -TFS є набором інструментів для співпраці, що включає в себе облік дефектів, завдань, підтримку Scrum процесу та інших, перегляд коду, та контроль версій. -Є трохи плутанини: *TFS* -- це сервер, котрий має підтримку контролю коду, користуючись як Git, так і своєю власною СКВ, що має назву *TFVC* (Team Foundation Version Control). -Підтримка Git є дещо новою особливістю для TFS (починаючи з 2013 версії), тому всі інструменти, що передували цій появі, звертаються до частини версіонування коду як ``TFS'', незважаючи на те, що насправді працюють з TFVC. - -Якщо ви опинетеся в команді, котра користується TFVC, але краще б надали перевагу Git, як системі контролю версій, то для цього існує готовий проект. - -===== Який інструмент - -(((git-tf)))(((git-tfs))) -Насправді, їх є два: git-tf та git-tfs. - -Git-tfs (можна знайти за https://github.com/git-tfs/git-tfs[]) є .NET проектом та (на момент написання цього тексту) сумісний тільки з Windows. -Для роботи з Git сховищами він використовує .NET обгортку над libgit2, бібліотеко-орієнтованою реалізацією Git, що є високопродуктивною та дозволяє багато гнучкості з нутрощами Git сховища. -Libgit2 не є повною реалізацією Git, тому git-tfs використовує клієнтську командну стрічку Git для того, щоб закрити недостачу, отже, фактично, немає обмежень в тому, що ця утиліта може робити зі сховищами Git. -Її підтримка особливостей TFVC є достить зрілою через те, що вона оперує з сервером через бібліотеки Visual Studio. -Це значить, що вам потрібен доступ до цих бібліотек, що, в свою чергу означає, що потрібно встановити недавню версію Visual Studio (будь-яку редакцію, починаючи з версії 2010, включно з Express починаючи з 2012), або Visual Studio SDK. - -Git-tf (який живе за адресою https://gittf.codeplex.com[]) є Java проектом і через це може працювати на будь-якому комп'ютері з Java середовищем. -Він взаємодіє з Git сховищем через JGit (JVM реалізація Git), тобто, практично не має обмежень щодо функціональності Git. -Проте, робота TFVC не є повною, порівняно з git-tfs – немає підтримки гілок, для прикладу. - -Тому, кожен інструмент має свої сильні та слабкі сторони і є різні ситуації, коли треба надати перевагу одному над іншим. -В цій книзі ми розкриємо базове використання обох. - -[NOTE] -==== -Вам знадобиться доступ до сховища TFVC для того, щоб могти слідувати цим інструкціям. -А їх не так просто знайти, як, скажімо, сховища Git чи Subversion, тому, можливо, прийдеться створити самому. -Для цієї задачі добре підходять Codeplex (https://www.codeplex.com[]) чи Visual Studio Online (http://www.visualstudio.com[]). -==== - - -===== Ознайомлення з `git-tf` - -По-перше, як і з будь-яким іншим Git проектом, склонуймо. -Ось як це виглядає з `git-tf`: - -[source,console] ----- -$ git tf clone https://tfs.codeplex.com:443/tfs/TFS13 $/myproject/Main project_git ----- - -Перший аргумент є URL до TFVC колекцій, другий має формат `$/проект/гілка`, а третій -- це шлях до локального Git сховища, що буде створено (цей аргумент не обов'язковий). -Git-tf може працювати лише з одною гілкою одночасно; якщо ви хочете зробити чекіни (checkins) до іншої гілки TFVC, то склонуйте заново з потрібної гілки. - -Ось як створити повнофункціональний Git репозиторій: - -[source,console] ----- -$ cd project_git -$ git log --all --oneline --decorate -512e75a (HEAD, tag: TFS_C35190, origin_tfs/tfs, master) Checkin message ----- - -Це зветься _мілким_ (shallow) клоном, в тому значенні, що завантажено лише найостанніший ченджсет. -TFVC не спроектований таким чином, що кожен клієнт має повну копію історії, тому git-tf типово отримає лише останню версію, а це є значно швидшим. - -Коли ж у вас вдосталь часу, мабуть, варто клонувати всю історію проекту, за допомогою опції `--deep`: - -[source,console] ----- -$ git tf clone https://tfs.codeplex.com:443/tfs/TFS13 $/myproject/Main \ - project_git --deep -Username: domain\user -Password: -Connecting to TFS... -Cloning $/myproject into /tmp/project_git: 100%, done. -Cloned 4 changesets. Cloned last changeset 35190 as d44b17a -$ cd project_git -$ git log --all --oneline --decorate -d44b17a (HEAD, tag: TFS_C35190, origin_tfs/tfs, master) Goodbye -126aa7b (tag: TFS_C35189) -8f77431 (tag: TFS_C35178) FIRST -0745a25 (tag: TFS_C35177) Created team project folder $/tfvctest via the \ - Team Project Creation Wizard ----- - -Зверніть увагу на теґи з іменами типу `TFS_C35189`; за допомогою цієї особливості ви дізнаєтеся який Git коміт та ченджсет TFVC пов'язані між собою. -Це є хорошим відображенням, оскільки ви можете за допомогою простої команди `log` з'ясувати які з ваших комітів також також існують в TFVC. -Ці теґи не є обов'язковими (і їх насправді можна вимкнути за допомогою `git config git-tf.tag false`) – git-tf все одно зберігає реальні зв'язки коміт-ченджсет у файлі `.git/git-tf`. - - -===== Ознайомлення з `git-tfs` - -Клонування в git-tfs відбувається дещо інакше. -Погляньте: - -[source,powershell] ----- -PS> git tfs clone --with-branches \ - https://username.visualstudio.com/DefaultCollection \ - $/project/Trunk project_git -Initialized empty Git repository in C:/Users/ben/project_git/.git/ -C15 = b75da1aba1ffb359d00e85c52acb261e4586b0c9 -C16 = c403405f4989d73a2c3c119e79021cb2104ce44a -Tfs branches found: -- $/tfvc-test/featureA -The name of the local branch will be : featureA -C17 = d202b53f67bde32171d5078968c644e562f1c439 -C18 = 44cd729d8df868a8be20438fdeeefb961958b674 ----- - -Зверніть увагу на прапорець `--with-branches`. -Git-tfs має можливість створювати відповідності між гілками TFVC та Git, а цей прапорець вказує на необхідність створювати локальні Git гілки для кожної гілки TFVC. -Його використання є рекомендованим якщо ви збираєтеся робити гілки чи зливати в TFS, проте такий підхід не працюватиме з сервером старішим за TFS 2010 – до цього релізу ``гілки'' були просто теками, тому git-tfs не міг відрізнити їх від звичайних тек. - -Погляньте на результуюче Git сховище: - -[source,powershell] ----- -PS> git log --oneline --graph --decorate --all -* 44cd729 (tfs/featureA, featureA) Goodbye -* d202b53 Branched from $/tfvc-test/Trunk -* c403405 (HEAD, tfs/default, master) Hello -* b75da1a New project -PS> git log -1 -commit c403405f4989d73a2c3c119e79021cb2104ce44a -Author: Ben Straub -Date: Fri Aug 1 03:41:59 2014 +0000 - - Hello - - git-tfs-id: [https://username.visualstudio.com/DefaultCollection]$/myproject/Trunk;C16 ----- - -Маємо дві локальні гілки, `master` та `featureA`, котрі відображають стартову точку клонування (`Trunk` в іменуванні TFVC) та дочірню гілку (`featureA` в TFVC). -Ви можете бачити також, що ``віддалене сховище'' `tfs` має також кілька посилань: `default` та `featureA`, які відображають гілки TFVC. -Git-tfs робить відповідність між клонованою гілкою та `tfs/default`, а також інші отримують свої імена. - -Ще варто звернути увагу на `git-tfs-id:` рядки в повідомленнях коміту. -Замість теґів, git-tfs використовує ці позначки для зв'язку між TFVC ченджсетами та Git комітами. -З цього випливає те, що ваші Git коміти матимуть різні SHA-1 хеші до та після надсилання до TFVC. - -===== Процеси роботи Git-tf[s] - -[NOTE] -==== -Незалежно від того, яким з інстументів ви користуєтеся, налаштуйте ряд конфігураційних значень, задля уникнення неприємностей. - -[source,console] ----- -$ git config set --local core.ignorecase=true -$ git config set --local core.autocrlf=false ----- -==== - -Очевидно, далі ви б хотіли попрацювати над проектом. -TFVC та TFS мають кілька особливостей що можуть ускладнити ваш робочий процес: - -. Тематичні гілки, що не мають відображення в TFVC додають складнощів. - Стається це через *дуже* різний спосіб того, як TFVC та Git тракують гілки. -. Пам'ятайте, що TFVC дозволяє користувачам ``забирати''(checkout) файли з сервера, замикаючи їх так, що більш ніхто не зможе їх редагувати. - Звичайно, це не є перепоною для роботою з цими файлами у вашому локальному сховищі, але може стати такою, коли прийде час надсилання змін до TFVC сервера. -. TFS має концепцію ``закритих'' ??? (``gated'') чекінів, коли цикл побудова-тести має бути успішно завершеним до того, як дозволено робити чекін. - Тут використовується функція відкладених комітів ``shelve'' TFVC, яку ми тут детально не розглядатимемо. - Ви можете сфабрикувати це вручну з git-tf та git-tfs котрі мають команду `checkintool`, що знає про закриті чекіни. - -Для стислості, ми розглянемо лише щасливий шлях, що уникає більшість із згаданих нюансів. - -===== Робочий процес `git-tf` - - -Скажімо, ви виконали деяку роботу, додали кілька комітів до `master`, а тепер готові ділитися своїми доробками на TFVC сервері. -Ось наше Git сховище: - -[source,console] ----- -$ git log --oneline --graph --decorate --all -* 4178a82 (HEAD, master) update code -* 9df2ae3 update readme -* d44b17a (tag: TFS_C35190, origin_tfs/tfs) Goodbye -* 126aa7b (tag: TFS_C35189) -* 8f77431 (tag: TFS_C35178) FIRST -* 0745a25 (tag: TFS_C35177) Created team project folder $/tfvctest via the \ - Team Project Creation Wizard ----- - -Ми хочемо взяти відбиток коміту `4178a82` та надіслати його на TFVC сервер. -Насамперед, подивимося чи хтось із колег долучався до проекту з того часу, як ми востаннє з'єднувалися: - -[source,console] ----- -$ git tf fetch -Username: domain\user -Password: -Connecting to TFS... -Fetching $/myproject at latest changeset: 100%, done. -Downloaded changeset 35320 as commit 8ef06a8. Updated FETCH_HEAD. -$ git log --oneline --graph --decorate --all -* 8ef06a8 (tag: TFS_C35320, origin_tfs/tfs) just some text -| * 4178a82 (HEAD, master) update code -| * 9df2ae3 update readme -|/ -* d44b17a (tag: TFS_C35190) Goodbye -* 126aa7b (tag: TFS_C35189) -* 8f77431 (tag: TFS_C35178) FIRST -* 0745a25 (tag: TFS_C35177) Created team project folder $/tfvctest via the \ - Team Project Creation Wizard ----- - -Схоже на те, що ще хтось також працює та наші історії розійшлися. -Ось де переваги Git очевидні, але ми маємо два способи продовжувати: - -. Зробити коміт злиття здається природнім для користувача Git (зрештою, `git pull` саме це й робить), а git-tf може це виконати за допомогою `git tf pull`. - Однак, зауважте, що TFVC не мислить таким самим чином, і, якщо ви надсилаєте коміти злиття, ваша історія виглядатиме по-різному по обидві сторони, що може спантеличувати. - Проте, якщо ви збираєтеся надіслати всі свої зміни як один ченджсет, це, мабуть, найлегший спосіб. -. Перебазовування робить історію лінійною, тобто дає нам можливість перетворити кожен Git коміт на ченджсет TFVC. - Оскільки даний спосіб залишає нам найбільше можливостей потім, ми рекомендуємо саме його; git-tf підтримує цю дію за допомогою `git tf pull --rebase`. - -Вибір за вами. -У цьому прикладі ми перебазовуватимемо: - -[source,console] ----- -$ git rebase FETCH_HEAD -First, rewinding head to replay your work on top of it... -Applying: update readme -Applying: update code -$ git log --oneline --graph --decorate --all -* 5a0e25e (HEAD, master) update code -* 6eb3eb5 update readme -* 8ef06a8 (tag: TFS_C35320, origin_tfs/tfs) just some text -* d44b17a (tag: TFS_C35190) Goodbye -* 126aa7b (tag: TFS_C35189) -* 8f77431 (tag: TFS_C35178) FIRST -* 0745a25 (tag: TFS_C35177) Created team project folder $/tfvctest via the \ - Team Project Creation Wizard ----- - -Тепер ми готові до чекіну в TFVC сервер. -Git-tf дає можливість вибрати: створити один ченджсет, що представлятиме всі зміни, починаючи з останньої (`--shallow`, що є типовою поведінкою) чи створювати по ченджсету на кожен коміт (`--deep`). -Тут ми просто створимо один ченджсет: - -[source,console] ----- -$ git tf checkin -m 'Updating readme and code' -Username: domain\user -Password: -Connecting to TFS... -Checking in to $/myproject: 100%, done. -Checked commit 5a0e25e in as changeset 35348 -$ git log --oneline --graph --decorate --all -* 5a0e25e (HEAD, tag: TFS_C35348, origin_tfs/tfs, master) update code -* 6eb3eb5 update readme -* 8ef06a8 (tag: TFS_C35320) just some text -* d44b17a (tag: TFS_C35190) Goodbye -* 126aa7b (tag: TFS_C35189) -* 8f77431 (tag: TFS_C35178) FIRST -* 0745a25 (tag: TFS_C35177) Created team project folder $/tfvctest via the \ - Team Project Creation Wizard ----- - -Створився теґ `TFS_C35348`, вказуючи що TFVC має такий самий відбиток як відбиток в коміті `5a0e25e`. -Важливо зауважити, що не кожен Git коміт потребує точного відповідника в TFVC; коміт `6eb3eb5`, наприклад, ніде не існує на сервері. - -Таким є основний процес роботи. -Ось ще кілька міркувань, що варто пам'ятати: - -* Робота з гілками не підтримується. - Git-tf в змозі створити Git сховище лише з одної гілки TFVC одночасно. -* Співпрацюйте за допомогою TFVC або Git, але не за допомогою обидвох. - Різні git-tf клони одного й того ж TFVC сховища можуть мати різні SHA-1 хеші, що спричинить нескінченні головні болі. -* Якщо процес вашої команди включає в себе роботу в Git та періодичні синхронізації до TFVC, з'єднуйте до TFVC лише одне Git сховище. - -===== Робочий процес `git-tfs` - -Пройдімо такий самий сценарій з git-tfs. -Маємо нові коміти, зроблені в гілку `master` нашого Git сховища: - -[source,powershell] ----- -PS> git log --oneline --graph --all --decorate -* c3bd3ae (HEAD, master) update code -* d85e5a2 update readme -| * 44cd729 (tfs/featureA, featureA) Goodbye -| * d202b53 Branched from $/tfvc-test/Trunk -|/ -* c403405 (tfs/default) Hello -* b75da1a New project ----- - -Тепер глянемо чи хтось додав якісь зміни, поки ми тут мудрували: - -[source,powershell] ----- -PS> git tfs fetch -C19 = aea74a0313de0a391940c999e51c5c15c381d91d -PS> git log --all --oneline --graph --decorate -* aea74a0 (tfs/default) update documentation -| * c3bd3ae (HEAD, master) update code -| * d85e5a2 update readme -|/ -| * 44cd729 (tfs/featureA, featureA) Goodbye -| * d202b53 Branched from $/tfvc-test/Trunk -|/ -* c403405 Hello -* b75da1a New project ----- - -Так, виявляється, що хтось із наших колег додав TFVC ченджсет, який ми бачимо як новий коміт `aea74a0`, а віддалена гілка `tfs/default` прогресувала. - -Так само як і у випадку git-tf, ми маємо дві фундаментальні опції, щоб розв'язати цю розбіжність: - -. Перебазуватися та зберегти історію лінійною. -. Виконати злиття та зберегти що ж насправді трапилося. - -В нашому випадку ми робитимемо ``глибокий'' чекін, тобто кожен Git коміт стає ченджсетом TFVC, тому виберемо варіант з перебазовуванням. - -[source,powershell] ----- -PS> git rebase tfs/default -First, rewinding head to replay your work on top of it... -Applying: update readme -Applying: update code -PS> git log --all --oneline --graph --decorate -* 10a75ac (HEAD, master) update code -* 5cec4ab update readme -* aea74a0 (tfs/default) update documentation -| * 44cd729 (tfs/featureA, featureA) Goodbye -| * d202b53 Branched from $/tfvc-test/Trunk -|/ -* c403405 Hello -* b75da1a New project ----- - -Тепер ми готові завершити наш вклад, зачекінивши код до TFVC серверу. -Будемо використовувати команду `rcheckin` для того, щоб створювався TFVC ченджсет на кожен Git коміт від HEAD до першого віддаленого посилання `tfs` (команда `checkin` створила б просто один ченджсет, щось типу того як працює зчавлення (squashing) комітів). - -[source,powershell] ----- -PS> git tfs rcheckin -Working with tfs remote: default -Fetching changes from TFS to minimize possibility of late conflict... -Starting checkin of 5cec4ab4 'update readme' - add README.md -C20 = 71a5ddce274c19f8fdc322b4f165d93d89121017 -Done with 5cec4ab4b213c354341f66c80cd650ab98dcf1ed, rebasing tail onto new TFS-commit... -Rebase done successfully. -Starting checkin of b1bf0f99 'update code' - edit .git\tfs\default\workspace\ConsoleApplication1/ConsoleApplication1/Program.cs -C21 = ff04e7c35dfbe6a8f94e782bf5e0031cee8d103b -Done with b1bf0f9977b2d48bad611ed4a03d3738df05ea5d, rebasing tail onto new TFS-commit... -Rebase done successfully. -No more to rcheckin. -PS> git log --all --oneline --graph --decorate -* ff04e7c (HEAD, tfs/default, master) update code -* 71a5ddc update readme -* aea74a0 update documentation -| * 44cd729 (tfs/featureA, featureA) Goodbye -| * d202b53 Branched from $/tfvc-test/Trunk -|/ -* c403405 Hello -* b75da1a New project ----- - -Зверніть увагу на те, як після кожного успішного чекіна до TFVC сервера, git-tfs перебазовує залишкові зміни поверх щойно зробленого. -Це тому, що додається поле `git-tfs-id` в кінці повідомлення коміту, і це змінює SHA-1 хеші. -Так і було задумано, не потрібно хвилюватися з цього приводу, просто вам потрібно знати, що це відбувається; особливо, якщо ви ділитеся ідентифікаторами Git комітів з іншими. - -TFS має багато особливостей для інтеграції зі своєю системою контролю версій, такі як одиниці роботи (work items), переглядальники коду, закриті (gated) чекіни тощо. -Опанувати їх всіх з командного рядка може бути досить хвацькою задачею, але, на щастя, git-tfs має досить швидкий доступ і до більш візуальних інструментів чекіну: - -[source,powershell] ----- -PS> git tfs checkintool -PS> git tfs ct ----- - -Виглядає це якось так: - -.Інструмент чекіну git-tfs. -image::images/git-tfs-ct.png[Інструмент чекіну git-tfs.] - -Це виглядатиме звичним для користувачів TFS, оскільки це той самий діалог, що запускається у Visual Studio. - -Git-tfs також дає можливість керувати гілками TFVC з Git сховища. -Для прикладу, створимо гілку: - -[source,powershell] ----- -PS> git tfs branch $/tfvc-test/featureBee -The name of the local branch will be : featureBee -C26 = 1d54865c397608c004a2cadce7296f5edc22a7e5 -PS> git log --oneline --graph --decorate --all -* 1d54865 (tfs/featureBee) Creation branch $/myproject/featureBee -* ff04e7c (HEAD, tfs/default, master) update code -* 71a5ddc update readme -* aea74a0 update documentation -| * 44cd729 (tfs/featureA, featureA) Goodbye -| * d202b53 Branched from $/tfvc-test/Trunk -|/ -* c403405 Hello -* b75da1a New project ----- - -Створення гілки в TFVC означає додавання ченджсету до гілки, що вже існує, і це відображено окремим комітом Git. -Також, зверніть увагу, що git-tfs *створив* віддалену гілку `tfs/featureBee`, але `HEAD` досі вказує на `master`. -Якщо вам кортить попрацювати з щойно створеною гілкою, потрібно базувати свої нові коміти на коміті `1d54865`, можливо, створивши тематичну гілку з цього коміту. - -===== Git та TFS. Підсумок - -Обидві Git-tf та Git-tfs є чудовими інструментами для доступу до сервера TFVC та роботи з ним. -Вони дають вам локальну могутність Git, уникають постійних мандрів мережею до центрального сервера TFVC, та спрощують ваше розробницьке життя, без необхідності переходу на Git цілою командою. -Якщо ви працюєте з Windows (що дуже ймовірно, коли користуєтеся TFS), то вам, мабуть, більше захочеться обрати git-tfs, через більш повний набір особливостей, а у випадку іншої платформи, ви користуватиметеся git-tf, яка є більш обмеженою. -Як і з більшістю інструментів цього розділу, вам потрібно обрати одну з систем контролю версій, яка буде основною, а іншу використовувати ніби підлеглу – будь це Git чи TFVC, потрібно обрати один центр для співпраці, не обидва. diff --git a/book/09-git-and-other-scms/sections/import-tfs.asc b/book/09-git-and-other-scms/sections/import-tfs.asc deleted file mode 100644 index e58827f..0000000 --- a/book/09-git-and-other-scms/sections/import-tfs.asc +++ /dev/null @@ -1,60 +0,0 @@ -[[_git_tfs]] -==== TFS - -(((TFS)))(((Importing, from TFS))) -Якщо ваша команда переходить від керування кодом за допомогою TFVC до Git, то ви забажаєте конвертацію найвищої якості з тих, які вам доступні. -Це означає, що хоча ми розглянули й git-tfs і git-tf у секції взаємодії, тут ми розглянемо лише git-tfs, оскільки він підтримує гілки, та здійснити це за допомогою git-tf неприйнятно складно. - -[NOTE] -==== -Це однобічна конвертація. -Отримане сховище Git не буде в змозі взаємодіяти з оригінальним проектом TFVC. -==== - -Спершу треба встановити відображення імен користувачів. -TFVC доволі ліберальний щодо того, що може бути в полі автора для набору змін, проте Git бажає читабельне ім’я та поштову адресу. -Ви можете отримати цю інформацію з консольного клієнта `tf` ось так: - -[source,powershell] ----- -PS> tf history $/myproject -recursive > AUTHORS_TMP ----- - -Ця команда отримує всі набори змін в історії проекту та кладе їх у файл AUTHORS_TMP, з якого ми отримаємо дані зі стовпчика 'User' (другого). -Відкрийте файл та з’ясуйте з якого символу починається та на якому закінчується стовпчик, та замініть у наступній команді параметри `11-20` команди `cut` своїми значеннями: - -[source,powershell] ----- -PS> cat AUTHORS_TMP | cut -b 11-20 | tail -n+3 | sort | uniq > AUTHORS ----- - -Команда `cut` залишає лише символи між 11 та 20 кожного рядка. -Команда `tail` ігнорує перші два рядки, що є заголовками та лінією ASCII-арт. -Результат пропускається через `sort` і `uniq`, щоб позбутися дублікатів, та зберігається у файлі `AUTHORS`. -Далі треба попрацювати вручну; щоб git-tfs зміг ефективно використати цей файл, кожен рядок має бути у форматі: - -[source,text] ----- -DOMAIN\username = User Name ----- - -Частина ліворуч -- це поле ``User'' з TFVC, а частина праворуч від знаку дорівнює -- це ім’я користувача, яке використовуватиметься для комітів Git. - -Щойно у вас є такий файл, можна робити повний клон проекту TFVC, який вам потрібен: - -[source,powershell] ----- -PS> git tfs clone --with-branches --authors=AUTHORS https://username.visualstudio.com/DefaultCollection $/project/Trunk project_git ----- - -Далі ви забажаєте прибрати секції `git-tfs-id` наприкінці повідомлень комітів. -Це зробить наступна команда: - -[source,powershell] ----- -PS> git filter-branch -f --msg-filter 'sed "s/^git-tfs-id:.*$//g"' '--' --all ----- - -Вона використовує команду `sed` з середовища Git-bash, щоб замінити будь-який рядок, що починається з ``git-tfs-id:'', порожнечею, яку потім проігнорує Git. - -Коли все це зроблено, ви готові додати нове віддалене сховище, надіслати туди всі свої гілки, та команда може розпочати роботу з Git. diff --git a/book/A-git-in-other-environments/sections/eclipse.asc b/book/A-git-in-other-environments/sections/eclipse.asc deleted file mode 100644 index 80e0da3..0000000 --- a/book/A-git-in-other-environments/sections/eclipse.asc +++ /dev/null @@ -1,10 +0,0 @@ -=== Git в Eclipse - -(((Eclipse))) -Git постачає додаток під назвою Egit, який надає доволі повний інтерфейс до операцій Git. -Щоб отримати до нього доступ, треба переключитись на перспективу Git (Window > Open Perspective > Other…, та вибрати "Git"). - -.Середовище EGit в Eclipse. -image::images/egit.png[Середовище EGit в Eclipse.] - -EGit має багацько чудової документації, яку ви можете знайти, якщо перейдете до Help > Help Contents, та виберете "EGit Documentation" зі списку. diff --git a/update-plan/files.adoc b/update-plan/files.adoc index 0628b8c..dc916bd 100644 --- a/update-plan/files.adoc +++ b/update-plan/files.adoc @@ -101,10 +101,10 @@ Вилучені файли: -* book/A-git-in-other-environments/sections/eclipse.asc -* book/09-git-and-other-scms/sections/client-tfs.asc -* .travis.yml -* book/09-git-and-other-scms/sections/import-tfs.asc +* + book/A-git-in-other-environments/sections/eclipse.asc +* + book/09-git-and-other-scms/sections/client-tfs.asc +* + .travis.yml +* + book/09-git-and-other-scms/sections/import-tfs.asc Додані і нами (для того, щоб генерація працювала), і ними: From 9d678da41c30ae3fad49fa2b454d9f398e914802 Mon Sep 17 00:00:00 2001 From: burlakvo Date: Tue, 22 Oct 2024 23:23:17 +0300 Subject: [PATCH 03/17] =?UTF-8?q?=D0=9E=D0=BD=D0=BE=D0=B2=D0=BB=D1=8E?= =?UTF-8?q?=D1=94:=201=20-=20about-version-control.asc?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../sections/about-version-control.asc | 24 +++++++++---------- update-plan/files.adoc | 12 +++++----- 2 files changed, 18 insertions(+), 18 deletions(-) diff --git a/book/01-introduction/sections/about-version-control.asc b/book/01-introduction/sections/about-version-control.asc index 631f3cf..f204975 100755 --- a/book/01-introduction/sections/about-version-control.asc +++ b/book/01-introduction/sections/about-version-control.asc @@ -1,12 +1,12 @@ === Про систему контролю версій (((version control))) -Що таке ``система контролю версій'', і чому це важливо? +Що таке "`система контролю версій`", і чому це важливо? Система контролю версій - це система, що записує зміни у файл або набір файлів протягом деякого часу, так що ви зможете повернутися до певної версії пізніше. Як приклад, в цій книзі, для файлів, що знаходяться під контролем версій, буде використовуватися код програмного забезпечення, хоча насправді ви можете використовувати контроль версій практично для будь-яких типів файлів. Якщо ви графічний або веб-дизайнер і хочете зберегти кожну версію зображення або макета (швидше за все, захочете), система контролю версій (далі СКВ) якраз те, що потрібно. -Вона дозволяє повернути вибрані файли до попереднього стану, повернути весь проект до попереднього стану, побачити зміни, побачити, хто останній міняв щось і спровокував проблему, хто вказав на проблему і коли, та багато іншого. +Вона дозволяє повернути вибрані файли до попереднього стану, повернути весь проєкт до попереднього стану, побачити зміни, побачити, хто останній міняв щось і спровокував проблему, хто вказав на проблему і коли, та багато іншого. Використання СКВ також в цілому означає, що, якщо ви зламали щось або втратили файли, ви просто можете все виправити. Крім того, ви отримаєте все це за дуже невеликі накладні витрати. @@ -19,43 +19,43 @@ Щоб справитися з цією проблемою, програмісти давно розробили локальні СКВ, що мають просту базу даних, яка зберігає всі зміни в файлах під контролем версій. -.Локальні системи контролю версій. +.Діаграма локальних систем контролю версій. image::images/local.png[Local version control diagram] Одним з найбільш поширених інструментів СКВ була система під назвою RCS, яка досі поширюється з багатьма комп'ютерами сьогодні. -RCS зберігає набори латок (тобто, відмінності між файлами) в спеціальному форматі на диску; він може заново відтворити будь-який файл, як він виглядав, в будь-який момент часу, шляхом додавання всіх латок. +https://www.gnu.org/software/rcs/[RCS^] зберігає набори латок (тобто, відмінності між файлами) в спеціальному форматі на диску; він може заново відтворити будь-який файл, як він виглядав, в будь-який момент часу, шляхом додавання всіх латок. ==== Централізовані системи контролю версій (((version control,centralized))) Наступним важливим питанням, з яким стикаються люди, є необхідність співпрацювати з іншими розробниками. Щоб справитися з цією проблемою, були розроблені централізовані системи контролю версій (ЦСКВ). -Такі системи як CVS, Subversion і Perforce, мають єдиний сервер, який містить всі версії файлів, та деяке число клієнтів, які отримують файли з центрального місця. +Ці системи (такі як CVS, Subversion і Perforce) мають єдиний сервер, який містить всі версії файлів, та деяке число клієнтів, які отримують файли з центрального місця. Протягом багатьох років, це було стандартом для систем контролю версій. -.Централізовані системи контролю версій. +.Діаграма централізованих систем контролю версій. image::images/centralized.png[Centralized version control diagram] Такий підхід має безліч переваг, особливо над локальними СКВ. -Наприклад, кожному учаснику проекту відомо, певною мірою, чим займаються інші. +Наприклад, кожному учаснику проєкту відомо, певною мірою, чим займаються інші. Адміністратори мають повний контроль над тим, хто і що може робити. Набагато легше адмініструвати ЦСКВ, ніж мати справу з локальними базами даних для кожного клієнта. Але цей підхід також має деякі серйозні недоліки. Найбільш очевидним є єдина точка відмови, яким є централізований сервер. Якщо сервер виходить з ладу протягом години, то протягом цієї години ніхто не може співпрацювати або зберігати зміни над якими вони працюють під версійним контролем. -Якщо жорсткий диск центральної бази даних на сервері пошкоджено, і своєчасні резервні копії не були зроблені, ви втрачаєте абсолютно все -- всю історію проекту, крім одиночних знімків проекту, що збереглися на локальних машинах людей. -Локальні СКВ страждають тією ж проблемою -- щоразу, коли вся історія проекту зберігається в одному місці, ви ризикуєте втратити все. +Якщо жорсткий диск центральної бази даних на сервері пошкоджено, і своєчасні резервні копії не були зроблені, ви втрачаєте абсолютно все -- всю історію проєкту, крім одиночних знімків проєкту, що збереглися на локальних машинах людей. +Локальні СКВ страждають тією ж проблемою -- щоразу, коли вся історія проєкту зберігається в одному місці, ви ризикуєте втратити все. ==== Децентралізовані системи контролю версій (((version control,distributed))) Долучаються до гри децентралізовані системи контролю версій (ДСКВ). -В ДСКВ (таких як, Git, Mercurial, Bazaar або Darcs), клієнти не просто отримують останній знімок файлів репозиторія: натомість вони є повною копією сховища разом з усією його історією. +В ДСКВ (таких як, Git, Mercurial або Darcs), клієнти не просто отримують останній знімок файлів репозиторія: натомість вони є повною копією сховища разом з усією його історією. Таким чином, якщо вмирає який-небудь сервер, через який співпрацюють розробники, будь-який з клієнтських репозиторіїв може бути скопійований назад до серверу, щоб відновити його. Кожна копія дійсно є повною резервною копією всіх даних. -.Децентралізовані системи контролю версій. +.Діаграма децентралізованих систем контролю версій. image::images/distributed.png[Distributed version control diagram] -Більш того, багато з цих систем дуже добре взаємодіють з декількома віддаленими репозиторіями, так що ви можете співпрацювати з різними групами людей, застосовуючи різні підходи в межах одного проекту одночасно. +Більш того, багато з цих систем дуже добре взаємодіють з декількома віддаленими репозиторіями, так що ви можете співпрацювати з різними групами людей, застосовуючи різні підходи в межах одного проєкту одночасно. Це дозволяє налаштувати декілька типів робочих процесів, таких як ієрархічні моделі, які неможливі в централізованих системах. diff --git a/update-plan/files.adoc b/update-plan/files.adoc index dc916bd..f2b01de 100644 --- a/update-plan/files.adoc +++ b/update-plan/files.adoc @@ -4,7 +4,7 @@ |=== | Назва файлу |Статус (+ означає зроблено, * означає в процесі) -| book/01-introduction/sections/about-version-control.asc | +| book/01-introduction/sections/about-version-control.asc | + | book/01-introduction/sections/command-line.asc | | book/01-introduction/sections/first-time-setup.asc | | book/01-introduction/sections/help.asc | @@ -12,11 +12,11 @@ | book/01-introduction/sections/installing.asc | | book/01-introduction/sections/what-is-git.asc | | book/02-git-basics/sections/aliases.asc | * by Eugene (dev99problems) -| book/02-git-basics/sections/getting-a-repository.asc | * by Eugene (dev99problems) -| book/02-git-basics/sections/recording-changes.asc | * by Eugene (dev99problems) -| book/02-git-basics/sections/remotes.asc | * by Eugene (dev99problems) -| book/02-git-basics/sections/tagging.asc | * by Eugene (dev99problems) -| book/02-git-basics/sections/undoing.asc | * by Eugene (dev99problems) +| book/02-git-basics/sections/getting-a-repository.asc | * by Eugene (dev99problems) +| book/02-git-basics/sections/recording-changes.asc | * by Eugene (dev99problems) +| book/02-git-basics/sections/remotes.asc | * by Eugene (dev99problems) +| book/02-git-basics/sections/tagging.asc | * by Eugene (dev99problems) +| book/02-git-basics/sections/undoing.asc | * by Eugene (dev99problems) | book/02-git-basics/sections/viewing-history.asc | * by Eugene (dev99problems) | book/03-git-branching/sections/basic-branching-and-merging.asc | | book/03-git-branching/sections/branch-management.asc | From 44a311d82cb25634ca3781592c3029cb98a19dfd Mon Sep 17 00:00:00 2001 From: burlakvo Date: Tue, 22 Oct 2024 23:24:36 +0300 Subject: [PATCH 04/17] =?UTF-8?q?=D0=9E=D0=BD=D0=BE=D0=B2=D0=BB=D1=8E?= =?UTF-8?q?=D1=94:=201=20-=20command-line.asc?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- book/01-introduction/sections/command-line.asc | 4 ++-- update-plan/files.adoc | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/book/01-introduction/sections/command-line.asc b/book/01-introduction/sections/command-line.asc index 83c8278..9f499c5 100755 --- a/book/01-introduction/sections/command-line.asc +++ b/book/01-introduction/sections/command-line.asc @@ -3,9 +3,9 @@ Є багато різних варіантів використання Git. Крім оригінальних клієнтів командного рядка, є безліч клієнтів з графічним інтерфейсом користувача з різними можливостями. Для цієї книги ми будемо використовувати Git в командному рядку. -З одного боку, командний рядок -- єдине місце, де можна виконувати _всі_ команди Git - більшість графічних інтерфейсів для простоти реалізують тільки деяку підмножину функціональності Git. +З одного боку, командний рядок -- єдине місце, де можна виконувати _всі_ команди Git -- більшість графічних інтерфейсів для простоти реалізують тільки деяку підмножину функціональності Git. Якщо ви знаєте, як виконати щось з командного рядка, ви, ймовірно, також можете з'ясувати, як виконати це і графічному інтерфейсі, у той час як зворотне не завжди вірно. Крім того, в той час, як вибір графічного клієнта справа особистого смаку, інструменти командного рядка мають _усі_ користувачі одразу ж після інсталяції. -Таким чином, ми очікуємо, що ви знаєте, як відкрити термінал в Mac або командний рядок, або Powershell в Windows. +Таким чином, ми очікуємо, що ви знаєте, як відкрити термінал в macOS або командний рядок чи PowerShell у Windows. Якщо ви не розумієте, про що ми тут говоримо, можливо, вам потрібно буде зупинитися та швидко дізнатися це, щоб ви були в змозі розуміти інші приклади і описи в цій книзі. diff --git a/update-plan/files.adoc b/update-plan/files.adoc index f2b01de..3618267 100644 --- a/update-plan/files.adoc +++ b/update-plan/files.adoc @@ -5,7 +5,7 @@ |=== | Назва файлу |Статус (+ означає зроблено, * означає в процесі) | book/01-introduction/sections/about-version-control.asc | + -| book/01-introduction/sections/command-line.asc | +| book/01-introduction/sections/command-line.asc | + | book/01-introduction/sections/first-time-setup.asc | | book/01-introduction/sections/help.asc | | book/01-introduction/sections/history.asc | From 53cf41faa354adea35f8c25d42dbabb4020a8b19 Mon Sep 17 00:00:00 2001 From: burlakvo Date: Wed, 23 Oct 2024 00:34:55 +0300 Subject: [PATCH 05/17] =?UTF-8?q?=D0=9E=D0=BD=D0=BE=D0=B2=D0=BB=D1=8E?= =?UTF-8?q?=D1=94:=201=20-=20first-time-setup.asc?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../sections/first-time-setup.asc | 50 ++++++++++++------- update-plan/files.adoc | 2 +- 2 files changed, 34 insertions(+), 18 deletions(-) diff --git a/book/01-introduction/sections/first-time-setup.asc b/book/01-introduction/sections/first-time-setup.asc index 9047125..b48fdf1 100755 --- a/book/01-introduction/sections/first-time-setup.asc +++ b/book/01-introduction/sections/first-time-setup.asc @@ -8,21 +8,30 @@ До Git входить утиліта що має назву `git config`, яка дозволяє отримати чи встановити параметри, що контролюють усіма аспектами того, як Git виглядає чи працює. Ці параметри можуть бути збережені в трьох різних місцях: -1. Файл `/etc/gitconfig` містить значення для кожного користувача в системі і всіх їхніх репозиторіїв. +1. Файл `[path]/etc/gitconfig` містить значення для кожного користувача в системі і всіх їхніх репозиторіїв. Якщо ви передаєте опцію `--system` при виконанні `git config`, параметри читаються та пишуться з цього файлу. - (Це системний файл конфігурації, відповідно, вам потрібен був доступ адміністратора чи суперкористувача, щоб змінювати його.) + Це системний файл конфігурації, відповідно, вам потрібен був доступ адміністратора чи суперкористувача, щоб змінювати його. 2. Файл `~/.gitconfig` або `~/.config/git/config` зберігає значення саме для вас -- користувача. - Ви можете налаштувати Git читати і писати в цей файл, вказуючи опцію `--global.` + Ви можете налаштувати Git читати і писати в цей файл, вказуючи опцію `--global`, що вплине на _всі_ репозиторії з якими ви працюєте у вашій системі. 3. Файл `config` у каталозі Git (тобто `.git/config`) у тому репозиторії, який ви використовуєте в даний момент, зберігає налаштування конкретного репозиторія. + Ви можете змусити Git читати і писати в цей файл, вказавши опцію `--local`, але типово вона увімкнута. + Звісно, ви маєте бути десь у репозиторії Git аби ця опція працювала правильно. -Кожен рівень має пріоритет над налаштуваннями в попередньому рівні, тобто параметри в `.git/config` перевизначають параметри в `/etc/gitconfig`. +Кожен рівень має пріоритет над налаштуваннями в попередньому рівні, тобто параметри в `.git/config` перевизначають параметри в `[path]/etc/gitconfig`. У системах Windows, Git шукає файл `.gitconfig` в каталозі `$HOME` (`C:\Users\$USER` для більшості користувачів). -Він також все одно шукає файл `/etc/gitconfig`, хоча відносно кореня MSys, котрий знаходиться там, де ви вирішили встановити Git у вашій Windows системі, коли ви запускали інсталяцію. +Він також все одно шукає файл `[path]/etc/gitconfig`, хоча відносно кореня MSys, котрий знаходиться там, де ви вирішили встановити Git у вашій Windows системі, коли ви запускали інсталяцію. Якщо ви використовуєте Git для Windows версії 2.x або новішу, то є також системний конфігураційний файл `C:\Documents and Settings\All Users\Application Data\Git\config` під Windows XP, і `C:\ProgramData\Git\config` під Windows Vista й новіші. Цей файл може бути зміненим лише за допомогою `git config -f <файл>` адміністратором. +Ви можете переглянути усі ваші налаштування та звідки вони надходять виконавши: + +[source,console] +---- +$ git config --list --show-origin +---- + ==== Ім'я користувача Перше, що ви повинні зробити, коли ви інсталюєте Git - це встановити ім'я користувача та адресу електронної пошти. @@ -35,13 +44,14 @@ $ git config --global user.email johndoe@example.com ---- Знову ж таки, якщо ви передаєте опцію `--global`, ці налаштування потрібно зробити тільки один раз, тоді Git завжди буде використовувати цю інформацію для всього, що ви робите у цій системі. -Якщо ви хочете, перевизначити ім'я або адресу електронної пошти для конкретних проектів, ви можете виконати цю ж команду без опції `--global` в каталозі необхідного проекту. +Якщо ви хочете, перевизначити ім'я або адресу електронної пошти для конкретних проєктів, ви можете виконати цю ж команду без опції `--global` в каталозі необхідного проєкту. Багато з графічних інструментів допомагають зробити це при першому запуску. +[[_editor]] ==== Редактор -Зараз, коли ваше ім'я вже вказано, ви можете налаштувати текстовий редактор за замовчуванням, який буде використовуватися Git при необхідності ввести повідомлення. +Зараз, коли ваше ім'я вже вказано, ви можете налаштувати типовий текстовий редактор, який буде використовуватися Git при необхідності ввести повідомлення. Якщо це не налаштовано, Git використовує типовий системний редактор. Якщо ви бажаєте використовувати інший текстовий редактор, наприклад Emacs, необхідно зробити наступне: @@ -59,20 +69,13 @@ $ git config --global core.editor emacs [source,console] ---- -$ git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -nosession" ----- - -Якщо у вас 32-бітовий редактор під 64-бітовою системою, програму буде встановлено до `C:\Program Files (x86)`: - -[source,console] ----- -$ git config --global core.editor "'C:/Program Files (x86)/Notepad++/notepad++.exe' -multiInst -nosession" +$ git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin" ---- [NOTE] ==== Vim, Emacs і Notepad++ -- це популярні текстові редактори, що їх часто використовують розробники на Unix-похідних системах (на кшталт Linux та macOS) та на Windows. -Якщо ви не знайомі з цими редакторами, можливо, вам потрібно буде знайти інструкції з налаштуванню вашого улюбленого редактора з Git. +Якщо ви використовуєте інші редактори або 32-бітові версії, ласкаво просимо знайти інструкції з налаштуванню вашого улюбленого редактора з Git у <>. ==== [WARNING] @@ -81,6 +84,19 @@ Vim, Emacs і Notepad++ -- це популярні текстові редакт Наприклад, під Windows операція Git може бути завчасно припинена під час запуску редактора. ==== +[[_new_default_branch]] +==== Типова назва гілки + +Типово, Git буде створювати гілку з назвою _master_ коли ви створюєте новий репозиторій із `git init`. +Із версії Git 2.28 і вище, ви можете налаштувати іншу назву для початкової гілки. + +Аби налаштувати _main_ як типову назву гілки, виконайте: + +[source,console] +---- +$ git config --global init.defaultBranch main +---- + ==== Перевірка налаштувань Якщо ви хочете подивитися на свої налаштування, можете скористатися командою `git config --list`, щоб переглянути всі налаштування, які Git може знайти: @@ -97,7 +113,7 @@ color.diff=auto ... ---- -Ви можете побачити ключі більш ніж один раз, тому що Git читає однакові ключі з різних файлів (наприклад `/etc/gitconfig` або `~/.gitconfig`). +Ви можете побачити ключі більш ніж один раз, тому що Git читає однакові ключі з різних файлів (наприклад, `[path]/etc/gitconfig` або `~/.gitconfig`). У цьому випадку, Git використовує останнє значення для кожного ключа. Ви також можете перевірити значення конкретного ключа виконавши `git config `:(((git commands, config))) diff --git a/update-plan/files.adoc b/update-plan/files.adoc index 3618267..ecbb383 100644 --- a/update-plan/files.adoc +++ b/update-plan/files.adoc @@ -6,7 +6,7 @@ | Назва файлу |Статус (+ означає зроблено, * означає в процесі) | book/01-introduction/sections/about-version-control.asc | + | book/01-introduction/sections/command-line.asc | + -| book/01-introduction/sections/first-time-setup.asc | +| book/01-introduction/sections/first-time-setup.asc | + | book/01-introduction/sections/help.asc | | book/01-introduction/sections/history.asc | | book/01-introduction/sections/installing.asc | From 520495b57798945bb3072daeaa5d49602fc25849 Mon Sep 17 00:00:00 2001 From: burlakvo Date: Wed, 23 Oct 2024 01:07:46 +0300 Subject: [PATCH 06/17] =?UTF-8?q?=D0=9E=D0=BD=D0=BE=D0=B2=D0=BB=D0=B5?= =?UTF-8?q?=D0=BD=D0=BD=D1=8F=20=D0=BA=D0=BE=D0=BC=D0=B0=D0=BD=D0=B4=20?= =?UTF-8?q?=D0=B2=20=D0=BF=D0=BB=D0=B0=D0=BD=D1=96?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- update-plan/plan.adoc | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/update-plan/plan.adoc b/update-plan/plan.adoc index 8fc5b61..030c662 100644 --- a/update-plan/plan.adoc +++ b/update-plan/plan.adoc @@ -16,9 +16,8 @@ // # Дивимося конфлікти // git show origin/english-version:$f > $f-old-english // git show 2.1.434:$f > $f-cur-english -// git show HEAD:$f > $f-ukrainian -// git merge-file --diff3 -p $f-ukrainian $f-old-english $f-cur-english > $f -// rm $f-ukrainian $f-old-english $f-cur-english +// git merge-file --diff3 $f $f-old-english $f-cur-english +// rm $f-old-english $f-cur-english // ---- // // Виправляємо файл і робимо PR. From 35479fcb9ab04d4371a2ee2c2d9a31c7acf0767b Mon Sep 17 00:00:00 2001 From: burlakvo Date: Wed, 23 Oct 2024 09:10:31 +0300 Subject: [PATCH 07/17] =?UTF-8?q?Revert=20"=D0=92=D0=B8=D0=BB=D1=83=D1=87?= =?UTF-8?q?=D0=B0=D1=94=20=D1=84=D0=B0=D0=B9=D0=BB=D0=B8"?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This reverts commit d9cb263674419d99bb81373feecb9be8822cabe2. --- .travis.yml | 34 ++ .../sections/client-tfs.asc | 410 ++++++++++++++++++ .../sections/import-tfs.asc | 60 +++ .../sections/eclipse.asc | 10 + update-plan/files.adoc | 8 +- 5 files changed, 518 insertions(+), 4 deletions(-) create mode 100644 .travis.yml create mode 100644 book/09-git-and-other-scms/sections/client-tfs.asc create mode 100644 book/09-git-and-other-scms/sections/import-tfs.asc create mode 100644 book/A-git-in-other-environments/sections/eclipse.asc diff --git a/.travis.yml b/.travis.yml new file mode 100644 index 0000000..cd6f15a --- /dev/null +++ b/.travis.yml @@ -0,0 +1,34 @@ +language: ruby +sudo: false +git: + depth: false +cache: bundler +before_install: + - wget https://raw.githubusercontent.com/progit/progit2-pub/master/bootstrap.sh + - sh bootstrap.sh +script: bundle exec rake book:build +after_success: bundle exec rake book:tag +deploy: + provider: releases + file_glob: true + file: + - progit*.epub + - progit*.mobi + - progit*.pdf + skip_cleanup: true + on: + tags: true + api-key: $GITHUB_API_TOKEN +branches: + only: + - master + - /^2\.1(\.\d+)+$/ + +addons: + apt: + packages: + - epubcheck +notifications: + email: + on_success: never + on_failure: always diff --git a/book/09-git-and-other-scms/sections/client-tfs.asc b/book/09-git-and-other-scms/sections/client-tfs.asc new file mode 100644 index 0000000..f68c719 --- /dev/null +++ b/book/09-git-and-other-scms/sections/client-tfs.asc @@ -0,0 +1,410 @@ +==== Git та TFS + +(((Interoperation with other VCSs, TFS))) +(((TFS)))((("TFVC", see="TFS"))) +Git популяризується серед Windows розробників і, якщо ви пишете код "під Windows", то є велика ймовірність, що ви також використовуєте Microsoft's Team Foundation Server (TFS). +TFS є набором інструментів для співпраці, що включає в себе облік дефектів, завдань, підтримку Scrum процесу та інших, перегляд коду, та контроль версій. +Є трохи плутанини: *TFS* -- це сервер, котрий має підтримку контролю коду, користуючись як Git, так і своєю власною СКВ, що має назву *TFVC* (Team Foundation Version Control). +Підтримка Git є дещо новою особливістю для TFS (починаючи з 2013 версії), тому всі інструменти, що передували цій появі, звертаються до частини версіонування коду як ``TFS'', незважаючи на те, що насправді працюють з TFVC. + +Якщо ви опинетеся в команді, котра користується TFVC, але краще б надали перевагу Git, як системі контролю версій, то для цього існує готовий проект. + +===== Який інструмент + +(((git-tf)))(((git-tfs))) +Насправді, їх є два: git-tf та git-tfs. + +Git-tfs (можна знайти за https://github.com/git-tfs/git-tfs[]) є .NET проектом та (на момент написання цього тексту) сумісний тільки з Windows. +Для роботи з Git сховищами він використовує .NET обгортку над libgit2, бібліотеко-орієнтованою реалізацією Git, що є високопродуктивною та дозволяє багато гнучкості з нутрощами Git сховища. +Libgit2 не є повною реалізацією Git, тому git-tfs використовує клієнтську командну стрічку Git для того, щоб закрити недостачу, отже, фактично, немає обмежень в тому, що ця утиліта може робити зі сховищами Git. +Її підтримка особливостей TFVC є достить зрілою через те, що вона оперує з сервером через бібліотеки Visual Studio. +Це значить, що вам потрібен доступ до цих бібліотек, що, в свою чергу означає, що потрібно встановити недавню версію Visual Studio (будь-яку редакцію, починаючи з версії 2010, включно з Express починаючи з 2012), або Visual Studio SDK. + +Git-tf (який живе за адресою https://gittf.codeplex.com[]) є Java проектом і через це може працювати на будь-якому комп'ютері з Java середовищем. +Він взаємодіє з Git сховищем через JGit (JVM реалізація Git), тобто, практично не має обмежень щодо функціональності Git. +Проте, робота TFVC не є повною, порівняно з git-tfs – немає підтримки гілок, для прикладу. + +Тому, кожен інструмент має свої сильні та слабкі сторони і є різні ситуації, коли треба надати перевагу одному над іншим. +В цій книзі ми розкриємо базове використання обох. + +[NOTE] +==== +Вам знадобиться доступ до сховища TFVC для того, щоб могти слідувати цим інструкціям. +А їх не так просто знайти, як, скажімо, сховища Git чи Subversion, тому, можливо, прийдеться створити самому. +Для цієї задачі добре підходять Codeplex (https://www.codeplex.com[]) чи Visual Studio Online (http://www.visualstudio.com[]). +==== + + +===== Ознайомлення з `git-tf` + +По-перше, як і з будь-яким іншим Git проектом, склонуймо. +Ось як це виглядає з `git-tf`: + +[source,console] +---- +$ git tf clone https://tfs.codeplex.com:443/tfs/TFS13 $/myproject/Main project_git +---- + +Перший аргумент є URL до TFVC колекцій, другий має формат `$/проект/гілка`, а третій -- це шлях до локального Git сховища, що буде створено (цей аргумент не обов'язковий). +Git-tf може працювати лише з одною гілкою одночасно; якщо ви хочете зробити чекіни (checkins) до іншої гілки TFVC, то склонуйте заново з потрібної гілки. + +Ось як створити повнофункціональний Git репозиторій: + +[source,console] +---- +$ cd project_git +$ git log --all --oneline --decorate +512e75a (HEAD, tag: TFS_C35190, origin_tfs/tfs, master) Checkin message +---- + +Це зветься _мілким_ (shallow) клоном, в тому значенні, що завантажено лише найостанніший ченджсет. +TFVC не спроектований таким чином, що кожен клієнт має повну копію історії, тому git-tf типово отримає лише останню версію, а це є значно швидшим. + +Коли ж у вас вдосталь часу, мабуть, варто клонувати всю історію проекту, за допомогою опції `--deep`: + +[source,console] +---- +$ git tf clone https://tfs.codeplex.com:443/tfs/TFS13 $/myproject/Main \ + project_git --deep +Username: domain\user +Password: +Connecting to TFS... +Cloning $/myproject into /tmp/project_git: 100%, done. +Cloned 4 changesets. Cloned last changeset 35190 as d44b17a +$ cd project_git +$ git log --all --oneline --decorate +d44b17a (HEAD, tag: TFS_C35190, origin_tfs/tfs, master) Goodbye +126aa7b (tag: TFS_C35189) +8f77431 (tag: TFS_C35178) FIRST +0745a25 (tag: TFS_C35177) Created team project folder $/tfvctest via the \ + Team Project Creation Wizard +---- + +Зверніть увагу на теґи з іменами типу `TFS_C35189`; за допомогою цієї особливості ви дізнаєтеся який Git коміт та ченджсет TFVC пов'язані між собою. +Це є хорошим відображенням, оскільки ви можете за допомогою простої команди `log` з'ясувати які з ваших комітів також також існують в TFVC. +Ці теґи не є обов'язковими (і їх насправді можна вимкнути за допомогою `git config git-tf.tag false`) – git-tf все одно зберігає реальні зв'язки коміт-ченджсет у файлі `.git/git-tf`. + + +===== Ознайомлення з `git-tfs` + +Клонування в git-tfs відбувається дещо інакше. +Погляньте: + +[source,powershell] +---- +PS> git tfs clone --with-branches \ + https://username.visualstudio.com/DefaultCollection \ + $/project/Trunk project_git +Initialized empty Git repository in C:/Users/ben/project_git/.git/ +C15 = b75da1aba1ffb359d00e85c52acb261e4586b0c9 +C16 = c403405f4989d73a2c3c119e79021cb2104ce44a +Tfs branches found: +- $/tfvc-test/featureA +The name of the local branch will be : featureA +C17 = d202b53f67bde32171d5078968c644e562f1c439 +C18 = 44cd729d8df868a8be20438fdeeefb961958b674 +---- + +Зверніть увагу на прапорець `--with-branches`. +Git-tfs має можливість створювати відповідності між гілками TFVC та Git, а цей прапорець вказує на необхідність створювати локальні Git гілки для кожної гілки TFVC. +Його використання є рекомендованим якщо ви збираєтеся робити гілки чи зливати в TFS, проте такий підхід не працюватиме з сервером старішим за TFS 2010 – до цього релізу ``гілки'' були просто теками, тому git-tfs не міг відрізнити їх від звичайних тек. + +Погляньте на результуюче Git сховище: + +[source,powershell] +---- +PS> git log --oneline --graph --decorate --all +* 44cd729 (tfs/featureA, featureA) Goodbye +* d202b53 Branched from $/tfvc-test/Trunk +* c403405 (HEAD, tfs/default, master) Hello +* b75da1a New project +PS> git log -1 +commit c403405f4989d73a2c3c119e79021cb2104ce44a +Author: Ben Straub +Date: Fri Aug 1 03:41:59 2014 +0000 + + Hello + + git-tfs-id: [https://username.visualstudio.com/DefaultCollection]$/myproject/Trunk;C16 +---- + +Маємо дві локальні гілки, `master` та `featureA`, котрі відображають стартову точку клонування (`Trunk` в іменуванні TFVC) та дочірню гілку (`featureA` в TFVC). +Ви можете бачити також, що ``віддалене сховище'' `tfs` має також кілька посилань: `default` та `featureA`, які відображають гілки TFVC. +Git-tfs робить відповідність між клонованою гілкою та `tfs/default`, а також інші отримують свої імена. + +Ще варто звернути увагу на `git-tfs-id:` рядки в повідомленнях коміту. +Замість теґів, git-tfs використовує ці позначки для зв'язку між TFVC ченджсетами та Git комітами. +З цього випливає те, що ваші Git коміти матимуть різні SHA-1 хеші до та після надсилання до TFVC. + +===== Процеси роботи Git-tf[s] + +[NOTE] +==== +Незалежно від того, яким з інстументів ви користуєтеся, налаштуйте ряд конфігураційних значень, задля уникнення неприємностей. + +[source,console] +---- +$ git config set --local core.ignorecase=true +$ git config set --local core.autocrlf=false +---- +==== + +Очевидно, далі ви б хотіли попрацювати над проектом. +TFVC та TFS мають кілька особливостей що можуть ускладнити ваш робочий процес: + +. Тематичні гілки, що не мають відображення в TFVC додають складнощів. + Стається це через *дуже* різний спосіб того, як TFVC та Git тракують гілки. +. Пам'ятайте, що TFVC дозволяє користувачам ``забирати''(checkout) файли з сервера, замикаючи їх так, що більш ніхто не зможе їх редагувати. + Звичайно, це не є перепоною для роботою з цими файлами у вашому локальному сховищі, але може стати такою, коли прийде час надсилання змін до TFVC сервера. +. TFS має концепцію ``закритих'' ??? (``gated'') чекінів, коли цикл побудова-тести має бути успішно завершеним до того, як дозволено робити чекін. + Тут використовується функція відкладених комітів ``shelve'' TFVC, яку ми тут детально не розглядатимемо. + Ви можете сфабрикувати це вручну з git-tf та git-tfs котрі мають команду `checkintool`, що знає про закриті чекіни. + +Для стислості, ми розглянемо лише щасливий шлях, що уникає більшість із згаданих нюансів. + +===== Робочий процес `git-tf` + + +Скажімо, ви виконали деяку роботу, додали кілька комітів до `master`, а тепер готові ділитися своїми доробками на TFVC сервері. +Ось наше Git сховище: + +[source,console] +---- +$ git log --oneline --graph --decorate --all +* 4178a82 (HEAD, master) update code +* 9df2ae3 update readme +* d44b17a (tag: TFS_C35190, origin_tfs/tfs) Goodbye +* 126aa7b (tag: TFS_C35189) +* 8f77431 (tag: TFS_C35178) FIRST +* 0745a25 (tag: TFS_C35177) Created team project folder $/tfvctest via the \ + Team Project Creation Wizard +---- + +Ми хочемо взяти відбиток коміту `4178a82` та надіслати його на TFVC сервер. +Насамперед, подивимося чи хтось із колег долучався до проекту з того часу, як ми востаннє з'єднувалися: + +[source,console] +---- +$ git tf fetch +Username: domain\user +Password: +Connecting to TFS... +Fetching $/myproject at latest changeset: 100%, done. +Downloaded changeset 35320 as commit 8ef06a8. Updated FETCH_HEAD. +$ git log --oneline --graph --decorate --all +* 8ef06a8 (tag: TFS_C35320, origin_tfs/tfs) just some text +| * 4178a82 (HEAD, master) update code +| * 9df2ae3 update readme +|/ +* d44b17a (tag: TFS_C35190) Goodbye +* 126aa7b (tag: TFS_C35189) +* 8f77431 (tag: TFS_C35178) FIRST +* 0745a25 (tag: TFS_C35177) Created team project folder $/tfvctest via the \ + Team Project Creation Wizard +---- + +Схоже на те, що ще хтось також працює та наші історії розійшлися. +Ось де переваги Git очевидні, але ми маємо два способи продовжувати: + +. Зробити коміт злиття здається природнім для користувача Git (зрештою, `git pull` саме це й робить), а git-tf може це виконати за допомогою `git tf pull`. + Однак, зауважте, що TFVC не мислить таким самим чином, і, якщо ви надсилаєте коміти злиття, ваша історія виглядатиме по-різному по обидві сторони, що може спантеличувати. + Проте, якщо ви збираєтеся надіслати всі свої зміни як один ченджсет, це, мабуть, найлегший спосіб. +. Перебазовування робить історію лінійною, тобто дає нам можливість перетворити кожен Git коміт на ченджсет TFVC. + Оскільки даний спосіб залишає нам найбільше можливостей потім, ми рекомендуємо саме його; git-tf підтримує цю дію за допомогою `git tf pull --rebase`. + +Вибір за вами. +У цьому прикладі ми перебазовуватимемо: + +[source,console] +---- +$ git rebase FETCH_HEAD +First, rewinding head to replay your work on top of it... +Applying: update readme +Applying: update code +$ git log --oneline --graph --decorate --all +* 5a0e25e (HEAD, master) update code +* 6eb3eb5 update readme +* 8ef06a8 (tag: TFS_C35320, origin_tfs/tfs) just some text +* d44b17a (tag: TFS_C35190) Goodbye +* 126aa7b (tag: TFS_C35189) +* 8f77431 (tag: TFS_C35178) FIRST +* 0745a25 (tag: TFS_C35177) Created team project folder $/tfvctest via the \ + Team Project Creation Wizard +---- + +Тепер ми готові до чекіну в TFVC сервер. +Git-tf дає можливість вибрати: створити один ченджсет, що представлятиме всі зміни, починаючи з останньої (`--shallow`, що є типовою поведінкою) чи створювати по ченджсету на кожен коміт (`--deep`). +Тут ми просто створимо один ченджсет: + +[source,console] +---- +$ git tf checkin -m 'Updating readme and code' +Username: domain\user +Password: +Connecting to TFS... +Checking in to $/myproject: 100%, done. +Checked commit 5a0e25e in as changeset 35348 +$ git log --oneline --graph --decorate --all +* 5a0e25e (HEAD, tag: TFS_C35348, origin_tfs/tfs, master) update code +* 6eb3eb5 update readme +* 8ef06a8 (tag: TFS_C35320) just some text +* d44b17a (tag: TFS_C35190) Goodbye +* 126aa7b (tag: TFS_C35189) +* 8f77431 (tag: TFS_C35178) FIRST +* 0745a25 (tag: TFS_C35177) Created team project folder $/tfvctest via the \ + Team Project Creation Wizard +---- + +Створився теґ `TFS_C35348`, вказуючи що TFVC має такий самий відбиток як відбиток в коміті `5a0e25e`. +Важливо зауважити, що не кожен Git коміт потребує точного відповідника в TFVC; коміт `6eb3eb5`, наприклад, ніде не існує на сервері. + +Таким є основний процес роботи. +Ось ще кілька міркувань, що варто пам'ятати: + +* Робота з гілками не підтримується. + Git-tf в змозі створити Git сховище лише з одної гілки TFVC одночасно. +* Співпрацюйте за допомогою TFVC або Git, але не за допомогою обидвох. + Різні git-tf клони одного й того ж TFVC сховища можуть мати різні SHA-1 хеші, що спричинить нескінченні головні болі. +* Якщо процес вашої команди включає в себе роботу в Git та періодичні синхронізації до TFVC, з'єднуйте до TFVC лише одне Git сховище. + +===== Робочий процес `git-tfs` + +Пройдімо такий самий сценарій з git-tfs. +Маємо нові коміти, зроблені в гілку `master` нашого Git сховища: + +[source,powershell] +---- +PS> git log --oneline --graph --all --decorate +* c3bd3ae (HEAD, master) update code +* d85e5a2 update readme +| * 44cd729 (tfs/featureA, featureA) Goodbye +| * d202b53 Branched from $/tfvc-test/Trunk +|/ +* c403405 (tfs/default) Hello +* b75da1a New project +---- + +Тепер глянемо чи хтось додав якісь зміни, поки ми тут мудрували: + +[source,powershell] +---- +PS> git tfs fetch +C19 = aea74a0313de0a391940c999e51c5c15c381d91d +PS> git log --all --oneline --graph --decorate +* aea74a0 (tfs/default) update documentation +| * c3bd3ae (HEAD, master) update code +| * d85e5a2 update readme +|/ +| * 44cd729 (tfs/featureA, featureA) Goodbye +| * d202b53 Branched from $/tfvc-test/Trunk +|/ +* c403405 Hello +* b75da1a New project +---- + +Так, виявляється, що хтось із наших колег додав TFVC ченджсет, який ми бачимо як новий коміт `aea74a0`, а віддалена гілка `tfs/default` прогресувала. + +Так само як і у випадку git-tf, ми маємо дві фундаментальні опції, щоб розв'язати цю розбіжність: + +. Перебазуватися та зберегти історію лінійною. +. Виконати злиття та зберегти що ж насправді трапилося. + +В нашому випадку ми робитимемо ``глибокий'' чекін, тобто кожен Git коміт стає ченджсетом TFVC, тому виберемо варіант з перебазовуванням. + +[source,powershell] +---- +PS> git rebase tfs/default +First, rewinding head to replay your work on top of it... +Applying: update readme +Applying: update code +PS> git log --all --oneline --graph --decorate +* 10a75ac (HEAD, master) update code +* 5cec4ab update readme +* aea74a0 (tfs/default) update documentation +| * 44cd729 (tfs/featureA, featureA) Goodbye +| * d202b53 Branched from $/tfvc-test/Trunk +|/ +* c403405 Hello +* b75da1a New project +---- + +Тепер ми готові завершити наш вклад, зачекінивши код до TFVC серверу. +Будемо використовувати команду `rcheckin` для того, щоб створювався TFVC ченджсет на кожен Git коміт від HEAD до першого віддаленого посилання `tfs` (команда `checkin` створила б просто один ченджсет, щось типу того як працює зчавлення (squashing) комітів). + +[source,powershell] +---- +PS> git tfs rcheckin +Working with tfs remote: default +Fetching changes from TFS to minimize possibility of late conflict... +Starting checkin of 5cec4ab4 'update readme' + add README.md +C20 = 71a5ddce274c19f8fdc322b4f165d93d89121017 +Done with 5cec4ab4b213c354341f66c80cd650ab98dcf1ed, rebasing tail onto new TFS-commit... +Rebase done successfully. +Starting checkin of b1bf0f99 'update code' + edit .git\tfs\default\workspace\ConsoleApplication1/ConsoleApplication1/Program.cs +C21 = ff04e7c35dfbe6a8f94e782bf5e0031cee8d103b +Done with b1bf0f9977b2d48bad611ed4a03d3738df05ea5d, rebasing tail onto new TFS-commit... +Rebase done successfully. +No more to rcheckin. +PS> git log --all --oneline --graph --decorate +* ff04e7c (HEAD, tfs/default, master) update code +* 71a5ddc update readme +* aea74a0 update documentation +| * 44cd729 (tfs/featureA, featureA) Goodbye +| * d202b53 Branched from $/tfvc-test/Trunk +|/ +* c403405 Hello +* b75da1a New project +---- + +Зверніть увагу на те, як після кожного успішного чекіна до TFVC сервера, git-tfs перебазовує залишкові зміни поверх щойно зробленого. +Це тому, що додається поле `git-tfs-id` в кінці повідомлення коміту, і це змінює SHA-1 хеші. +Так і було задумано, не потрібно хвилюватися з цього приводу, просто вам потрібно знати, що це відбувається; особливо, якщо ви ділитеся ідентифікаторами Git комітів з іншими. + +TFS має багато особливостей для інтеграції зі своєю системою контролю версій, такі як одиниці роботи (work items), переглядальники коду, закриті (gated) чекіни тощо. +Опанувати їх всіх з командного рядка може бути досить хвацькою задачею, але, на щастя, git-tfs має досить швидкий доступ і до більш візуальних інструментів чекіну: + +[source,powershell] +---- +PS> git tfs checkintool +PS> git tfs ct +---- + +Виглядає це якось так: + +.Інструмент чекіну git-tfs. +image::images/git-tfs-ct.png[Інструмент чекіну git-tfs.] + +Це виглядатиме звичним для користувачів TFS, оскільки це той самий діалог, що запускається у Visual Studio. + +Git-tfs також дає можливість керувати гілками TFVC з Git сховища. +Для прикладу, створимо гілку: + +[source,powershell] +---- +PS> git tfs branch $/tfvc-test/featureBee +The name of the local branch will be : featureBee +C26 = 1d54865c397608c004a2cadce7296f5edc22a7e5 +PS> git log --oneline --graph --decorate --all +* 1d54865 (tfs/featureBee) Creation branch $/myproject/featureBee +* ff04e7c (HEAD, tfs/default, master) update code +* 71a5ddc update readme +* aea74a0 update documentation +| * 44cd729 (tfs/featureA, featureA) Goodbye +| * d202b53 Branched from $/tfvc-test/Trunk +|/ +* c403405 Hello +* b75da1a New project +---- + +Створення гілки в TFVC означає додавання ченджсету до гілки, що вже існує, і це відображено окремим комітом Git. +Також, зверніть увагу, що git-tfs *створив* віддалену гілку `tfs/featureBee`, але `HEAD` досі вказує на `master`. +Якщо вам кортить попрацювати з щойно створеною гілкою, потрібно базувати свої нові коміти на коміті `1d54865`, можливо, створивши тематичну гілку з цього коміту. + +===== Git та TFS. Підсумок + +Обидві Git-tf та Git-tfs є чудовими інструментами для доступу до сервера TFVC та роботи з ним. +Вони дають вам локальну могутність Git, уникають постійних мандрів мережею до центрального сервера TFVC, та спрощують ваше розробницьке життя, без необхідності переходу на Git цілою командою. +Якщо ви працюєте з Windows (що дуже ймовірно, коли користуєтеся TFS), то вам, мабуть, більше захочеться обрати git-tfs, через більш повний набір особливостей, а у випадку іншої платформи, ви користуватиметеся git-tf, яка є більш обмеженою. +Як і з більшістю інструментів цього розділу, вам потрібно обрати одну з систем контролю версій, яка буде основною, а іншу використовувати ніби підлеглу – будь це Git чи TFVC, потрібно обрати один центр для співпраці, не обидва. diff --git a/book/09-git-and-other-scms/sections/import-tfs.asc b/book/09-git-and-other-scms/sections/import-tfs.asc new file mode 100644 index 0000000..e58827f --- /dev/null +++ b/book/09-git-and-other-scms/sections/import-tfs.asc @@ -0,0 +1,60 @@ +[[_git_tfs]] +==== TFS + +(((TFS)))(((Importing, from TFS))) +Якщо ваша команда переходить від керування кодом за допомогою TFVC до Git, то ви забажаєте конвертацію найвищої якості з тих, які вам доступні. +Це означає, що хоча ми розглянули й git-tfs і git-tf у секції взаємодії, тут ми розглянемо лише git-tfs, оскільки він підтримує гілки, та здійснити це за допомогою git-tf неприйнятно складно. + +[NOTE] +==== +Це однобічна конвертація. +Отримане сховище Git не буде в змозі взаємодіяти з оригінальним проектом TFVC. +==== + +Спершу треба встановити відображення імен користувачів. +TFVC доволі ліберальний щодо того, що може бути в полі автора для набору змін, проте Git бажає читабельне ім’я та поштову адресу. +Ви можете отримати цю інформацію з консольного клієнта `tf` ось так: + +[source,powershell] +---- +PS> tf history $/myproject -recursive > AUTHORS_TMP +---- + +Ця команда отримує всі набори змін в історії проекту та кладе їх у файл AUTHORS_TMP, з якого ми отримаємо дані зі стовпчика 'User' (другого). +Відкрийте файл та з’ясуйте з якого символу починається та на якому закінчується стовпчик, та замініть у наступній команді параметри `11-20` команди `cut` своїми значеннями: + +[source,powershell] +---- +PS> cat AUTHORS_TMP | cut -b 11-20 | tail -n+3 | sort | uniq > AUTHORS +---- + +Команда `cut` залишає лише символи між 11 та 20 кожного рядка. +Команда `tail` ігнорує перші два рядки, що є заголовками та лінією ASCII-арт. +Результат пропускається через `sort` і `uniq`, щоб позбутися дублікатів, та зберігається у файлі `AUTHORS`. +Далі треба попрацювати вручну; щоб git-tfs зміг ефективно використати цей файл, кожен рядок має бути у форматі: + +[source,text] +---- +DOMAIN\username = User Name +---- + +Частина ліворуч -- це поле ``User'' з TFVC, а частина праворуч від знаку дорівнює -- це ім’я користувача, яке використовуватиметься для комітів Git. + +Щойно у вас є такий файл, можна робити повний клон проекту TFVC, який вам потрібен: + +[source,powershell] +---- +PS> git tfs clone --with-branches --authors=AUTHORS https://username.visualstudio.com/DefaultCollection $/project/Trunk project_git +---- + +Далі ви забажаєте прибрати секції `git-tfs-id` наприкінці повідомлень комітів. +Це зробить наступна команда: + +[source,powershell] +---- +PS> git filter-branch -f --msg-filter 'sed "s/^git-tfs-id:.*$//g"' '--' --all +---- + +Вона використовує команду `sed` з середовища Git-bash, щоб замінити будь-який рядок, що починається з ``git-tfs-id:'', порожнечею, яку потім проігнорує Git. + +Коли все це зроблено, ви готові додати нове віддалене сховище, надіслати туди всі свої гілки, та команда може розпочати роботу з Git. diff --git a/book/A-git-in-other-environments/sections/eclipse.asc b/book/A-git-in-other-environments/sections/eclipse.asc new file mode 100644 index 0000000..80e0da3 --- /dev/null +++ b/book/A-git-in-other-environments/sections/eclipse.asc @@ -0,0 +1,10 @@ +=== Git в Eclipse + +(((Eclipse))) +Git постачає додаток під назвою Egit, який надає доволі повний інтерфейс до операцій Git. +Щоб отримати до нього доступ, треба переключитись на перспективу Git (Window > Open Perspective > Other…, та вибрати "Git"). + +.Середовище EGit в Eclipse. +image::images/egit.png[Середовище EGit в Eclipse.] + +EGit має багацько чудової документації, яку ви можете знайти, якщо перейдете до Help > Help Contents, та виберете "EGit Documentation" зі списку. diff --git a/update-plan/files.adoc b/update-plan/files.adoc index ecbb383..d43c293 100644 --- a/update-plan/files.adoc +++ b/update-plan/files.adoc @@ -101,10 +101,10 @@ Вилучені файли: -* + book/A-git-in-other-environments/sections/eclipse.asc -* + book/09-git-and-other-scms/sections/client-tfs.asc -* + .travis.yml -* + book/09-git-and-other-scms/sections/import-tfs.asc +* book/A-git-in-other-environments/sections/eclipse.asc +* book/09-git-and-other-scms/sections/client-tfs.asc +* .travis.yml +* book/09-git-and-other-scms/sections/import-tfs.asc Додані і нами (для того, щоб генерація працювала), і ними: From b6ad115cc14d00c8d2ba6ca108a141e01f093ec9 Mon Sep 17 00:00:00 2001 From: burlakvo Date: Wed, 23 Oct 2024 09:22:07 +0300 Subject: [PATCH 08/17] =?UTF-8?q?=D0=94=D0=BE=D0=B4=D0=B0=D1=94=20=D0=B2?= =?UTF-8?q?=D1=96=D0=B4=D1=81=D1=83=D1=82=D0=BD=D1=96=20=D1=96=D0=BD=D0=B4?= =?UTF-8?q?=D0=B5=D0=BA=D1=81=D0=B8?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- book/01-introduction/sections/about-version-control.asc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/01-introduction/sections/about-version-control.asc b/book/01-introduction/sections/about-version-control.asc index f204975..49106fa 100755 --- a/book/01-introduction/sections/about-version-control.asc +++ b/book/01-introduction/sections/about-version-control.asc @@ -30,7 +30,7 @@ https://www.gnu.org/software/rcs/[RCS^] зберігає набори латок (((version control,centralized))) Наступним важливим питанням, з яким стикаються люди, є необхідність співпрацювати з іншими розробниками. Щоб справитися з цією проблемою, були розроблені централізовані системи контролю версій (ЦСКВ). -Ці системи (такі як CVS, Subversion і Perforce) мають єдиний сервер, який містить всі версії файлів, та деяке число клієнтів, які отримують файли з центрального місця. +Ці системи (такі як CVS, Subversion і Perforce) мають єдиний сервер, який містить всі версії файлів, та деяке число клієнтів, які отримують файли з центрального місця.(((CVS)))(((Subversion)))(((Perforce))) Протягом багатьох років, це було стандартом для систем контролю версій. .Діаграма централізованих систем контролю версій. From 29e5981ad49b2e9d17c518c2a6e792ec7c1b57c8 Mon Sep 17 00:00:00 2001 From: burlakvo Date: Wed, 23 Oct 2024 09:49:01 +0300 Subject: [PATCH 09/17] =?UTF-8?q?=D0=94=D0=BE=D0=B4=D0=B0=D1=94=20conflict?= =?UTF-8?q?style=20=D0=BF=D0=BE=D1=80=D0=B0=D0=B4=D1=83=20=D0=B2=20=D0=BF?= =?UTF-8?q?=D0=BB=D0=B0=D0=BD?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- update-plan/plan.adoc | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/update-plan/plan.adoc b/update-plan/plan.adoc index 030c662..f0ca616 100644 --- a/update-plan/plan.adoc +++ b/update-plan/plan.adoc @@ -7,6 +7,13 @@ Спробував залити `2.1.434` до `master`, список файлів з конфліктами у `files.adoc`. +Перевірте, чи у вас налаштовано `merge.conflictstyle` як `diff3`. +Якщо ні, то не забудьте додати опцію `--diff3` до команди `merge-file` у скрипті нижче, або виконайте наступну команду: + +```bash +git config --global merge.conflictstyle diff3 +``` + // Пропонований порядок роботи (продемонстрований на `book/01-introduction/sections/about-version-control.asc`): // // Спершу отримаємо всі версії цього файлу: @@ -16,7 +23,7 @@ // # Дивимося конфлікти // git show origin/english-version:$f > $f-old-english // git show 2.1.434:$f > $f-cur-english -// git merge-file --diff3 $f $f-old-english $f-cur-english +// git merge-file $f $f-old-english $f-cur-english // rm $f-old-english $f-cur-english // ---- // From a2d9f9e0e9c6bb31cee6074577fec77faf423976 Mon Sep 17 00:00:00 2001 From: burlakvo Date: Sat, 23 Nov 2024 22:52:53 +0200 Subject: [PATCH 10/17] =?UTF-8?q?=D0=9E=D0=BD=D0=BE=D0=B2=D0=BB=D1=8E?= =?UTF-8?q?=D1=94:=201=20-=20about-version-control.asc?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Вивірення перекладу, застосування узгоджених термінів, інші правки --- .../sections/about-version-control.asc | 24 +++++++++---------- 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/book/01-introduction/sections/about-version-control.asc b/book/01-introduction/sections/about-version-control.asc index 49106fa..3150a52 100755 --- a/book/01-introduction/sections/about-version-control.asc +++ b/book/01-introduction/sections/about-version-control.asc @@ -3,19 +3,19 @@ (((version control))) Що таке "`система контролю версій`", і чому це важливо? Система контролю версій - це система, що записує зміни у файл або набір файлів протягом деякого часу, так що ви зможете повернутися до певної версії пізніше. -Як приклад, в цій книзі, для файлів, що знаходяться під контролем версій, буде використовуватися код програмного забезпечення, хоча насправді ви можете використовувати контроль версій практично для будь-яких типів файлів. +Для прикладів в цій книзі, як файли, що знаходяться під контролем версій, буде використано код програмного забезпечення, хоча, насправді, ви можете використовувати контроль версій практично для будь-яких типів файлів. Якщо ви графічний або веб-дизайнер і хочете зберегти кожну версію зображення або макета (швидше за все, захочете), система контролю версій (далі СКВ) якраз те, що потрібно. -Вона дозволяє повернути вибрані файли до попереднього стану, повернути весь проєкт до попереднього стану, побачити зміни, побачити, хто останній міняв щось і спровокував проблему, хто вказав на проблему і коли, та багато іншого. +Вона дозволяє вивернути вибрані файли до попереднього стану, вивернути весь проєкт до попереднього стану, побачити зміни, побачити, хто останній міняв щось і спровокував проблему, хто вказав на проблему і коли, та багато іншого. Використання СКВ також в цілому означає, що, якщо ви зламали щось або втратили файли, ви просто можете все виправити. Крім того, ви отримаєте все це за дуже невеликі накладні витрати. ==== Локальні системи контролю версій (((version control,local))) -Багато людей в якості одного з методів контролю версій застосовують копіювання файлів в окрему директорію (можливо навіть директорію з відміткою за часом, якщо вони достатньо розумні). +Багато людей в якості одного з методів контролю версій застосовують копіювання файлів в окрему теку (можливо, навіть теку з відміткою за часом, якщо вони достатньо розумні). Даний підхід є дуже поширеним завдяки його простоті, проте він, неймовірним чином, схильний до появи помилок. -Можна легко забути в якій директорії ви знаходитеся і випадково змінити не той файл або скопіювати не ті файли, які ви хотіли. +Можна легко забути в якій теці ви знаходитеся і випадково змінити не той файл або скопіювати не ті файли, які ви хотіли. Щоб справитися з цією проблемою, програмісти давно розробили локальні СКВ, що мають просту базу даних, яка зберігає всі зміни в файлах під контролем версій. @@ -23,7 +23,7 @@ image::images/local.png[Local version control diagram] Одним з найбільш поширених інструментів СКВ була система під назвою RCS, яка досі поширюється з багатьма комп'ютерами сьогодні. -https://www.gnu.org/software/rcs/[RCS^] зберігає набори латок (тобто, відмінності між файлами) в спеціальному форматі на диску; він може заново відтворити будь-який файл, як він виглядав, в будь-який момент часу, шляхом додавання всіх латок. +https://www.gnu.org/software/rcs/[RCS^] зберігає набори латок (тобто, різницю між файлами) в спеціальному форматі на диску; вона може заново відтворити стан будь-якого файлу у будь-який момент часу, шляхом додавання всіх латок. ==== Централізовані системи контролю версій @@ -43,19 +43,19 @@ image::images/centralized.png[Centralized version control diagram] Але цей підхід також має деякі серйозні недоліки. Найбільш очевидним є єдина точка відмови, яким є централізований сервер. Якщо сервер виходить з ладу протягом години, то протягом цієї години ніхто не може співпрацювати або зберігати зміни над якими вони працюють під версійним контролем. -Якщо жорсткий диск центральної бази даних на сервері пошкоджено, і своєчасні резервні копії не були зроблені, ви втрачаєте абсолютно все -- всю історію проєкту, крім одиночних знімків проєкту, що збереглися на локальних машинах людей. +Якщо жорсткий диск центральної бази даних на сервері пошкоджено, і своєчасні резервні копії не були зроблені, ви втрачаєте абсолютно все -- всю історію проєкту, крім поодиноких відбитків проєкту, що збереглися на локальних машинах людей. Локальні СКВ страждають тією ж проблемою -- щоразу, коли вся історія проєкту зберігається в одному місці, ви ризикуєте втратити все. -==== Децентралізовані системи контролю версій +==== Розподілені системи контролю версій (((version control,distributed))) -Долучаються до гри децентралізовані системи контролю версій (ДСКВ). -В ДСКВ (таких як, Git, Mercurial або Darcs), клієнти не просто отримують останній знімок файлів репозиторія: натомість вони є повною копією сховища разом з усією його історією. -Таким чином, якщо вмирає який-небудь сервер, через який співпрацюють розробники, будь-який з клієнтських репозиторіїв може бути скопійований назад до серверу, щоб відновити його. -Кожна копія дійсно є повною резервною копією всіх даних. +Ось тут до гри долучаються розподілені системи контролю версій (РСКВ). +В РСКВ (таких як, Git, Mercurial або Darcs), клієнти не просто отримують останній відбиток файлів репозиторія: натомість вони є повною копією сховища разом з усією його історією. +Таким чином, якщо вмирає який-небудь сервер, через який співпрацюють розробники, будь-яке з клієнтських сховищ може бути скопійований назад до серверу, щоб відновити його. +Кожна копія являє собою повну резервну копію всіх даних. .Діаграма децентралізованих систем контролю версій. image::images/distributed.png[Distributed version control diagram] -Більш того, багато з цих систем дуже добре взаємодіють з декількома віддаленими репозиторіями, так що ви можете співпрацювати з різними групами людей, застосовуючи різні підходи в межах одного проєкту одночасно. +Більш того, багато з цих систем дуже добре взаємодіють з декількома віддаленими сховищами, так що ви можете співпрацювати з різними групами людей, застосовуючи різні підходи в межах одного проєкту одночасно. Це дозволяє налаштувати декілька типів робочих процесів, таких як ієрархічні моделі, які неможливі в централізованих системах. From 87db386a348d3723cae6fc18c3c7c7caa7545748 Mon Sep 17 00:00:00 2001 From: burlakvo Date: Sat, 23 Nov 2024 22:59:15 +0200 Subject: [PATCH 11/17] =?UTF-8?q?=D0=9E=D0=BD=D0=BE=D0=B2=D0=BB=D1=8E?= =?UTF-8?q?=D1=94:=201=20-=20command-line.asc?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Невеликі правки --- book/01-introduction/sections/command-line.asc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/book/01-introduction/sections/command-line.asc b/book/01-introduction/sections/command-line.asc index 9f499c5..50d6b09 100755 --- a/book/01-introduction/sections/command-line.asc +++ b/book/01-introduction/sections/command-line.asc @@ -1,10 +1,10 @@ === Командний рядок Є багато різних варіантів використання Git. -Крім оригінальних клієнтів командного рядка, є безліч клієнтів з графічним інтерфейсом користувача з різними можливостями. +Крім оригінальних клієнтів командного рядка, є безліч клієнтів з графічним інтерфейсом користувача із різними можливостями. Для цієї книги ми будемо використовувати Git в командному рядку. З одного боку, командний рядок -- єдине місце, де можна виконувати _всі_ команди Git -- більшість графічних інтерфейсів для простоти реалізують тільки деяку підмножину функціональності Git. -Якщо ви знаєте, як виконати щось з командного рядка, ви, ймовірно, також можете з'ясувати, як виконати це і графічному інтерфейсі, у той час як зворотне не завжди вірно. +Якщо ви знаєте, як виконати щось з командного рядка, ви, ймовірно, також можете з'ясувати, як виконати це і у графічному інтерфейсі, у той час як зворотне не завжди вірно. Крім того, в той час, як вибір графічного клієнта справа особистого смаку, інструменти командного рядка мають _усі_ користувачі одразу ж після інсталяції. Таким чином, ми очікуємо, що ви знаєте, як відкрити термінал в macOS або командний рядок чи PowerShell у Windows. From e907fffbe79a4ca6821a1086e48f5e8f8e727b74 Mon Sep 17 00:00:00 2001 From: burlakvo Date: Sun, 24 Nov 2024 10:10:49 +0200 Subject: [PATCH 12/17] =?UTF-8?q?=D0=9E=D0=BD=D0=BE=D0=B2=D0=BB=D1=8E?= =?UTF-8?q?=D1=94:=201=20-=20first-time-setup.asc?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Вивірення перекладу, застосування узгоджених термінів, інші правки --- .../sections/first-time-setup.asc | 39 +++++++++---------- 1 file changed, 19 insertions(+), 20 deletions(-) diff --git a/book/01-introduction/sections/first-time-setup.asc b/book/01-introduction/sections/first-time-setup.asc index b48fdf1..1048b27 100755 --- a/book/01-introduction/sections/first-time-setup.asc +++ b/book/01-introduction/sections/first-time-setup.asc @@ -1,28 +1,27 @@ [[_first_time]] === Початкове налаштування Git -Зараз, коли у ви вже маєте Git у системі, можливо, ви захочете зробити декілька речей, щоб налаштувати ваше Git середовище. +Зараз, коли ви вже маєте Git у системі, можливо, ви захочете зробити декілька речей, щоб налаштувати ваше середовище Git. Це потрібно виконати лише один раз - налаштування залишаються між оновленнями. Ви також можете змінити їх у будь-який час, знову виконавши декілька команд. -До Git входить утиліта що має назву `git config`, яка дозволяє отримати чи встановити параметри, що контролюють усіма аспектами того, як Git виглядає чи працює. +До Git входить утиліта що має назву `git config`, яка дозволяє отримати чи встановити параметри, що контролюють усіма аспектами того, як Git виглядає чи працює.(((git commands, config))) Ці параметри можуть бути збережені в трьох різних місцях: -1. Файл `[path]/etc/gitconfig` містить значення для кожного користувача в системі і всіх їхніх репозиторіїв. +1. Файл `[path]/etc/gitconfig` містить значення для кожного користувача в системі та всіх їхніх сховищ. Якщо ви передаєте опцію `--system` при виконанні `git config`, параметри читаються та пишуться з цього файлу. - Це системний файл конфігурації, відповідно, вам потрібен був доступ адміністратора чи суперкористувача, щоб змінювати його. + Оскільки це системний файл конфігурації, відповідно, вам знадобяться права адміністратора чи суперкористувача, щоб змінювати його. 2. Файл `~/.gitconfig` або `~/.config/git/config` зберігає значення саме для вас -- користувача. - Ви можете налаштувати Git читати і писати в цей файл, вказуючи опцію `--global`, що вплине на _всі_ репозиторії з якими ви працюєте у вашій системі. -3. Файл `config` у каталозі Git (тобто `.git/config`) у тому репозиторії, який ви використовуєте в даний момент, зберігає налаштування конкретного репозиторія. - Ви можете змусити Git читати і писати в цей файл, вказавши опцію `--local`, але типово вона увімкнута. - Звісно, ви маєте бути десь у репозиторії Git аби ця опція працювала правильно. + Ви можете спрямувати Git читати і писати в цей файл, передавши опцію `--global`, що вплине на _всі_ сховища з якими ви працюєте у вашій системі. +3. Файл `config` у теці Git (тобто `.git/config`) у тому сховищі, яке ви використовуєте в даний момент, зберігає налаштування цього конкретного сховища. + Ви можете змусити Git читати і писати в цей файл, вказавши опцію `--local`, але типово використовується саме вона. + Звісно, ви маєте бути десь у сховищі Git аби ця опція працювала правильно. Кожен рівень має пріоритет над налаштуваннями в попередньому рівні, тобто параметри в `.git/config` перевизначають параметри в `[path]/etc/gitconfig`. -У системах Windows, Git шукає файл `.gitconfig` в каталозі `$HOME` (`C:\Users\$USER` для більшості користувачів). -Він також все одно шукає файл `[path]/etc/gitconfig`, хоча відносно кореня MSys, котрий знаходиться там, де ви вирішили встановити Git у вашій Windows системі, коли ви запускали інсталяцію. -Якщо ви використовуєте Git для Windows версії 2.x або новішу, то є також системний конфігураційний файл -`C:\Documents and Settings\All Users\Application Data\Git\config` під Windows XP, і `C:\ProgramData\Git\config` під Windows Vista й новіші. +У системах Windows, Git шукає файл `.gitconfig` у теці `$HOME` (`C:\Users\$USER` для більшості користувачів). +Також, він все одно шукає файл `[path]/etc/gitconfig`, хоча й відносно кореня MSys, котрий знаходиться там, де ви вирішили встановити Git у вашій Windows системі, коли ви запускали інсталяцію. +Якщо ви використовуєте Git для Windows версії 2.x або новішу, то є також системний конфігураційний файл `C:\Documents and Settings\All Users\Application Data\Git\config` під Windows XP, і `C:\ProgramData\Git\config` під Windows Vista й новіші. Цей файл може бути зміненим лише за допомогою `git config -f <файл>` адміністратором. Ви можете переглянути усі ваші налаштування та звідки вони надходять виконавши: @@ -34,8 +33,8 @@ $ git config --list --show-origin ==== Ім'я користувача -Перше, що ви повинні зробити, коли ви інсталюєте Git - це встановити ім'я користувача та адресу електронної пошти. -Це важливо, тому що кожен коміт в Git використовує цю інформацію, і вона незмінно включена у комміти, які ви робите: +Перше, що ви повинні зробити, коли ви інсталюєте Git -- це встановити ім'я користувача та адресу електронної пошти. +Це важливо, тому що кожен коміт в Git використовує цю інформацію, і вона незмінно включена у коміти, які ви робите: [source,console] ---- @@ -43,8 +42,8 @@ $ git config --global user.name "John Doe" $ git config --global user.email johndoe@example.com ---- -Знову ж таки, якщо ви передаєте опцію `--global`, ці налаштування потрібно зробити тільки один раз, тоді Git завжди буде використовувати цю інформацію для всього, що ви робите у цій системі. -Якщо ви хочете, перевизначити ім'я або адресу електронної пошти для конкретних проєктів, ви можете виконати цю ж команду без опції `--global` в каталозі необхідного проєкту. +Знову ж таки, якщо ви передаєте опцію `--global`, ці налаштування потрібно зробити тільки один раз, бо тоді Git завжди буде використовувати цю інформацію для всього, що ви робите у цій системі. +Якщо ви хочете перевизначити ім'я або адресу електронної пошти для конкретних проєктів, ви можете виконати цю ж команду без опції `--global` в теці необхідного проєкту. Багато з графічних інструментів допомагають зробити це при першому запуску. @@ -52,7 +51,7 @@ $ git config --global user.email johndoe@example.com ==== Редактор Зараз, коли ваше ім'я вже вказано, ви можете налаштувати типовий текстовий редактор, який буде використовуватися Git при необхідності ввести повідомлення. -Якщо це не налаштовано, Git використовує типовий системний редактор. +Якщо це не налаштовано, Git буде використовувати типовий системний редактор. Якщо ви бажаєте використовувати інший текстовий редактор, наприклад Emacs, необхідно зробити наступне: @@ -61,8 +60,8 @@ $ git config --global user.email johndoe@example.com $ git config --global core.editor emacs ---- -Під Windows, якщо ви бажаєте використати інший текстовий редактор, то маєте вказати повний шлях до відповідної програми. -Це залежить від того, як ваш редактор поставляється. +Під Windows, якщо ви бажаєте використати інший текстовий редактор, то маєте вказати повний шлях до його виконуваного файлу. +Він може різнитися залежно від того, як ваш редактор поставляється. У випадку Notepad++ -- популярного редактору коду -- ви напевно надасте перевагу 32-бітовій версії, адже на час написання цього тексу 64-бітова версія не підтримувала всіх додатків. Якщо у вас 32-бітова система, чи у вас 64-бітова система і ви хочете використовувати 64-бітовий редактор, варто спробувати щось таке: @@ -87,7 +86,7 @@ Vim, Emacs і Notepad++ -- це популярні текстові редакт [[_new_default_branch]] ==== Типова назва гілки -Типово, Git буде створювати гілку з назвою _master_ коли ви створюєте новий репозиторій із `git init`. +Типово, Git буде створювати гілку з назвою _master_ коли ви створюєте нове сховище із `git init`. Із версії Git 2.28 і вище, ви можете налаштувати іншу назву для початкової гілки. Аби налаштувати _main_ як типову назву гілки, виконайте: From 20bb0bed1b8be5d735b3b4d8c48cdce2d4e1ed2f Mon Sep 17 00:00:00 2001 From: burlakvo Date: Sun, 24 Nov 2024 10:13:02 +0200 Subject: [PATCH 13/17] =?UTF-8?q?=D0=92=D0=B8=D0=BF=D1=80=D0=B0=D0=B2?= =?UTF-8?q?=D0=BB=D1=8F=D1=94=20TRANSLATION=5FNOTES.asc?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Форматування та друкарська помилка --- TRANSLATION_NOTES.asc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/TRANSLATION_NOTES.asc b/TRANSLATION_NOTES.asc index c9fa6aa..c52f552 100644 --- a/TRANSLATION_NOTES.asc +++ b/TRANSLATION_NOTES.asc @@ -37,7 +37,7 @@ *checkout, to (file) http://github.com/progit/progit2-uk/issues/136[#136]*:: отримати (файл) *cherry-pick, to cherry-pick http://github.com/progit/progit2-uk/issues/134[#134]*:: висмикування, висмикнути *command line*:: командний рядок -*commit, to commit, comitted, commiter http://github.com/progit/progit2-uk/issues/135[#135]*:: коміт, створювати коміт, збережене в коміті, творець коміту +*commit, to commit, committed, commiter http://github.com/progit/progit2-uk/issues/135[#135]*:: коміт, створювати коміт, збережене в коміті, творець коміту *community*:: спільнота *continuous integration*:: безперервна інтеграція (http://uk.wikipedia.org/wiki/Безперервна_інтеграція[вікі]) *dashboard*:: дошка керування @@ -57,7 +57,7 @@ *fetch http://github.com/progit/progit2-uk/issues/140[#140]*:: здобути зміни *filter-branch http://github.com/progit/progit2-uk/issues/141[#141]*:: фільтрація гілки *folder http://github.com/progit/progit2-uk/issues/138[#138]*:: тека -*force (push) http://github.com/progit/progit2-uk/issues/142[#142]*::: примусове (надсилання змін) +*force (push) http://github.com/progit/progit2-uk/issues/142[#142]*:: примусове (надсилання змін) *fork, to fork, forking http://github.com/progit/progit2-uk/issues/143[#143]*:: відсадок, відсаджувати, відсадження *Git*:: Git (не транслітерується) *GUI*:: графічний інтерфейс From ff15762d03f27eb66450931939bfc7540be221e9 Mon Sep 17 00:00:00 2001 From: burlakvo Date: Sun, 24 Nov 2024 10:21:19 +0200 Subject: [PATCH 14/17] =?UTF-8?q?=D0=9F=D0=BE=D0=B7=D0=BD=D0=B0=D1=87?= =?UTF-8?q?=D0=B0=D1=94=20=D1=84=D0=B0=D0=B9=D0=BB=D0=B8=20=D0=B2=20=D0=BF?= =?UTF-8?q?=D0=BB=D0=B0=D0=BD=D1=96=20=D0=B7=D1=96=D1=80=D0=BA=D0=BE=D1=8E?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- update-plan/files.adoc | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/update-plan/files.adoc b/update-plan/files.adoc index d43c293..1312d7f 100644 --- a/update-plan/files.adoc +++ b/update-plan/files.adoc @@ -7,10 +7,10 @@ | book/01-introduction/sections/about-version-control.asc | + | book/01-introduction/sections/command-line.asc | + | book/01-introduction/sections/first-time-setup.asc | + -| book/01-introduction/sections/help.asc | -| book/01-introduction/sections/history.asc | -| book/01-introduction/sections/installing.asc | -| book/01-introduction/sections/what-is-git.asc | +| book/01-introduction/sections/help.asc | * by Oleh (burlakvo) +| book/01-introduction/sections/history.asc | * by Oleh (burlakvo) +| book/01-introduction/sections/installing.asc | * by Oleh (burlakvo) +| book/01-introduction/sections/what-is-git.asc | * by Oleh (burlakvo) | book/02-git-basics/sections/aliases.asc | * by Eugene (dev99problems) | book/02-git-basics/sections/getting-a-repository.asc | * by Eugene (dev99problems) | book/02-git-basics/sections/recording-changes.asc | * by Eugene (dev99problems) From e123ce229ad0e6068ac37bead89ce3e925326d85 Mon Sep 17 00:00:00 2001 From: burlakvo Date: Mon, 25 Nov 2024 23:04:45 +0200 Subject: [PATCH 15/17] =?UTF-8?q?=D0=9D=D0=B5=D0=B7=D0=BD=D0=B0=D1=87?= =?UTF-8?q?=D0=BD=D1=96=20=D0=B2=D0=B8=D0=BF=D1=80=D0=B0=D0=B2=D0=BB=D0=B5?= =?UTF-8?q?=D0=BD=D0=BD=D1=8F?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- book/01-introduction/sections/about-version-control.asc | 2 +- book/01-introduction/sections/first-time-setup.asc | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/book/01-introduction/sections/about-version-control.asc b/book/01-introduction/sections/about-version-control.asc index 3150a52..f7a9c4b 100755 --- a/book/01-introduction/sections/about-version-control.asc +++ b/book/01-introduction/sections/about-version-control.asc @@ -6,7 +6,7 @@ Для прикладів в цій книзі, як файли, що знаходяться під контролем версій, буде використано код програмного забезпечення, хоча, насправді, ви можете використовувати контроль версій практично для будь-яких типів файлів. Якщо ви графічний або веб-дизайнер і хочете зберегти кожну версію зображення або макета (швидше за все, захочете), система контролю версій (далі СКВ) якраз те, що потрібно. -Вона дозволяє вивернути вибрані файли до попереднього стану, вивернути весь проєкт до попереднього стану, побачити зміни, побачити, хто останній міняв щось і спровокував проблему, хто вказав на проблему і коли, та багато іншого. +Вона дозволяє повернути вибрані файли до попереднього стану, повернути весь проєкт до попереднього стану, побачити зміни, побачити, хто останній міняв щось і спровокував проблему, хто вказав на проблему і коли, та багато іншого. Використання СКВ також в цілому означає, що, якщо ви зламали щось або втратили файли, ви просто можете все виправити. Крім того, ви отримаєте все це за дуже невеликі накладні витрати. diff --git a/book/01-introduction/sections/first-time-setup.asc b/book/01-introduction/sections/first-time-setup.asc index 1048b27..a688f0d 100755 --- a/book/01-introduction/sections/first-time-setup.asc +++ b/book/01-introduction/sections/first-time-setup.asc @@ -21,7 +21,7 @@ У системах Windows, Git шукає файл `.gitconfig` у теці `$HOME` (`C:\Users\$USER` для більшості користувачів). Також, він все одно шукає файл `[path]/etc/gitconfig`, хоча й відносно кореня MSys, котрий знаходиться там, де ви вирішили встановити Git у вашій Windows системі, коли ви запускали інсталяцію. -Якщо ви використовуєте Git для Windows версії 2.x або новішу, то є також системний конфігураційний файл `C:\Documents and Settings\All Users\Application Data\Git\config` під Windows XP, і `C:\ProgramData\Git\config` під Windows Vista й новіші. +Якщо ви використовуєте Git для Windows версії 2.x або новішу, то є також системний конфігураційний файл `C:\Documents and Settings\All Users\Application Data\Git\config` під Windows XP і `C:\ProgramData\Git\config` під Windows Vista й новіші. Цей файл може бути зміненим лише за допомогою `git config -f <файл>` адміністратором. Ви можете переглянути усі ваші налаштування та звідки вони надходять виконавши: From e4f3ad664cf6553d01808af75b73bee719b3180e Mon Sep 17 00:00:00 2001 From: burlakvo Date: Mon, 25 Nov 2024 23:36:11 +0200 Subject: [PATCH 16/17] =?UTF-8?q?=D0=94=D0=BE=D0=B4=D0=B0=D1=94=20=D0=BF?= =?UTF-8?q?=D0=BE=D1=82=D1=80=D1=96=D0=B1=D0=BD=D0=B8=D0=B9=20=D1=80=D0=BE?= =?UTF-8?q?=D0=B7=D0=B4=D1=96=D0=BB=20=D0=B4=D0=BE=20C-git-commands.asc?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Новий розділ на який є посилання у first-time-setup.asc --- C-git-commands.asc | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+) diff --git a/C-git-commands.asc b/C-git-commands.asc index 3c05611..d234111 100644 --- a/C-git-commands.asc +++ b/C-git-commands.asc @@ -34,6 +34,44 @@ Git має типовий спосіб, як робити сотні речей. Нарешті, фактично весь <> присвячено цій команді. +[[ch_core_editor]] +==== Команди git config core.editor + +На додаток до інструкції з налаштування у <>, багато редакторів можуть бути встановлені наступним чином: + +.Вичерпний перелік команд налаштування `core.editor` +[cols="1,2",options="header"] +|============================== +|Редактор | Команда налаштування +|Atom |`git config --global core.editor "atom --wait"` +|BBEdit (macOS з інструментами командного рядка) |`git config --global core.editor "bbedit -w"` +|Emacs |`git config --global core.editor emacs` +|Gedit (Linux) |`git config --global core.editor "gedit --wait --new-window"` +|Gvim (64-бітовій Windows) |`git config --global core.editor "'C:\Program Files\Vim\vim72\gvim.exe' --nofork '%*'"` (дивіться примітку нижче) +|Helix |`git config --global core.editor "hx"` +|Kate (Linux) |`git config --global core.editor "kate --block"` +|nano |`git config --global core.editor "nano -w"` +|Notepad (64-бітовій Windows) |`git config core.editor notepad` +|Notepad++ (64-бітовій Windows) |`git config --global core.editor "'C:\Program Files\Notepad+\+\notepad++.exe' -multiInst -notabbar -nosession -noPlugin"` (дивіться примітку нижче) +|Scratch (Linux)|`git config --global core.editor "scratch-text-editor"` +|Sublime Text (macOS) |`git config --global core.editor "/Applications/Sublime\ Text.app/Contents/SharedSupport/bin/subl --new-window --wait"` +|Sublime Text (64-бітовій Windows) |`git config --global core.editor "'C:\Program Files\Sublime Text 3\sublime_text.exe' -w"` (дивіться примітку нижче) +|TextEdit (macOS)|`git config --global core.editor "open --wait-apps --new -e"` +|Textmate |`git config --global core.editor "mate -w"` +|Textpad (64-бітовій Windows) |`git config --global core.editor "'C:\Program Files\TextPad 5\TextPad.exe' -m"` (дивіться примітку нижче) +|UltraEdit (64-бітовій Windows) | `git config --global core.editor Uedit32` +|Vim |`git config --global core.editor "vim --nofork"` +|Visual Studio Code |`git config --global core.editor "code --wait"` +|VSCodium (Free/Libre Open Source Software Binaries of VSCode) | `git config --global core.editor "codium --wait"` +|WordPad |`git config --global core.editor "'C:\Program Files\Windows NT\Accessories\wordpad.exe'"` +|Xi | `git config --global core.editor "xi --wait"` +|============================== + +[NOTE] +==== +Якщо ви маєте 32-бітовий редактор у 64-бітовій системі Windows, його буде інстальовано радше до `C:\Program Files (x86)\` аніж `C:\Program Files\`, попри те, що вказано у таблиці вище. +==== + ==== git help Команда `git help` призначена для відображення документації, що постачається разом з Git для кожної команди. From 41dcce69d642ec7779de6b84fe4f5b196d8c3087 Mon Sep 17 00:00:00 2001 From: burlakvo Date: Mon, 25 Nov 2024 23:41:51 +0200 Subject: [PATCH 17/17] =?UTF-8?q?=D0=97=D0=BC=D1=96=D0=BD=D1=8E=D1=94=20?= =?UTF-8?q?=D1=84=D0=BE=D1=80=D0=BC=D1=83=D0=BB=D1=8E=D0=B2=D0=B0=D0=BD?= =?UTF-8?q?=D0=BD=D1=8F=20=D0=BD=D0=B0=20=D0=B1=D0=B5=D0=B7=20"=D0=BD?= =?UTF-8?q?=D0=BE=D0=B2=D1=96=D1=88=D1=96"?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- book/01-introduction/sections/first-time-setup.asc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/01-introduction/sections/first-time-setup.asc b/book/01-introduction/sections/first-time-setup.asc index a688f0d..050a2f1 100755 --- a/book/01-introduction/sections/first-time-setup.asc +++ b/book/01-introduction/sections/first-time-setup.asc @@ -21,7 +21,7 @@ У системах Windows, Git шукає файл `.gitconfig` у теці `$HOME` (`C:\Users\$USER` для більшості користувачів). Також, він все одно шукає файл `[path]/etc/gitconfig`, хоча й відносно кореня MSys, котрий знаходиться там, де ви вирішили встановити Git у вашій Windows системі, коли ви запускали інсталяцію. -Якщо ви використовуєте Git для Windows версії 2.x або новішу, то є також системний конфігураційний файл `C:\Documents and Settings\All Users\Application Data\Git\config` під Windows XP і `C:\ProgramData\Git\config` під Windows Vista й новіші. +Якщо ви використовуєте Git для Windows версії 2.x або новішу, то є також системний конфігураційний файл `C:\Documents and Settings\All Users\Application Data\Git\config` під Windows XP, а починаючи з Windows Vista -- `C:\ProgramData\Git\config`. Цей файл може бути зміненим лише за допомогою `git config -f <файл>` адміністратором. Ви можете переглянути усі ваші налаштування та звідки вони надходять виконавши: