Содержание
Как веб-разработчики, мы часто работаем над локальными сайтами разработки, а затем просто загружаем все, когда закончим. Это хорошо, когда дело касается только вас, а изменения невелики, но когда вы имеете дело с более чем одним человеком, работающим над чем-либо, или над большим проектом со множеством сложных компонентов, это просто неосуществимо. Вот когда мы обратимся к тому, что называется контролем версий.
Сегодня я буду говорить о программном обеспечении для управления версиями с открытым исходным кодом под названием Git. Это позволяет более чем одному человеку безопасно работать над одним проектом, не мешая друг другу, но это гораздо больше, чем это.
Зачем использовать программное обеспечение для контроля версий?
Прежде всего, имя должно дать его. Программное обеспечение для управления версиями позволяет вам иметь «версии» проекта, которые показывают изменения, которые были внесены в код с течением времени, и позволяют вам при необходимости отозвать и отменить эти изменения. Одна только эта способность — сравнивать две версии или изменять изменения, делает ее довольно бесценной при работе над большими проектами.
Возможно, вы даже сделали это в какой-то момент, сохранив копии проекта в разных точках, чтобы у вас была резервная копия. В системе контроля версий будут сохранены только изменения — файл исправления, который можно применить к одной версии, чтобы сделать ее такой же, как и в следующей версии. С одним разработчиком этого достаточно.
Но что, если над проектом работает более одного разработчика? Вот тогда-то и приходит идея централизованного сервера контроля версий. Они долгое время были стандартом, когда все версии хранятся на центральном сервере, а отдельные разработчики извлекают и загружают изменения обратно на этот сервер. Если вы когда-нибудь просматривали историю редактирования страницы Википедии, у вас будет хорошее представление о том, как это работает в сценарии реального мира:
Преимущества такой системы в том, что несколько разработчиков могут вносить изменения, и каждое изменение может быть приписано конкретному разработчику. С другой стороны, тот факт, что все хранится в удаленной базе данных, означает, что никакие изменения не могут быть сделаны, когда тот сервер выходит из строя; и если центральная база данных потеряна, у каждого клиента есть только текущая версия того, над чем он работал.
Это приводит нас к Git и другим так называемым распределенным системам контроля версий. В этих системах клиенты не просто проверяют текущую версию файлов и работают с ними — они отражают всю историю версий. У каждого разработчика всегда есть полная копия всего. Центральный сервер все еще используется, но если произойдет худшее, все можно будет восстановить с любого из клиентов, которые имеют последние версии.
Git специально работает, делая «снимки» файлов; если файлы в той или иной версии остаются неизменными, он просто ссылается на предыдущие файлы — все это остается быстрым и экономным.
Вам также может быть интересно узнать, что Git используется для управления и разработки ядра ядра Linux — базового строительного блока, на котором строятся все дистрибутивы Linux.
Что такое Github?
Хотя вы можете запускать свой собственный сервер Git локально, Github является и удаленным сервером, и сообществом разработчиков, и графическим веб-интерфейсом для управления вашим проектом Git. Можно бесплатно использовать до 5 общедоступных репозиториев — то есть, когда каждый может просмотреть или раскошелиться на ваш код — с недорогими планами для частных проектов. Я настоятельно рекомендую вам зарегистрироваться в бесплатной учетной записи, чтобы вы могли поиграть со своими собственными проектами или разбудить кого-то другого.
Ветвление разветвление
Это основные концепции в Git, так что давайте уделим немного времени, чтобы объяснить разницу.
Вы, наверное, слышали «форк» при работе с дистрибутивами Linux. Если вы знакомы с приложением Plex для медиацентра, вы наверняка узнаете, что оно изначально представляло собой аналог Xbox Media Center с открытым исходным кодом.
, Это просто означает, что когда-то в прошлом некоторые разработчики взяли код XBMC и решили пойти своим путем; это стало Plex.
Это, конечно, полностью разрешено, когда проект с открытым исходным кодом — вы можете взять код и делать с ним все, что захотите. С Git, если вы чувствуете, что ваши изменения достаточно хороши для того, чтобы их можно было откатить в «главный» проект, вы можете сделать «запрос на извлечение» автору, попросив его вернуть ваши изменения в их исходный проект. Это позволяет вам иметь сотни тысяч разработчиков, работающих над проектом в любой момент, ни один из которых не должен быть обязательно одобрен для доступа к коду — они просто копируют код, вносят изменения и запрашивают откат в мастер. Конечно, владельцы оригинального проекта должны решать, принять их изменения или нет.
Ветвление — это то, что делается внутри проекта авторизованными разработчиками. Это позволяет легко разделять конкретные проблемы или функции и работать с ними, не нарушая мастер-файлы. Как только вы убедитесь, что ваша ветвь справилась с этой проблемой, вы объединяете ее с мастером. В любой момент может быть сколько угодно ветвей; они не мешают друг другу. Вы также можете объединить изменения между ветвями, не касаясь мастера.
Вот отличная схема примера рабочего процесса Винсента Дриссена:
В следующий раз мы рассмотрим, как настроить работающий пример Git и внести изменения в код в ветвях. Контроль версий — огромная тема. Я дал только краткий обзор здесь, но как разработчик, который привык просто вносить изменения и отменять их, если они не работают, вся концепция взорвалась у меня в голове — я надеюсь, что она тоже твоя.
Вы опытный разработчик с опытом работы в Git? Вы только начинаете и думаете, что хотите попробовать? Отключить звук в комментариях!
