🗊Презентация Технология и процесс разработки ПО. Лекция 6

Нажмите для полного просмотра!
Технология и процесс разработки ПО. Лекция 6, слайд №1Технология и процесс разработки ПО. Лекция 6, слайд №2Технология и процесс разработки ПО. Лекция 6, слайд №3Технология и процесс разработки ПО. Лекция 6, слайд №4Технология и процесс разработки ПО. Лекция 6, слайд №5Технология и процесс разработки ПО. Лекция 6, слайд №6Технология и процесс разработки ПО. Лекция 6, слайд №7Технология и процесс разработки ПО. Лекция 6, слайд №8Технология и процесс разработки ПО. Лекция 6, слайд №9Технология и процесс разработки ПО. Лекция 6, слайд №10Технология и процесс разработки ПО. Лекция 6, слайд №11Технология и процесс разработки ПО. Лекция 6, слайд №12Технология и процесс разработки ПО. Лекция 6, слайд №13Технология и процесс разработки ПО. Лекция 6, слайд №14Технология и процесс разработки ПО. Лекция 6, слайд №15Технология и процесс разработки ПО. Лекция 6, слайд №16Технология и процесс разработки ПО. Лекция 6, слайд №17Технология и процесс разработки ПО. Лекция 6, слайд №18Технология и процесс разработки ПО. Лекция 6, слайд №19Технология и процесс разработки ПО. Лекция 6, слайд №20Технология и процесс разработки ПО. Лекция 6, слайд №21Технология и процесс разработки ПО. Лекция 6, слайд №22Технология и процесс разработки ПО. Лекция 6, слайд №23Технология и процесс разработки ПО. Лекция 6, слайд №24Технология и процесс разработки ПО. Лекция 6, слайд №25Технология и процесс разработки ПО. Лекция 6, слайд №26Технология и процесс разработки ПО. Лекция 6, слайд №27Технология и процесс разработки ПО. Лекция 6, слайд №28Технология и процесс разработки ПО. Лекция 6, слайд №29Технология и процесс разработки ПО. Лекция 6, слайд №30Технология и процесс разработки ПО. Лекция 6, слайд №31Технология и процесс разработки ПО. Лекция 6, слайд №32Технология и процесс разработки ПО. Лекция 6, слайд №33

Содержание

Вы можете ознакомиться и скачать презентацию на тему Технология и процесс разработки ПО. Лекция 6. Доклад-сообщение содержит 33 слайдов. Презентации для любого класса можно скачать бесплатно. Если материал и наш сайт презентаций Mypresentation Вам понравились – поделитесь им с друзьями с помощью социальных кнопок и добавьте в закладки в своем браузере.

Слайды и текст этой презентации


Слайд 1


Технология и процесс разработки ПО. Лекция 6, слайд №1
Описание слайда:

Слайд 2





Система  контроля версий
•	Системы  управления  версиями (Version Control Systems, VCS) или Системы управления исходным кодом (Source Management Systems, SMS) — важный аспект разработки	   современного  ПО.	   
VCS предоставляет следующие возможности: 
Поддержка  хранения	   файлов  в	репозитории. 
Поддержка истории  версий	   файлов в репозитории.
Нахождение конфликтов при  изменении	   исходного	   кода и обеспечение синхронизации  при работе в	  многопользовательской	среде	разработки.	   
Отслеживание авторов изменений.
Описание слайда:
Система контроля версий • Системы управления версиями (Version Control Systems, VCS) или Системы управления исходным кодом (Source Management Systems, SMS) — важный аспект разработки современного ПО. VCS предоставляет следующие возможности: Поддержка хранения файлов в репозитории. Поддержка истории версий файлов в репозитории. Нахождение конфликтов при изменении исходного кода и обеспечение синхронизации при работе в многопользовательской среде разработки. Отслеживание авторов изменений.

Слайд 3





Система контроля версий
Система контроля версий (СКВ) — это система, регистрирующая изменения в одном или нескольких файлах с тем, чтобы в дальнейшем была возможность вернуться к определённым старым версиям этих файлов.
Описание слайда:
Система контроля версий Система контроля версий (СКВ) — это система, регистрирующая изменения в одном или нескольких файлах с тем, чтобы в дальнейшем была возможность вернуться к определённым старым версиям этих файлов.

