Впервые я начал использовать Git и GitHub несколько лет назад, когда начал полноценную программу веб-разработки под названием Launch School. После изучения основ в начале программы, студентам предлагается фиксировать каждую проблему и задание с этого момента, что я и делал по мере продвижения по курсам. Вот где я ошибся: думая, что действую эффективно, я выполнял задания сразу в конце каждого урока. Я узнал об инструментах, потренировался с упражнениями и освоился с основными командами, но в каком-то смысле я полностью упустил суть Git и GitHub. По правде говоря, роль этих инструментов в рабочем процессе разработчика проста, и я готов поспорить, что вы уже знакомы с некоторыми из основных концепций.
Начнем с Git. Git — это распределенная система контроля версий. Хорошо, но что это на самом деле означает? Давайте разберемся с этим.
Во-первых, это система контроля версий. Линус Торвальдс, создатель Git, охарактеризовал этот инструмент как тупой трекер контента. Он сказал: … вы можете просто рассматривать git как файловую систему — она адресуема по содержимому и имеет понятие управления версиями, но я действительно разработал ее для решения проблемы с точки зрения человека, занимающегося файловой системой… (Источник ). Определение файловой системы Линусом, несомненно, более детально, чем ваше или мое, тем не менее, этот справочник является полезной отправной точкой для понимания основ Git.
Многие люди организовали свои документы по папкам, работали с файлами в текстовом редакторе и, в тот или иной момент, на собственном горьком опыте узнали значение кнопки сохранения. Если вспомнить свои школьные работы, я не просто сэкономил один раз, как делал с заданиями по программированию. Я копил десятки раз, прежде чем сдать доклад своему учителю. Я нажимал «сохранить» в конце каждого вечера, после того, как писал новый абзац, и если бы я делал перерыв, чтобы перекусить. В текстовом редакторе есть такие функции, как кнопка сохранения, которые помогут вам управлять своей работой.
Git — это просто более мощный инструмент, который поможет вам управлять своей работой, фактически любым типом работы, а не только кодом. Он отслеживает не только последнюю версию вашего файла, но и каждую версию, что может быть чрезвычайно полезно, когда вам нужно вернуться в предыдущее состояние. Это была большая картина, которую я сначала упустил.
Давайте представим файл как имеющий линейную шкалу времени. Вы можете пойти в двух направлениях: вы можете двигаться вперед, чтобы сохранить изменения, и двигаться назад, чтобы отменить изменения. Команды Git для сохранения версии файла: git add <filename>
и git commit -m <description>
. Команды Git для отмены лишь немного сложнее, поскольку у вас есть выбор из нескольких вариантов в зависимости от вашей ситуации.
При работе с одним файлом, для которого вы хотите выбросить самые последние изменения, используйте git checkout <filename>
. (Будьте осторожны при использовании git checkout
. Если вы используете git checkout
с идентификатором фиксации вместо имени файла, вы можете получить отсоединенный HEAD
. Это важно знать, потому что, если вы внесете изменения в отсоединенный HEAD
, они не будут восстановлены. Подробнее «здесь»).
При работе с связкой файлов, для которой вы хотите выбросить все самые последние изменения, сначала используйте git diff
, чтобы дважды проверить, не избавляетесь ли вы от любые изменения, которые вы действительно хотите сохранить. Если вы уверены, что хотите отменить изменения во всех своих файлах, используйте git reset --hard HEAD
. Используя эту команду, вам не нужно использовать git checkout
с каждым файлом по отдельности.
Вы также можете вернуть файлы к определенному моменту в истории проекта. Сначала используйте git log
, чтобы просмотреть идентификатор предыдущей фиксации. Скопируйте идентификатор фиксации и вставьте его в эту команду: git reset --hard <commit ID>
. Это приведет к отбрасыванию всех недавних изменений, а также любых коммитов, которые произошли после этого момента в истории проекта. (До сих пор мы только что говорили об отмене локальных, частных изменений. Отмена общедоступных изменений становится немного сложнее. Мы не будем вдаваться в подробности в в этой статье, но важно отметить, что git reset
не следует использовать в общедоступных репозиториях, так как эта команда может переписать историю проекта, от которой зависит кто-то еще. Подробнее здесь).
Если последнее предложение о переписывании истории сбивает с толку, не волнуйтесь. Сейчас мы обсудим вторую часть описания Git, которая, надеюсь, поможет вам разобраться в последней части.
До этого момента мы рассмотрели, как с помощью Git перемещаться между несколькими версиями файлов на локальном компьютере. По сути, это то, что делает Git системой контроля версий. В частности, Git — это распределенная система контроля версий. «Распределенная» часть относится к тому, как Git позволяет нескольким людям работать над проектом. Иногда легче понять концепцию, если сравнить ее с противоположностью, поэтому давайте начнем с этого.
В централизованной системе контроля версий будет одна главная копия проекта. Каждый человек может вытащить часть проекта на свой локальный компьютер, внести правки и отправить изменения напрямую в главную копию. Некоторые из недостатков централизованной системы и, возможно, причины, по которым она больше не является отраслевым стандартом, — это централизованная система, требующая подключения для внесения изменений, влияет на всех, когда фиксируется ошибочный код, и подвержена риску единой точки сбой, если этот сервер выйдет из строя.
Распределенная система контроля версий отличается. Люди, участвующие в проекте, будут загружать все файлы (и историю) на свой компьютер. Каждый человек может вносить изменения локально (онлайн или офлайн), а когда будет готов, отправить весь проект обратно на сервер. Обычная практика — отправить отредактированный проект в удаленную ветку, которая является копией проекта на сервере. Таким образом, изменения могут быть просмотрены, а ветка объединена с основной копией только тогда, когда код не содержит ошибок и готов к производству. Распределенная система контроля версий работает быстро, решает проблему единой точки отказа, потому что любую копию проекта можно отправить на сервер для восстановления, и позволяет множеству людей одновременно работать с одними и теми же файлами. Два члена команды могут даже работать с одними и теми же файлами одновременно для совершенно разных функций. Git — очень популярная, но не единственная распределенная система контроля версий.
Чтобы использовать централизованную или распределенную систему контроля версий, проект должен быть размещен где-то на сервере или компьютере. Однако не каждый разработчик и бизнес хочет или может разместить свой собственный сервер. Для тех, кто использует Git для управления своим проектом, здесь на помощь приходит GitHub. Проще говоря, GitHub — очень популярная, но, опять же, не единственная служба хостинга репозиториев Git. Этот инструмент обеспечивает удобную совместную работу для членов команды, работающих над проектами с использованием Git. Щелкните здесь, чтобы просмотреть короткое анимированное видео о том, как GitHub способствует этому сотрудничеству.
Git и GitHub — это просто инструменты, которые помогут вам управлять своими файлами, вернуть их в рабочее состояние, когда вы ошиблись, и безопасно поделиться своим прогрессом с другими. Для тех, кто учится программировать, я надеюсь, что этот более базовый обзор Git и GitHub поможет вам иметь в виду более широкую картину, когда вы продолжите свое путешествие по программированию, изучите дополнительные команды Git и начнете работать с другими разработчиками.
Помните: требуется время, чтобы новая концепция программирования укоренилась в вашей собственной ментальной модели или новый инструмент должным образом вписался в ваш рабочий процесс. Мое понимание Git, особенно части совместной работы, не менялось, пока я не начал работать в команде. Когда я впервые начал использовать Git, я работал самостоятельно, будучи студентом: у меня было наивное представление о том, как все взаимосвязано, все, что я видел, — это компьютер передо мной, и я нервничал из-за того, что испортил свои файлы. Даже когда я присоединился к команде, я все еще немного нервничал из-за того, что испортил файлы. Это, однако, суть кругового обучения; Мы учимся, практикуемся, учимся снова, иногда повторяя предыдущие уроки. Каждый раз, когда мы возвращаемся к теме, мы углубляем свое понимание и чувствуем себя более комфортно.
Рекомендуемое простое руководство по Git:
Другие источники: