Документ описывает системы управления версиями (VCS), такие как Git, SVN и Mercurial, и их возможности, преимущества и недостатки. В нём рассматриваются основные функции VCS, включая хранение различных версий документов, управление ветками и журнал изменений. Кроме того, представлены инструкции по установке и настройке Git, а также использование различных команд для управления репозиториями.

1. Sistem de control al versiunilor

2. Система управления версиями (от англ. Version
Control System, VCS или Revision Control System) —
программное обеспечение для облегчения
работы с изменяющейся информацией. Система
управления версиями позволяет хранить
несколько версий одного и того же документа,
при необходимости возвращаться к более
ранним версиям, определять, кто и когда сделал
то или иное изменение, и многое другое.

3. Многие системы управления версиями предоставляют ряд других
возможностей:
• Позволяют создавать разные варианты одного документа,
т. н. ветки, с общей историей изменений до точки ветвления и
с разными — после неё.
• Дают возможность узнать, кто и когда добавил или изменил
конкретный набор строк в файле.
• Ведут журнал изменений, в который пользователи могут
записывать пояснения о том, что и почему они изменили в
данной версии.
• Контролируют права доступа пользователей, разрешая или
запрещая чтение или изменение данных, в зависимости от того,
кто запрашивает это действие.
• …

4. Локальные системы контроля
версий

5. Централизованные системы
контроля версий

6. Распределенные
системы контроля
версий

7. Git, SVN, Mercurial

8. SVN
• CVS появилась в 1980-х и до сих пор популярна
как у разработчиков коммерческих продуктов,
так и у open-source разработчиков.
• CVS распространяется на условиях Открытого
лицензионного соглашения GNU и позволяет
получать с сервера нужную версию проекта —
«check-out» (извлечение), а затем пересылать
обратно на сервер, «check-in» (возврат), с
внесенными изменениями.

9. Преимущества:
• Испытанная временем технология, которая
удерживается на рынке десятки лет.
Недостатки:
• Переименование или перемещение файлов не
отражается в истории
• Риски безопасности, связанные с символическими
ссылками на файлы
• Нет поддержки атомарных операций, что может
привести к повреждению кода
• Операции с ветками программного кода
дорогостоящие, так как эта система контроля не
предназначена для долгосрочных проектов с ветками
кода

11. • SVN создавалась как альтернатива CVS с целью
исправить недостатки CVS и в то же время
обеспечить высокую совместимость с ней.
• Как и CVS, SVN это бесплатная
система контроля версий с открытым
исходным кодом. С той лишь разницей, что
распространяется под лицензией Apache, а не
под Открытым лицензионным
соглашением GNU.

12. В качестве недостатков SVN упоминаются
сравнительно низкая скорость и нехватка
распределенного управления версиями.
Преимущества:
• Система на основе CVS
• Допускает атомарные операции
• Операции с ветвлением кода менее затратны
• Широкий выбор плагинов IDE
• Не использует пиринговую модель
Недостатки:
• Все еще сохраняются ошибки, связанные с
переименованием файлов и директорий
• Неудовлетворительный набор команд для работы с
репозиторием
• Сравнительно небольшая скорость

13. Mercurial
• Mercurial создавалась в качестве альтернативы Git для
разработки модулей ядра Linux. Но так как выбрали все-
таки Git, то Mercurial используется меньше. Тем не
менее, многие ведущие разработчики работают именно
с этой системой, например OpenOffice.org.
• Система контроля версий Mercurial отличается от
других систем контроля версий тем, что главным
образом она написана на Python (а не С). Однако,
некоторые части выполнены в качестве модулей-
расширений на C.
• Поскольку система децентрализованная и написана
на Python, многие Python-программисты склоняются к
переходу на Mercurial.

15. Преимущества:
• По сравнению с Git легче в освоении
• Подробная документация
• Распределенная модель системы контроля
версий
Недостатки:
• Нет возможности слияния двух
родительских веток
• Использование плагинов, а не скриптов
• Меньше возможностей для нестандартных
решений

