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