Слайд 4





Классификация : 
Централизованные/распределённые — в централизованных системах контроля версий	 вся работа производится с центральным репозиторием, в распределённых — у каждого разработчика	 есть локальная копия репозитория.
Блокирующие/не блокирующие — блокирующие	 системы контроля версий позволяют наложить запрет на изменение файла,	 пока один из разработчиков работает над ним, в неблокирующих один файл может одновременно изменяться несколькими разработчиками.
Для текстовых данных/для бинарных данных — для VCS для текстовых данных очень важна поддержка слияния изменений, для	 VCS с бинарными данными важна возможность блокировки.
Описание слайда:
Классификация : Централизованные/распределённые — в централизованных системах контроля версий вся работа производится с центральным репозиторием, в распределённых — у каждого разработчика есть локальная копия репозитория. Блокирующие/не блокирующие — блокирующие системы контроля версий позволяют наложить запрет на изменение файла, пока один из разработчиков работает над ним, в неблокирующих один файл может одновременно изменяться несколькими разработчиками. Для текстовых данных/для бинарных данных — для VCS для текстовых данных очень важна поддержка слияния изменений, для VCS с бинарными данными важна возможность блокировки.

Слайд 5





Ежедневный цикл работы
Обычный цикл работы	разработчика выглядит следующим образом:   
Обновление рабочей копии.	   	   
Разработчик выполняет операцию обновления рабочей копии (update) насколько возможно	   
Модификация	   проекта.	   
Разработчик локально	 модифицирует проект, изменяя входящие в него файлы в рабочей	   копии.	   
Фиксация изменений.
Завершив очередной этап работы над заданием, разработчик фиксирует (commit) свои изменения, передавая их на сервер. VCS может	   требовать от разработчика перед фиксацией выполнить обновление.
Описание слайда:
Ежедневный цикл работы Обычный цикл работы разработчика выглядит следующим образом: Обновление рабочей копии. Разработчик выполняет операцию обновления рабочей копии (update) насколько возможно Модификация проекта. Разработчик локально модифицирует проект, изменяя входящие в него файлы в рабочей копии. Фиксация изменений. Завершив очередной этап работы над заданием, разработчик фиксирует (commit) свои изменения, передавая их на сервер. VCS может требовать от разработчика перед фиксацией выполнить обновление.

Слайд 6





       Основные термины:
Working copy – рабочая (локальная) копия документов.
repository, depot  — хранилище.	   
Revision — версия документа. Новые изменения (changeset) создают	   новую	   ревизию	   репозитория.	   
check-­‐in, commit, submit - фиксация	   изменений.	   	   
check-­‐out,	 clone —извлечение	   документа	   из	   хранилища и создание	   рабочей копии.	   
Update, sync — синхронизация	 рабочей копии до	   некоторого	   заданного	   состояния	   хранилища	   (в т.ч. И к более старому	   состоянию,	   чем	   текущее).
  merge, integration — слияние независимых изменений.	   
Conflict — ситуация, когда несколько пользователей сделали	   изменения одного и того же участка документа.	   
head — самая  свежая  версия (revision) в хранилище.	   Origin — имя главного	   сервера
Описание слайда:
Основные термины: Working copy – рабочая (локальная) копия документов. repository, depot — хранилище. Revision — версия документа. Новые изменения (changeset) создают новую ревизию репозитория. check-­‐in, commit, submit - фиксация изменений. check-­‐out, clone —извлечение документа из хранилища и создание рабочей копии. Update, sync — синхронизация рабочей копии до некоторого заданного состояния хранилища (в т.ч. И к более старому состоянию, чем текущее). merge, integration — слияние независимых изменений. Conflict — ситуация, когда несколько пользователей сделали изменения одного и того же участка документа. head — самая свежая версия (revision) в хранилище. Origin — имя главного сервера

Слайд 7





Ветвление
 