16. Git
• В основу Git закладывались концепции,
призванные создать более быструю
распределеннуюсистему контроля версий, в
противовес правилам и решениям,
использованным в CVS. Так как Git
разрабатывалась главным образом под
Linux, то именно в этой ОС она работает
быстрее всего.

17. Преимущества:
• Прекрасно подходит для тех, кто
ненавидит CVS/SVN
• Значительное увеличение быстродействия
• Дешевые операции с ветками кода
• Полная история разработки доступная
оффлайн
• Распределенная, пиринговая модель
Недостатки:
• Высокий порог вхождения (обучения) для тех,
кто ранее использовал SVN
• Ограниченная поддержка Windows (по
сравнению с Linux)

18. Краткая история Git
• Ядро Linux представляет собой крайне
масштабный проект ПО с открытым исходным
кодом. В истории поддержки ядра Linux
изменения программ долгое время
передавались в виде исправлений (patches) и
архивированных файлов. В 2002 году
для проекта Linux стали использовать
собственную систему DVCS, которая
называлась BitKeeper.

19. В 2005 году отношения между
сообществом, разрабатывавшим
ядро Linux, и коммерческой фирмой,
создавшей BitKeeper, были
разорваны и бесплатное
использование этой системы
контроля версий стало
невозможным, что побудило
сообщество
разработчиков Linux (и в частности
создателя этой операционной
системы Линуса
Торвальдса) начать работу над
собственным инструментом, взяв за
основу некоторые
идеи BitKeeper.

20. Снимки состояний, а не изменений
• Git воспринимает данные как поток
снимков состояния (stream of snapshots)

21. Локальность операций
• Для осуществления практически всех
операций системе Git требуются только
локальные файлы и ресурсы — в общем
случае информация с других компьютеров
сети не нужна.

22. Целостность Git
• В системе Git для всех данных перед
сохранением вычисляется контрольная
сумма,
по которой они впоследствии ищутся. То
есть сохранить содержимое файла или
папки таким образом, чтобы система Git об
этом не узнала, невозможно.

23. Git, как правило, только добавляет
данные
• Практически все операции в Git приводят к
добавлению данных в базу. Систему
сложно заставить выполнить неотменяемое
действие или каким-то образом стереть
данные.

24. Три состояния
Файлы в Git могут находиться в трех основных состояниях:
Зафиксированное (committed) состояние означает, что
данные надежно сохранены в локальной базе.
Модифицированное (modified) состояние означает, что
изменения уже внесены в файл, но пока не
зафиксированы в базе данных.
Индексированное(staged) состояние означает, что вы
пометили текущую версию модифицированного файла как
предназначенную для следующей фиксации .

25. • В результате Git-проект разбивается на три
основные области: папка Git, рабочая
папка и область индексирования

26. Папка Git — это место, где Git хранит метаданные и
объектную базу данных проекта.
Рабочая папка — это место, куда выполняется
выгрузка одной из версий проекта. Эти файлы
извлекаются из сжатой базы данных в папке Git и
помещаются на жесткий диск вашего компьютера,
готовые к использованию или редактированию.
Область индексирования — это файл, обычно
находящийся в папке Git и хранящий
информацию о том, что именно войдет в следующую
операцию фиксации. Иногда
ее еще называют промежуточной областью.

27. Базовый рабочий процесс в Git
выглядит так:
1. Вы редактируете файлы в рабочей папке.
2. Вы индексируете файлы, добавляя их
снимки в область индексирования.
3. Вы выполняете фиксацию, беря файлы из
области индексирования и сохраняя
снимки в папке Git.

28. Установка Git
• http://msysgit.github.io/
• $ apt-get install git

29. Первая настройка Git
• Система Git поставляется с инструментом
git config, позволяющим получать
и устанавливать переменные
конфигурации, которые задают все аспекты
внешнего вида и работы Git. Эти
переменные хранятся в разных местах.

