Ответ:Контроль версий, также известный как управление исходным кодом, — это практика отслеживания изменений программного кода и управления ими. Системы контроля версий — это программные инструменты, помогающие командам разработчиков управлять изменениями в исходном коде с течением времени.
Первоначальная настройка Git Туту сылка на сайт c полной инфой
Теперь, когда Git установлен в вашей системе, самое время настроить среду для работы с Git под себя. Это нужно сделать только один раз — при обновлении версии Git настройки сохранятся. Но, при необходимости, вы можете поменять их в любой момент, выполнив те же команды снова.
В состав Git входит утилита git config, которая позволяет просматривать и настраивать параметры, контролирующие все аспекты работы Git, а также его внешний вид. Эти параметры могут быть сохранены в трёх местах:
- Файл [path]/etc/gitconfig содержит значения, общие для всех пользователей системы и для всех их репозиториев. Если при запуске git config указать параметр --system, то параметры будут читаться и сохраняться именно в этот файл. Так как этот файл является системным, то вам потребуются права суперпользователя для внесения изменений в него.
- Файл ~/.gitconfig или ~/.config/git/config хранит настройки конкретного пользователя. Этот файл используется при указании параметра --global и применяется ко всем репозиториям, с которыми вы работаете в текущей системе.
- Файл config в каталоге Git (т. е. .git/config) репозитория, который вы используете в данный момент, хранит настройки конкретного репозитория. Вы можете заставить Git читать и писать в этот файл с помощью параметра --local, но на самом деле это значение по умолчанию. Неудивительно, что вам нужно находиться где-то в репозитории Git, чтобы эта опция работала правильно.
Настройки на каждом следующем уровне подменяют настройки из предыдущих уровней, то есть значения в .git/config перекрывают соответствующие значения в [path]/etc/gitconfig.
В системах семейства Windows Git ищет файл .gitconfig в каталоге $HOME (C:\Users$USER для большинства пользователей). Кроме того, Git ищет файл [path]/etc/gitconfig, но уже относительно корневого каталога MSys, который находится там, куда вы решили установить Git при запуске инсталлятора.
Если вы используете Git для Windows версии 2.х или новее, то так же обрабатывается файл конфигурации уровня системы, который имеет путь C:\Documents and Settings\All Users\Application Data\Git\config в Windows XP или C:\ProgramData\Git\config в Windows Vista и новее. Этот файл может быть изменён только командой git config -f , запущенной с правами администратора.
Чтобы посмотреть все установленные настройки и узнать где именно они заданы, используйте команду:
$ git config --list --show-origin
Имя пользователя Первое, что вам следует сделать после установки Git — указать ваше имя и адрес электронной почты. Это важно, потому что каждый коммит в Git содержит эту информацию, и она включена в коммиты, передаваемые вами, и не может быть далее изменена:
$ git config --global user.name "John Doe"
$ git config --global user.email [email protected]
Опять же, если указана опция --global, то эти настройки достаточно сделать только один раз, поскольку в этом случае Git будет использовать эти данные для всего, что вы делаете в этой системе. Если для каких-то отдельных проектов вы хотите указать другое имя или электронную почту, можно выполнить эту же команду без параметра --global в каталоге с нужным проектом.
Многие GUI-инструменты предлагают сделать это при первом запуске.
Использую команду git branch мы можем увидеть список всех открытых веток. Командой git branch name_branch мы можем создать новую ветку. С помощью команды git checkout branch_name мы можем перейти на нужную нам ветку.
Как сделать pull request ● Делаем fork репозитория ● Делаем clone СВОЕЙ версии репозитория ● Создаем новую ветку и в НЕЕ вносим свои изменения ● Фиксируем изменения (делаем коммиты) ● Отправляем свою версию в свой GitHub ● На сайте GitHub нажимаем кнопку pull request
Мы сравнили несколько популярных решений, чтобы вам было проще сделать выбор.
Это узкоспециальная техническая тема. Мы постарались сделать наш обзор понятным для всех. Но если у вас нет опыта в программировании, обязательно посоветуйтесь с вашим отделом разработки, прежде чем принимать решения.
CVS появилась в 1980-х и до сих пор популярна как у разработчиков коммерческих продуктов, так и у open-source разработчиков.
CVS распространяется на условиях Открытого лицензионного соглашения GNU и позволяет получать с сервера нужную версию проекта — «check-out» (извлечение), а затем пересылать обратно на сервер, «check-in» (возврат), с внесенными изменениями.
Изначально CVS была создана, чтобы избежать конфликта версий. Всем участникам для работы предоставлялась только самая последняя версия кода. Это была первая система контроля версий. Пользователю нужно было быстро фиксировать изменения в репозитории, пока другие не опередили его.
Сейчас CVS имеет поддержку работы над проектами с ветками кода. Получается несколько вариантов продукта с разными характеристиками, которые можно будет объединить позднее.
Сервера CVS обычно работают под управлением Unix, но CVS-клиенты доступны и в других популярных операционных системах. CVS — «зрелая», проверенная временем система контроля версий. Это по-прежнему опенсорсная система, но на сегодняшний день новые функции добавляются довольно редко.
При этом CVSNT, — выделившаяся в отдельный проект версия CVS для серверов Windows, — сейчас достаточно активно расширяет функционал.
Преимущества: Испытанная временем технология, которая удерживается на рынке десятки лет. Недостатки: Переименование или перемещение файлов не отражается в истории Риски безопасности, связанные с символическими ссылками на файлы Нет поддержки атомарных операций, что может привести к повреждению кода Операции с ветками программного кода дорогостоящие, так как эта система контроля не предназначена для долгосрочных проектов с ветками кода
SVN создавалась как альтернатива CVS с целью исправить недостатки CVS и в то же время обеспечить высокую совместимость с ней.
Как и CVS, SVN это бесплатная система контроля версий с открытым исходным кодом. С той лишь разницей, что распространяется под лицензией Apache, а не под Открытым лицензионным соглашением GNU.
Для сохранения целостности базы данных SVN использует так называемые атомарные операции. При появлении новой версии к финальному продукту применяются либо все исправления, либо ни одно из них. Таким образом, код защищают от хаотичных частичных правок, которые не согласуются между собой и вызывают ошибки.
Многие разработчики переключились на SVN, так как новая технология унаследовала лучшие возможности CVS и в то же время расширила их.
В то время как в CVS операции с ветками кода дорогостоящие и не предусмотрены архитектурой системы, SVN создана как раз для этого. То есть, для более крупных проектов с ветвлением кода и многими направлениями разработки.
В качестве недостатков SVN упоминаются сравнительно низкая скорость и нехватка распределенного управления версиями. Распределенный контроль версий использует пиринговую модель, а не централизованный сервер для хранения обновлений программного кода. И хотя пиринговая модель работает лучше в open source проектах, она не идеальна в других случаях. Недостаток серверного подхода в том, что когда сервер падает, то у клиентов нет доступа к коду.
Преимущества: Система на основе CVS Допускает атомарные операции Операции с ветвлением кода менее затратны Широкий выбор плагинов IDE Не использует пиринговую модель Недостатки: Все еще сохраняются ошибки, связанные с переименованием файлов и директорий Неудовлетворительный набор команд для работы с репозиторием Сравнительно небольшая скорость