Ветвь (branch) - направление разработки проекта, независимое от других	   
Ветвь представляет собой копию части  (как правило, одного каталога)	   хранилища,	в которую можно вносить свои изменения, не влияющие на другие ветви.   
Документы в разных ветвях имеют одинаковую	   историю	   до точки ветвления и разные — после неё.	   
Изменения	   из	   одной	   ветви	   можно	   переносить	   в	   другую.
Ствол (trunk, mainline, master) — основная	   ветвь разработки проекта.
Описание слайда:
Ветвление Ветвь (branch) - направление разработки проекта, независимое от других Ветвь представляет собой копию части (как правило, одного каталога) хранилища, в которую можно вносить свои изменения, не влияющие на другие ветви. Документы в разных ветвях имеют одинаковую историю до точки ветвления и разные — после неё. Изменения из одной ветви можно переносить в другую. Ствол (trunk, mainline, master) — основная ветвь разработки проекта.

Слайд 8





Локальные системы контроля версий
Описание слайда:
Локальные системы контроля версий

Слайд 9





Централизованные системы контроля версий
Описание слайда:
Централизованные системы контроля версий

Слайд 10





Распределённые системы контроля версий
Описание слайда:
Распределённые системы контроля версий

Слайд 11





Краткое описание популярных распределенных СУВ