30. • Файл /etc/gitconfig содержит значения, действующие
для всех пользователей системы и всех их
репозиториев. Указав параметр --system при запуске git
config, вы добьетесь чтения и записи для этого
конкретного файла.
• Файл ~/.gitconfig или ~/.config/git/config связан с
конкретным пользователем. Чтение и запись для этого
файла инициируются передачей параметра--global.
• ‰Параметры конфигурационного файла в папке Git (то
есть .git/config) репозитория, с которым вы работаете в
данный момент, действуют только на конкретный
репозиторий.

31. Ваш идентификатор
• При установке Git первым делом следует
указать имя пользователя и адрес
электронной почты.
$ git config --global user.name "John Doe"
$ git config --global user.email
johndoe@example.com

32. Проверка настроек
git config --list
Получение справочной информации
git help <команда>
git <команда> --help
man git-<команда>

33. Инициализация репозитория в существующей
папке
git init
В результате в существующей папке появится
еще одна папка с именем .git и всеми
нужными вам файлами репозитория — это
будет основа вашего Git-репозитория.
Пока контроль ваших файлов отсутствует.

34. Чтобы начать управление версиями
существующих файлов (в противовес пустому
каталогу), укажите файлы, за которыми
должна следить система, и выполните
первую фиксацию изменений. Для этого
потребуется несколько команд git add,
добавляющих файлы, за которыми вы хотите
следить, а затем команда git commit:

35. Клонирование существующего
репозитория
• Клонирование репозитория осуществляется
командой git clone [url].
git clone https://github.com/libgit2/libgit2

36. Запись изменений в репозиторий

37. Проверка состояния файлов
• Основным инструментом определения
состояния файлов является команда
git status

38. Слежение за новыми файлами
Чтобы начать слежение за новым файлом,
воспользуйтесь командой git add.
Это многоцелевая команда, позволяющая начать
слежение за новыми файлами, произвести
индексирование файлов, а также пометить файлы с
конфликтом слияния как разрешенные.
Возможно, целесообразнее воспринимать
эту команду как «добавление содержимого к
следующему коммиту», а не как «добавление файла к
проекту».

39. Краткий отчет о состоянии
Команда git status дает исчерпывающий, хотя
и многословный результат. Но в Git
существует флаг, позволяющий получить
сведения в более компактной форме.
Запустив команду git status -s или
git status --short, вы получите упрощенный
вариант вывода.

40. Игнорирование файлов
• Бывает так, что некоторый класс файлов вы не
хотите ни автоматически добавлять в
репозиторий, ни видеть в списке
неотслеживаемых.
• В эту категорию, как правило, попадают
автоматически генерируемые файлы,
например журналы регистрации или файлы,
генерируемые системой сборки.

41. • В подобных случаях создается файл
.gitignore со списком соответствующих
паттернов.
Пример такого файла:
$ cat .gitignore
*.[oa]
*~

42. PATTERN FORMAT
• Строка, начинающаяся с #, служит комментарием.
• Промежуточные пробелы игнорируются, если они
не цитируются с обратным слэшем («»).
• Дополнительный префикс "!" что отрицает шаблон;
любой сопоставимый файл, исключенный
предыдущим шаблоном, снова будет включен.
• Положите обратную косую черту («») перед
первым «!» для шаблонов, которые начинаются с
буквального «!»
• Если шаблон заканчивается косой чертой, он
удаляется с целью последующего описания, но он
будет находить совпадение с каталогом.

43. • Git рассматривает шаблон как оболочку
glob: «*» соответствует чему угодно, кроме
«/», «?» соответствует одному символу,
кроме «/» и «[]» соответствует одному
символу в выбранном диапазоне.

44. Две последовательные звездочки («**») в шаблонах, сопоставленные с
полным именем пути, могут иметь особое значение:
• Например, «** / foo» соответствует файлу или директории «foo» в
любом месте, так же, как и шаблон «foo». «** / foo / bar»
соответствует файлу или каталогу «bar» где угодно, прямо под
каталогом «foo».
• Например, «abc / **» соответствует всем файлам внутри каталога
«abc» относительно местоположения файла .gitignore с бесконечной
глубиной.
• Слэш, за которым следуют две последовательные звездочки, затем
косая черта совпадает с нулевыми или более каталогами. Например,
«a / ** / b» соответствует «a / b», «a / x / b», «a / x / y / b» и так далее.
• Другие последовательные звездочки считаются недействительными.