Git (http://git-scm.com/) - распределенная система контроля версий, разработанная Линусом Торвальдсом. Изначально Git предназначалась для использования в процессе разработки ядра Linux, но позже стала использоваться и во многих других проектах — таких, как, например, X.org и Ruby on Rails, Drupal. На данный момент Git является самой быстрой распределенной системой, использующей самое компактное хранилище ревизий. Но в тоже время для пользователей, переходящих, например, с Subversion интерфейс Git может показаться сложным;
Mercurial (http://www.selenic.com/mercurial/) - распределенная система, написанная на языке Python с несколькими расширениями на C. Из использующих Mercurial проектов можно назвать, такие, как, Mozilla и MoinMoin.
Bazaar (http://bazaar-vcs.org/) - система разработка которой поддерживается компанией Canonical — известной своими дистрибутивом Ubuntu и сайтом https://launchpad.net/. Система в основном написана на языке Python и используется такими проектами, как, например, MySQL.
Codeville (http://codeville.org/) - написанная на Python распределенная система использующая инновационный алгоритм объединения изменений (merge). Система используется, например, при разработке оригинального клиента BitTorrent.
Darcs (http://darcs.net/) - распределенная система контроля версий написанная на Haskell используемая, например, проектом Buildbot.
Monotone (http://monotone.ca/) - система написанная на C++ и использующая SQLite как хранилище ревизий.
Описание слайда:
Краткое описание популярных распределенных СУВ Git (http://git-scm.com/) - распределенная система контроля версий, разработанная Линусом Торвальдсом. Изначально Git предназначалась для использования в процессе разработки ядра Linux, но позже стала использоваться и во многих других проектах — таких, как, например, X.org и Ruby on Rails, Drupal. На данный момент Git является самой быстрой распределенной системой, использующей самое компактное хранилище ревизий. Но в тоже время для пользователей, переходящих, например, с Subversion интерфейс Git может показаться сложным; Mercurial (http://www.selenic.com/mercurial/) - распределенная система, написанная на языке Python с несколькими расширениями на C. Из использующих Mercurial проектов можно назвать, такие, как, Mozilla и MoinMoin. Bazaar (http://bazaar-vcs.org/) - система разработка которой поддерживается компанией Canonical — известной своими дистрибутивом Ubuntu и сайтом https://launchpad.net/. Система в основном написана на языке Python и используется такими проектами, как, например, MySQL. Codeville (http://codeville.org/) - написанная на Python распределенная система использующая инновационный алгоритм объединения изменений (merge). Система используется, например, при разработке оригинального клиента BitTorrent. Darcs (http://darcs.net/) - распределенная система контроля версий написанная на Haskell используемая, например, проектом Buildbot. Monotone (http://monotone.ca/) - система написанная на C++ и использующая SQLite как хранилище ревизий.

Слайд 12





Краткая история Git

Основные требования к новой системе были следующими:
Скорость
Простота дизайна
Поддержка нелинейной разработки (тысячи параллельных веток)
Полная распределённость
Возможность эффективной работы с такими большими проектами, как ядро Linux (как по скорости, так и по размеру данных)
Описание слайда:
Краткая история Git Основные требования к новой системе были следующими: Скорость Простота дизайна Поддержка нелинейной разработки (тысячи параллельных веток) Полная распределённость Возможность эффективной работы с такими большими проектами, как ядро Linux (как по скорости, так и по размеру данных)

Слайд 13





Слепки вместо патчей
Описание слайда:
Слепки вместо патчей

Слайд 14





Git хранит данные как слепки состояний проекта во времени
Описание слайда:
Git хранит данные как слепки состояний проекта во времени

Слайд 15





Git следит за целостностью данных

Механизм, используемый Git'ом для вычисления контрольных сумм, называется SHA-1 хешем. Это строка из 40 шестнадцатеричных символов (0-9 и a-f), вычисляемая в Git'е на основе содержимого файла или структуры каталога. SHA-1 хеш выглядит примерно так:
24b9da6552252987aa493b52f8696cd6d3b00373
Работая с Git'ом, вы будете встречать эти хеши повсюду, поскольку он их очень широко использует. Фактически, в своей базе данных Git сохраняет всё не по именам файлов, а по хешам их содержимого.
Описание слайда:
Git следит за целостностью данных Механизм, используемый Git'ом для вычисления контрольных сумм, называется SHA-1 хешем. Это строка из 40 шестнадцатеричных символов (0-9 и a-f), вычисляемая в Git'е на основе содержимого файла или структуры каталога. SHA-1 хеш выглядит примерно так: 24b9da6552252987aa493b52f8696cd6d3b00373 Работая с Git'ом, вы будете встречать эти хеши повсюду, поскольку он их очень широко использует. Фактически, в своей базе данных Git сохраняет всё не по именам файлов, а по хешам их содержимого.

Слайд 16





Три состояния GIT
Описание слайда:
Три состояния GIT

Слайд 17





Установка GIT
Установка в Linux
Если вы хотите установить Git под Linux как бинарный пакет, это можно сделать, используя обычный менеджер пакетов вашего дистрибутива. Если у вас Fedora, можно воспользоваться yum'ом:
$ yum install git-core
Если же у вас дистрибутив, основанный на Debian, например, Ubuntu, попробуйте apt-get:  $ apt-get install git
Установка на Mac
Есть два простых способа установить Git на Mac. Самый простой — использовать графический инсталлятор Git'а, который вы можете скачать со страницы на Google Code:
http://code.google.com/p/git-osx-installer
Описание слайда:
Установка GIT Установка в Linux Если вы хотите установить Git под Linux как бинарный пакет, это можно сделать, используя обычный менеджер пакетов вашего дистрибутива. Если у вас Fedora, можно воспользоваться yum'ом: $ yum install git-core Если же у вас дистрибутив, основанный на Debian, например, Ubuntu, попробуйте apt-get: $ apt-get install git Установка на Mac Есть два простых способа установить Git на Mac. Самый простой — использовать графический инсталлятор Git'а, который вы можете скачать со страницы на Google Code: http://code.google.com/p/git-osx-installer

Слайд 18





Первоначальная настройка Git

В состав Git'а входит утилита git config, которая позволяет просматривать и устанавливать параметры, контролирующие все аспекты работы Git'а и его внешний вид. Эти параметры могут быть сохранены в трёх местах:
    Файл /etc/gitconfig содержит значения, общие для всех пользователей системы и для всех их репозиториев. Если при запуске git config указать параметр --system, то параметры будут читаться и сохраняться именно в этот файл.
    Файл ~/.gitconfig хранит настройки конкретного пользователя. Этот файл используется при указании параметра --global.
    Конфигурационный файл в каталоге Git'а (.git/config) в том репозитории, где вы находитесь в данный момент. Эти параметры действуют только для данного конкретного репозитория. Настройки на каждом следующем уровне подменяют настройки из предыдущих уровней, то есть значения в .git/config перекрывают соответствующие значения в /etc/gitconfig.
Описание слайда:
Первоначальная настройка Git В состав Git'а входит утилита git config, которая позволяет просматривать и устанавливать параметры, контролирующие все аспекты работы Git'а и его внешний вид. Эти параметры могут быть сохранены в трёх местах: Файл /etc/gitconfig содержит значения, общие для всех пользователей системы и для всех их репозиториев. Если при запуске git config указать параметр --system, то параметры будут читаться и сохраняться именно в этот файл. Файл ~/.gitconfig хранит настройки конкретного пользователя. Этот файл используется при указании параметра --global. Конфигурационный файл в каталоге Git'а (.git/config) в том репозитории, где вы находитесь в данный момент. Эти параметры действуют только для данного конкретного репозитория. Настройки на каждом следующем уровне подменяют настройки из предыдущих уровней, то есть значения в .git/config перекрывают соответствующие значения в /etc/gitconfig.

Слайд 19





Имя пользователя

Первое, что вам следует сделать после установки Git'а, — указать ваше имя и адрес электронной почты. Это важно, потому что каждый коммит в Git'е содержит эту информацию, и она включена в коммиты, передаваемые вами, и не может быть далее изменена:
$ git config --global user.name “Denis Kasatkin"
$ git config --global user.email  d.kasatkin@outlook.com
Описание слайда:
Имя пользователя Первое, что вам следует сделать после установки Git'а, — указать ваше имя и адрес электронной почты. Это важно, потому что каждый коммит в Git'е содержит эту информацию, и она включена в коммиты, передаваемые вами, и не может быть далее изменена: $ git config --global user.name “Denis Kasatkin" $ git config --global user.email d.kasatkin@outlook.com

Слайд 20





Выбор редактора

Вы указали своё имя, и теперь можно выбрать текстовый редактор, который будет использоваться, если будет нужно набрать сообщение в Git'е. По умолчанию Git использует стандартный редактор вашей системы, обычно это Vi или Vim. Если вы хотите использовать другой текстовый редактор, например, Emacs, можно сделать следующее:
$ git config --global core.editor emacs
Описание слайда:
Выбор редактора Вы указали своё имя, и теперь можно выбрать текстовый редактор, который будет использоваться, если будет нужно набрать сообщение в Git'е. По умолчанию Git использует стандартный редактор вашей системы, обычно это Vi или Vim. Если вы хотите использовать другой текстовый редактор, например, Emacs, можно сделать следующее: $ git config --global core.editor emacs

Слайд 21





Утилита сравнения

Другая полезная настройка, которая может понадобиться — встроенная diff-утилита, которая будет использоваться для разрешения конфликтов слияния. Например, если вы хотите использовать vimdiff:
$ git config --global merge.tool vimdiff
Git умеет делать слияния при помощи kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge и opendiff, но вы можете настроить и другую утилиту.
Описание слайда:
Утилита сравнения Другая полезная настройка, которая может понадобиться — встроенная diff-утилита, которая будет использоваться для разрешения конфликтов слияния. Например, если вы хотите использовать vimdiff: $ git config --global merge.tool vimdiff Git умеет делать слияния при помощи kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge и opendiff, но вы можете настроить и другую утилиту.

Слайд 22





Проверка настроек

Если вы хотите проверить используемые настройки, можете использовать команду git config --list, чтобы показать все, которые Git найдёт:
$ git config --list
user.name=Denis Kasatkin
user.email=d.kasatkin@outlook.com
color.status=auto
color.branch=auto
color.interactive=auto
color.diff=auto
...
Описание слайда:
Проверка настроек Если вы хотите проверить используемые настройки, можете использовать команду git config --list, чтобы показать все, которые Git найдёт: $ git config --list user.name=Denis Kasatkin user.email=d.kasatkin@outlook.com color.status=auto color.branch=auto color.interactive=auto color.diff=auto ...

Слайд 23





Как получить помощь?

Если вам нужна помощь при использовании Git'а, есть три способа открыть страницу руководства по любой команде Git'а:
$ git help <команда> $ git <команда> --help $ man git-<команда> 
Например, так можно открыть руководство по команде config:
$ git help config
Описание слайда:
Как получить помощь? Если вам нужна помощь при использовании Git'а, есть три способа открыть страницу руководства по любой команде Git'а: $ git help <команда> $ git <команда> --help $ man git-<команда> Например, так можно открыть руководство по команде config: $ git help config

Слайд 24





Создание Git-репозитория

Для создания Git-репозитория существуют два основных подхода. Первый подход — импорт в Git уже существующего проекта или каталога. Второй — клонирование уже существующего репозитория с сервера.
Создание репозитория в существующем каталоге
Если вы собираетесь начать использовать Git для существующего проекта, то вам необходимо перейти в проектный каталог и в командной строке ввести
$ git init
Описание слайда:
Создание Git-репозитория Для создания Git-репозитория существуют два основных подхода. Первый подход — импорт в Git уже существующего проекта или каталога. Второй — клонирование уже существующего репозитория с сервера. Создание репозитория в существующем каталоге Если вы собираетесь начать использовать Git для существующего проекта, то вам необходимо перейти в проектный каталог и в командной строке ввести $ git init

Слайд 25





Версионный контроль
Если вы хотите добавить под версионный контроль существующие файлы (в отличие от пустого каталога), вам стоит проиндексировать эти файлы и осуществить первую фиксацию изменений. Осуществить это вы можете с помощью нескольких команд git add указывающих индексируемые файлы, а затем commit:
$ git add *.c
$ git add README
$ git commit -m 'initial project version'
Мы разберём, что делают эти команды чуть позже. На данном этапе, у вас есть Git-репозиторий с добавленными файлами и начальным коммитом.
Описание слайда:
Версионный контроль Если вы хотите добавить под версионный контроль существующие файлы (в отличие от пустого каталога), вам стоит проиндексировать эти файлы и осуществить первую фиксацию изменений. Осуществить это вы можете с помощью нескольких команд git add указывающих индексируемые файлы, а затем commit: $ git add *.c $ git add README $ git commit -m 'initial project version' Мы разберём, что делают эти команды чуть позже. На данном этапе, у вас есть Git-репозиторий с добавленными файлами и начальным коммитом.

Слайд 26





Клонирование существующего репозитория

Клонирование репозитория осуществляется командой git clone [url]. Например, если вы хотите клонировать библиотеку Ruby Git, известную как Grit, вы можете сделать это следующим образом:
$ git clone git://github.com/libgit2/rugged.git
Эта команда создаёт каталог с именем rugged, инициализирует в нём каталог .git, скачивает все данные для этого репозитория и создаёт (checks out) рабочую копию последней версии. Если вы зайдёте в новый каталог rugged, вы увидите в нём проектные файлы, пригодные для работы и использования.
Описание слайда:
Клонирование существующего репозитория Клонирование репозитория осуществляется командой git clone [url]. Например, если вы хотите клонировать библиотеку Ruby Git, известную как Grit, вы можете сделать это следующим образом: $ git clone git://github.com/libgit2/rugged.git Эта команда создаёт каталог с именем rugged, инициализирует в нём каталог .git, скачивает все данные для этого репозитория и создаёт (checks out) рабочую копию последней версии. Если вы зайдёте в новый каталог rugged, вы увидите в нём проектные файлы, пригодные для работы и использования.

Слайд 27





Клонирование существующего репозитория

Если вы хотите клонировать репозиторий в каталог, отличный от rugged, можно это указать в следующем параметре командной строки:
$ git clone git://github.com/libgit2/rugged.git myrugget
Описание слайда:
Клонирование существующего репозитория Если вы хотите клонировать репозиторий в каталог, отличный от rugged, можно это указать в следующем параметре командной строки: $ git clone git://github.com/libgit2/rugged.git myrugget

Слайд 28





Запись изменений в репозиторий
Описание слайда:
Запись изменений в репозиторий

Слайд 29





Определение состояния файлов

Основной инструмент, используемый для определения, какие файлы в каком состоянии находятся — это команда git status. Если вы выполните эту команду сразу после клонирования, вы увидите что-то вроде этого:
$ git status # On branch master nothing to commit (working directory clean) 
Это означает, что у вас чистый рабочий каталог, другими словами — в нём нет отслеживаемых изменённых файлов. Git также не обнаружил неотслеживаемых файлов, в противном случае они бы были перечислены здесь. И наконец, команда сообщает вам на какой ветке (branch) вы сейчас находитесь. Пока что это всегда ветка master — это ветка по умолчанию. Позже подробно поработаем с ветками и ссылками.
Описание слайда:
Определение состояния файлов Основной инструмент, используемый для определения, какие файлы в каком состоянии находятся — это команда git status. Если вы выполните эту команду сразу после клонирования, вы увидите что-то вроде этого: $ git status # On branch master nothing to commit (working directory clean) Это означает, что у вас чистый рабочий каталог, другими словами — в нём нет отслеживаемых изменённых файлов. Git также не обнаружил неотслеживаемых файлов, в противном случае они бы были перечислены здесь. И наконец, команда сообщает вам на какой ветке (branch) вы сейчас находитесь. Пока что это всегда ветка master — это ветка по умолчанию. Позже подробно поработаем с ветками и ссылками.

Слайд 30





Графические интерфейсы

GitKraken — кроссплатформенный бесплатный клиент Git. 
SmartGit — кроссплатформенный интерфейс для Git на Java. 
gitk — простая и быстрая программа, написана на Tcl/Tk, распространяется с самим Git. 
QGit, интерфейс которого написан с использованием Qt, во многом схож с gitk, но несколько отличается набором возможностей. В настоящее время существуют реализации на Qt3 и Qt4. 
Giggle — вариант на Gtk+. 
gitg — ещё один интерфейс для gtk+/GNOME 
Git Extensions — кроссплатформенный вариант на .NET. 
TortoiseGit — интерфейс, реализованный как расширение для проводника Windows. 
SourceTree — бесплатный git клиент для Windows и Mac. 
Git-cola — кроссплатформенный интерфейс на Python. 
GitX — оболочка для Mac OS X с интерфейсом Cocoa, интерфейс схож с gitk. 
Gitti — оболочка для Mac OS X с интерфейсом Cocoa. 
Gitbox — оболочка для Mac OS X с интерфейсом Cocoa. 
Github-клиент 
StGit — написанная на Python система управления коллекцией патчей (Catalin Marinas) 
GitTower — коммерческий клиент Git для Mac и Windows
Описание слайда:
Графические интерфейсы GitKraken — кроссплатформенный бесплатный клиент Git. SmartGit — кроссплатформенный интерфейс для Git на Java. gitk — простая и быстрая программа, написана на Tcl/Tk, распространяется с самим Git. QGit, интерфейс которого написан с использованием Qt, во многом схож с gitk, но несколько отличается набором возможностей. В настоящее время существуют реализации на Qt3 и Qt4. Giggle — вариант на Gtk+. gitg — ещё один интерфейс для gtk+/GNOME Git Extensions — кроссплатформенный вариант на .NET. TortoiseGit — интерфейс, реализованный как расширение для проводника Windows. SourceTree — бесплатный git клиент для Windows и Mac. Git-cola — кроссплатформенный интерфейс на Python. GitX — оболочка для Mac OS X с интерфейсом Cocoa, интерфейс схож с gitk. Gitti — оболочка для Mac OS X с интерфейсом Cocoa. Gitbox — оболочка для Mac OS X с интерфейсом Cocoa. Github-клиент StGit — написанная на Python система управления коллекцией патчей (Catalin Marinas) GitTower — коммерческий клиент Git для Mac и Windows

Слайд 31


Технология и процесс разработки ПО. Лекция 6, слайд №31
Описание слайда:

Слайд 32


Технология и процесс разработки ПО. Лекция 6, слайд №32
Описание слайда:

Слайд 33


Технология и процесс разработки ПО. Лекция 6, слайд №33
Описание слайда:



Похожие презентации
Mypresentation.ru
Загрузить презентацию