45. Просмотр индексированных и
неиндексированных
изменений
• Если команда git status дает недостаточно
подробный, с вашей точки зрения,
результат, например если вы хотите не
только получить список отредактированных
файлов, но и узнать, что именно
изменилось, воспользуйтесь командой
git diff

46. • Чтобы посмотреть, что из
проиндексированного войдет в следующий
коммит, воспользуйтесь командой
git diff --staged

47. Фиксация изменений
Проще всего осуществить фиксацию командой
git commit
Все , оставленное неиндексированным, в том
числе любые созданные или измененные
файлы, для которых после редактирования не
была выполнена команда git add, в текущий
коммит не войдет. Все эти файлы останутся на
вашем диске как измененные.

48. Пропуск области индексирования
!!! Хотя область индексирования помогает получить
именно ту версию состояния, которая вам требуется,
иногда она чрезмерно усложняет рабочий процесс.
Впрочем, в Git есть простой способ обойтись без этой
области. Достаточно передать
команде
git commit -a
и система Git начнет автоматически индексировать
все отслеживаемые файлы перед их фиксацией,
позволяя обойтись без команды git add

49. Удаление файлов
Чтобы система Git перестала работать с файлом,
его нужно удалить из числа отслеживаемых
(точнее, убрать из области индексирования) и
зафиксировать данное
изменение.
Это делает команда git rm, которая заодно
удаляет указанный файл из рабочей папки,
благодаря чему он исчезает из списка
неотслеживаемых.

50. Команде git rm можно передавать в качестве
аргументов файлы, папки и глобальные
паттерны. То есть можно написать:
$ git rm log/*.log

51. Перемещение файлов
• Git есть команда mv. Для переименования
файла можно
написать:
$ git mv file_from file_to

52. Просмотр истории версий
• После сохранения нескольких версий
файлов или клонирования уже имеющего
содержимое репозитория вы, скорее всего,
захотите взглянуть на то, что было сделано
ранее.
• Базовым и самым мощным инструментом в
данном случае является
команда git log

53. • У команды git log существует великое
множество параметров, позволяющих
вывести именно ту информацию, которая
вам требуется. Рассмотрим несколько
самых популярных.

54. • К примеру, для получения краткой
статистики по каждой версии применяется
параметр --stat:
$ git log --stat

55. Еще одним крайне полезным параметром является
--pretty - Он меняет формат вывода информации.
$ git log --pretty=oneline
Наиболее интересен параметр format, позволяющий
выводить записи журнала в выбранном вами
формате. Это особенно полезно при генерации
данных для машинного анализа, ведь формат
задается в явном виде, и вы можете быть уверены,
что при обновлениях Git он не изменится:
$ git log --pretty=format:"%h - %an, %ar : %s"

56. Полезные параметры команды git
log --pretty=format
%H Хеш-код коммита
%h Сокращенный хеш-код коммита
%T Хеш-код дерева
%t Сокращенный хеш-код дерева
%P Хеш-код родительских коммитов
%p Сокращенный хеш-код родительских коммитов
%an Имя автора

57. %ae Электронная почта автора
%ad Дата создания оригинала
%ar Дата создания оригинала, в относительной форме
%cn Имя создателя версии
%ce Электронная почта создателя версии
%cd Дата создания версии
%cr Дата создания версии в относительном формате
%s Комментарий

58. Распространенные параметры
команды git log
-p Показывает изменения, внесенные в каждую версию
--stat Показывает статистику измененных файлов в каждом коммите
--shortstat Показывает только строку с изменениями/вставками/удалениями от
команды
--stat--name-only Показывает список измененных файлов после информации
о коммите
--name-status Показывает список измененных файлов с информацией
о добавлении/изменении/удалении
--abbrev-commit Показывает только первые несколько символов контрольной
суммы SHA-1 вместо всех 40--relative-date Показывает дату не в полном, а в
относительном формате (например, «2 недели назад»)
--graph Показывает ASCII-граф истории ветвлений и слияний вместе
с выводом команды log
--pretty Показывает коммиты в альтернативном формате. Возможны
параметры oneline, short, full, fuller и format (с указанием
вашей версии формата)

59. Ограничение вывода команды log
• Команда git log обладает не только
параметрами форматирования вывода, но
и ограничивающими параметрами,
дающими возможность выводить на экран
только часть коммитов.

60. -(n) Показывает только последние n коммитов
--since, --after Показывает только коммиты, внесенные
после указанной даты
--until, --before Показывает только коммиты,
внесенные до указанной даты
--author Показывает только коммиты определенного
автора--committer Показывает только коммиты,
внесенные определенным участником
--grep Показывает только коммиты с сообщением
фиксации,содержащим указанную строку
-S Показывает только коммиты, в которых
добавленный или удаленный код совпадает с
указанной строкой

61. Отмена изменений
• Необходимость отмены внесенных изменений
может возникнуть на любой стадии проекта. В
этом разделе мы рассмотрим несколько
базовых инструментов, позволяющих это
сделать.
• Для повторного сохранения версии в такой
ситуации можно воспользоваться параметром
–amend: $ git commit –amend

62. Отмена индексирования
• Предположим, вы отредактировали два
файла и хотели бы зафиксировать
их в двух разных коммитах, но случайно
набрали команду git add *, что привело
к их одновременному индексированию.
git reset HEAD <имя файла>

63. Etichete (Tags)
• Git utilizează două tipuri de etichete de
bază: ușoare și comentate.

65. • O etichetă ușoară (lightweight tag) ste
asemănătoare unei ramuri care nu se schimbă
- este doar un indicator al unui commit
specific.

66. Etichetele cu comentarii (etichete adnotate)
sunt stocate în baza de date Git ca obiecte
complete.
Ei au:
• o sumă de control;
• numele persoanei, care a pus tag-ul, adresa
de e-mail și data creării;
• un comentariu;
• pot fi semnate și verificate în programul GNU
Privacy Guard (GPG).

67. Listează etichetele>
$ git tag
Creați etichete ușoare
$ git tag v1.4-lw
Pentru a crea o etichetă într-un Git cu un comentariu este foarte ușor. Cea
mai ușoară cale de a adăuga opțiunea -a la comanda tag este:
$ git tag -a v1.4 -m 'my version 1.4‘
Pentru a vizualiza datele etichetei, utilizați comanda de afișare,
împreună cu comitetul :
$ git show v1.4

68. Etichetarea post-factuală
$ git tag -a v1.2 9fceb02
Schimb de etichete
$ git push --tags
$ git push origin v1.5

69. Aliasuri în Git
(aliases)
$ git config --global alias.co checkout
$ git config --global alias.br branch
$ git config --global alias.ci commit
$ git config --global alias.st status
Acum, în loc de comanda git commit, trebuie
doar să introduceți git ci.

70. Branchind în Git
• Termenul de ramificare înseamnă o
abatere de la linia principală de
dezvoltare, după care lucrarea încetează
să afecteze această linie de bază.

71. Crearea unei noi ramuri
• Se afișează un nou indicator, pe care îl
puteți muta.
• Să presupunem că creați o ramură de
testare. Această operație este executată
de comanda branch branch:
$ git branch testing

72. Se afișează un nou indicator al commitului dvs.
curent
Două ramuri care indică același set de comitete

73. Schimbarea ramurilor
Trecerea la ramura existentă este implementată de
comanda git checkout.
$ git checkout testing

74. Ramura master în Git nu este diferită de
celelalte. Dar este prezent în aproape fiecare
depozit, deoarece este creat de comanda git
init implicit, iar majoritatea utilizatorilor nu se
deranjează să se redenumească.

75. Daca peste un timp se pare că ramura dvs. de testare sa
mutat înainte, în timp ce ramura principală a rămas
asociată cu comitetul care rulează în prezent la o altă
ramură, folosind comanda git checkout

76. Git știe ce comite este cel curent, pentru care stochează un
indicator special HEAD.
!!! Comanda ramurii git tocmai a creat o nouă ramură, dar nu
te-a tradus în ea.
Pentru a afla exact unde sunt direcționate indicatorii de
ramură, puteți folosi comanda log git cu opțiunea --decorate
git log --decorate

77. • Este important să înțelegeți că trecerea la o
altă ramură este însoțită de o schimbare a
fișierelor în dosarul de lucru. Când vă
întoarceți la o ramură mai veche, conținutul
dosarului de lucru va obține viziunea pe care a
avut-o înainte de ultima comitere din acea
ramură.

78. Echipa în formă
git log –oneline --decorate –graph --all
Demonstrează esența a ceea ce se
întâmplă

79. Elementele de bază ale ramificării și
fuzionării
1. Facem câteva acțiuni pe site.
2. Creați o ramură pentru o poveste nouă, de care trebuie să
lucrați.
3. Și în această ramură facem niște acțiuni.
Și acum, să presupunem că am fost chemați și informați despre o
problemă importantă care necesită o soluție urgentă. Procedăm
după cum urmează:
4. Treceți la ramura de producție.
5. Creați o ramură pentru a rezolva problema.
6. După testare, efectuăm fuzionarea ramurii secundare și o
trimitem dezvoltării.
7. Întoarceți-vă la sarcina originală și continuați lucrarea.

80. Bazele ramificării
• Mai întâi, imaginați-vă că lucrați la
proiectul dvs. și aveți deja câteva
commituri

81. $ git branch iss53
$ git checkout iss53

82. În timp ce lucrați pe site-ul dvs., faceți mai
multe comitete. Aceste acțiuni fac trecerea
ramurii iss53 înainte, deoarece ați trecut-o
(adică, HEAD-ul dvs. indică acest lucru

83. • Cu Git, nu este nevoie să faceți corecții pentru
acele modificări pe care le-ați făcut deja în
iss53 și nu este nevoie să faceți prea multe
eforturi pentru a anula aceste modificări
înainte de a începe să lucrați la rezolvarea unei
probleme urgente.

84. Deci, trebuie să corectați rapid eroarea
$ git checkout -b hotfix
$ git commit -a -m 'fixed the broken email
address'

85. Ramura pentru rezolvarea problemei
urgente se bazează pe ramura principală.

86. • Puteți efectua teste, asigurați-vă că soluția
funcționează și îmbinați modificările înapoi în
ramura principală pentru a le include în
produs. Acest lucru se face cu comanda git
merge:
$ git checkout master
$ git merge hotfix

87. Git tocmai și-a împins indicatorul. Cu alte
cuvinte, atunci când încercați să îmbinați o
comitere cu una pe care o puteți realiza
urmând istoria primei comiteri,
Git ajunge mai ușor, deplasând indicatorul
înainte, deoarece nu există schimbări
divergente care trebuie combinate împreună.
Aceasta se numește "rapid înainte".

89. Elementele de bază ale fuziunii
Git face o îmbinare simplă în trei direcții, folosind cele două instantanee ale stării
repozitorului la care se adaugă indică vârfurile ramurilor, iar imaginea obișnuită
pentru aceste două ramuri este strămoșul.
Git determină automat
cel mai bun strămoș
comun pentru a
fuziona

90. În loc să mișcați pur și simplu pointerul de
ramură înainte, Git creează un instantaneu de
stare nou rezultatul unei îmbinări în trei direcții
și creează automat o nouă comitere care
indică acest instantaneu de stare nou

91. Конфликты при слиянии
În acest caz, Git nu poate crea automat o
comitere de îmbinare. Sistemul suspendă
procesul până la rezolvarea conflictului.
Pentru a vedea care fișiere nu au fuzionat
după ce apare un conflict, utilizați comanda
git status

92. Managementul ramurilor
Comanda ramură git vă permite nu numai să
creați și să ștergeți sucursalele. Rularea fără
argumente, afișează o listă de ramuri
disponibile:
$ git branch
iss53
* master
testing

93. * înaintea ramurii principale: indică faptul că în
această ramură sunteți în prezent (adică,
indicatorul HEAD este îndreptat spre el)
Ultima comitere efectuată în fiecare ramură este
demonstrată de comandă git branch -v:
--merged si --no-merged
lăsați în listă numai acele ramuri pe care le-
ați îmbinat sau nu fuzionate cu sucursala
curentă.

94. Tehnici de lucru cu ramuri
• Branduri lungi
Numărul de niveluri de stabilitate poate fi mărit. În proiectele mari, sucursala propusă
sau pu (o reducere față de actualizările propuse) adesea fuzionează sucursale cu
conținut care nu poate fi inclus în ramura următoare sau principală.

95. Deoarece Git utilizează o îmbinare simplă în
trei etape, nu există nimic care să împiedice
fuzionarea mai multor sucursale pentru o
perioadă lungă de timp. Adică, puteți avea
mai multe sucursale deschise în mod
constant utilizate pentru diferite etape ale
ciclului de dezvoltare; conținutul unora dintre
ele va fuziona regulat în alte ramuri.

96. Ramuri tematice

97. Afișarea repozitelor de la distanță
• Afișarea repozitelor de la distanță. Puteți
vizualiza serverele de la distanță deja
configurate cu comanda de la distanță Git
remote. Oferă o listă cu nume scurte pentru
toate zonele de lucru la distanță pe care le
specificați.

98. Adăugarea de repozite la distanță
• Am menționat deja și am demonstrat procesul
de adăugare a depozitelor de la distanță, dar
acum ne vom uita în mod explicit. Pentru a
adăuga un astfel de depozit sub un nume scurt
care va simplifica apelurile ulterioare la acesta,
utilizați comanda
git remote add [сокращенное имя] [url]

99. Extragerea datelor din repozitele de la
distanță
• După cum ați văzut deja, extragerea
datelor din proiectele la distanță este
efectuată de o astfel de comandă:
$ git fetch [имя удаленного репозитория]
Această comandă comunică cu proiectul
la distanță și extrage de acolo toate datele
care lipsesc.

100. Trimiterea datelor către un repozit la
distanță
Aceasta se face printr-o comandă simplă
git push [имя удаленного сервера] [ветка]
Pentru a trimite ramura principală la serverul de
origine (vă reamintim din nou că aceste nume
sunt atribuite automat în timpul procesului de
clonare), trebuie să scrieți:
git push origin master

101. Vizualizarea repozitelor de la distanță
• Pentru mai multe informații despre un anumit
depozit la distanță, utilizați comanda
git remote show [имя удаленного сервера]
Introducând originea numelui în comandă,
obțineți aproximativ acest rezultat:git
remote show origin

102. Ștergerea și redenumirea depozitelor
de la distanță
• Linkurile de renunțare se efectuează prin
comanda git remote rename, care schimbă
numele abreviate ale depozitelor de la
distanță. De exemplu, iată cum arată asocierea
magaziei paul cu paul:
git remote rename pb paul

103. GitHub – платформа для
совместной
работы. Она позволяет:
• Создавать свои репозитории в облаке, на
сервере GitHub
• Удобно управлять ими
• и многое другое…

104. 1. Регистрируемся на github.com
2. Создаем репозиторий. При создании
просим сразу создать в нём файл
README (это упростит нам
дальнейшую работу)
3. Запоминаем адрес нашего репозитория
(clone URL)
4. Клонируем этот репозиторий к себе на
компьютер:
git clone CLONE_URL PROJECT_FOLDER

105. • В результате мы получаем у себя
репозиторий, являющийся точной копией
удалённого репозитория. Более того – они
связаны невидимой связью и мы этим
воспользуемся!

106. git pull
- не просто «достаёт» изменения,
но и пытается применить изменения с
удаленного репозитория к нашему (влить
удаленную ветку в локальную)
git push
- отправляет наши наборы изменений
на удалённый репозиторий