Основы работы с Git — Разработка на vc.ru

2308 просмотров

В процессе разработки ПО значимая роль отводится сотрудничеству. В большинстве случаев деятельность разработчика включает работу в команде и совместное использование проекта с другими специалистами. Практический опыт использования системы контроля версий не просто важен, а ВАЖЕН для всех, кто намерен заниматься разработкой ПО. В то же время будет сложно привить навык использования контроля версий тем начинающим программистам, которые во время рабочего процесса позволяют коду изливаться из них бурным потоком, вместо того чтобы придержать обороты и размещать его по частям.

Время и целеустремленность все расставляют на свои места, и соблюдение всех правил использования контроля версий постепенно входит в привычку. Предлагаю разбить процесс написания кода на последовательные этапы.

Git послужит в качестве системы контроля версий, а Github — веб-сервиса для хостинга репозиториев Git. Осуществление этого проекта предполагает предварительное создание копии или нового репозитория.

Если же вы этого еще не сделали, но хотите научиться, то добро пожаловать на этот ресурс.

Приступим!

Этап 1. Проверка ветки

Итак, у вас есть собственный репозиторий на локальном компьютере. Прекрасно! И вам уже не терпится написать код, но прошу вас немного подождать и кое-что сделать. Проверьте ветку, на которой вы находитесь. Для этого введите следующую команду в терминал:

git branch

Если увидели этот результат, то притормозите!

Можно написать новый код непосредственно в ветку master при условии, что вы не работаете с директорией приложения, содержащей несколько папок и файлов. Но если вы планируете работу над большим проектом, то лучше этого не делать.

Написание кода прямо в ветку master может повлечь за собой его отправку в онлайн-репозиторий без каких-либо мер предосторожности, а мы же, наоборот, хотим убедиться, что отправленный код работает должным образом.

Итак, что же следует делать, если вы находитесь на ветке master?

Этап 2. Переключение на новую ветку

Во избежание сложностей, связанных с написанием кода прямо в ветку master, следует создать новую ветку на своем локальном компьютере. Для этого введите следующее в терминал:

git checkout -b

Имя ветки должно отражать проблему, ради решения которой она и создается. Если вы намерены создать базу данных, то в качестве имени ветки следует указать create-database.

Этап 3. Написание кода

Приступаем к основной части статьи: непосредственно процесс создания кода!

Будет целесообразно сосредоточиться только на решении задачи, указанной в имени текущей ветки. Основываясь на нашем примере, код в create-database должен способствовать созданию базы данных. Как только вы его написали и он заработал согласно вашему замыслу, самое время им поделиться!

Этап 4. Просмотр статуса

Используя команду git status, мы сможем увидеть все файлы, которые были добавлены, изменены или удалены во время нашего искрометного сеанса программирования.

Если все в полном порядке, то для индексации этих изменений просто введите в терминал следующую команду:

git add .

Зеленый цвет файлов означает, что изменения были проиндексированы:

Этап 5. Создание коммита

Проиндексировав изменения, мы переходим к их фиксации в коде. Git commit сохраняет эти изменения и готовит их для отправки в онлайн-репозиторий. Но не будем спешить — с этой командой мы еще не закончили.

Git предлагает написать комментарий к коммиту. А так как гордое звание программиста (и человека) обязывает развивать в себе коммуникационные навыки, то мы с вами сейчас это сделаем:

git commit -m “useful info about the code I wrote”.

Флаг -m указывает команде git commit, что вы добавляете полезный комментарий о коде. Итак, его уже можно отправлять, но прежде немного задержимся еще на одном этапе.

Этап 6. Проверка ветки

Догадываюсь, что вас не обрадует предложение по нескольку раз вводить в терминал команду git branch. Но так надо. Проверим дважды — от нас не убудет. Затовы избавите себя от необходимости запоминать имена веток, поскольку за вас это сделает инструмент!

Этап 7. Отправка

Итак, код написан, коммиты изменений созданы — пора отправлять их в онлайн-репозиторий, чтобы ваши коллеги-разработчики получили к ним доступ и добавили их на свои локальные компьютеры. Вводим следующую команду:

git push origin

Вы увидите нечто подобное:

Если вы используете VScode, то эта команда + клик на http-адрес перенесут вас на этап 8. И вот ваша ветка запущена в эфир!

Этап 8. Запросы на слияние

На этом этапе мы готовы, можно сказать сгораем от нетерпения, написать дополнительный код. Но прежде посмотрим, что же мы отправили. Перейдите на онлайн-репозиторий Github и сделайте запрос на слияние ветки:

Кликните на Pull request для активации процесса

Таким образом вы даете понять, что содержимое ветки безопасно для слияния с веткой master.

Если все идет по плану, то произойдет успешное слияние веток и другие разработчики получат доступ к написанному вами коду.

Этап 9. Лицом к лицу с master

На данный момент ветка master в онлайн-репозитории содержит больше кода, чем в локальном. Надо бы это исправить. Вернитесь на ветку master и введите в терминал следующую команду:

git pull origin master

Если все сработало, то вы увидите эти зеленые строки плюсов:

Этап 10. Итоги

На этом этапе вы должны определиться с функциональностями, которые хотели бы разрабатывать в дальнейшем. Начинайте процесс с этапа 2, и пусть осознание того, что вы четко выполняете все правила работы с Git, бережет ваш покой!

В завершении статьи хочу сказать, что еще больше полезной и нужной информации вы найдете в нашем Telegram-канале. Подпишитесь, мне будет очень приятно.

Оригинал данной статьи на английском:Alex Mata: Introduction to Git Workflow

Что такое Git? — Azure DevOps

  • Статья
  • Чтение занимает 3 мин

Git стал мировым стандартом для управления версиями. Так что же именно это?

Git — это распределенная система управления версиями, то есть локальный клон проекта — это полный репозиторий управления версиями. Полнофункциональные локальные репозитории упрощают работу как в автономном, так и в удаленном режиме. Разработчики фиксируют свою работу локально, а затем синхронизируют свою копию репозитория с копией на сервере. Эта парадигма отличается от централизованных систем управления версиями, где клиенты должны синхронизировать код с сервером перед созданием новой версии кода.

Гибкость и популярность Git делают его отличным выбором для любой команды. Многие разработчики и выпускники колледжей уже знают, как использовать Git. Сообщество пользователей Git создало ресурсы для обучения разработчиков и популярности Git упрощает получение помощи при необходимости. Почти каждая среда разработки поддерживает Git и средства командной строки Git, реализованные в каждой основной операционной системе.

Основы Git

При каждом сохранении работы Git создает фиксацию. Фиксация — это моментальный снимок всех файлов в определенный момент времени. Если файл не изменился с одной фиксации на следующую, Git использует ранее сохраненный файл. Эта конструкция отличается от других систем, которые хранят начальную версию файла и сохраняют запись изменений с течением времени.

Фиксации создают ссылки на другие фиксации, формируя граф журнала разработки. Можно вернуть код к предыдущей фиксации, проверить, как файлы изменились с одной фиксации на следующую, и просмотреть сведения о том, где и когда были внесены изменения. Фиксации идентифицируются в Git уникальным криптографическим хэшом содержимого фиксации. Так как все хэшируется, невозможно вносить изменения, терять сведения или повреждены файлы без обнаружения Git.

Ветви

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

Файлы и фиксации

Файлы в Git находятся в одном из трех состояний: измененных, промежуточных или зафиксированных. При первом изменении файла изменения существуют только в рабочем каталоге. Они еще не являются частью фиксации или истории разработки. Разработчик должен подготовить измененные файлы для включения в фиксацию. Промежуточная область содержит все изменения, которые необходимо включить в следующую фиксацию. Когда разработчик доволен промежуточными файлами, файлы упаковываются в виде фиксации с сообщением, описывающим изменения. Эта фиксация становится частью истории разработки.

Промежуточное хранение позволяет разработчикам выбирать изменения файлов для сохранения в фиксации, чтобы разбить большие изменения на ряд небольших фиксаций. Уменьшая область фиксаций, проще просмотреть журнал фиксаций, чтобы найти определенные изменения в файле.

Преимущества Git

Преимущества Git много.

Одновременная разработка

Каждый имеет собственную локальную копию кода и может работать одновременно с собственными ветвями. Git работает в автономном режиме, так как почти каждая операция является локальной.

Более быстрые выпуски

Ветви обеспечивают гибкую и одновременную разработку. Основная ветвь содержит стабильный высококачественный код, из которого вы выпускаете. Ветви компонентов содержат выполняемые действия, которые объединяются в главную ветвь после завершения. Отделяя ветвь выпуска от выполняющейся разработки, проще управлять стабильным кодом и отправлять обновления быстрее.

Встроенная интеграция

Благодаря популярности Git интегрируется в большинство инструментов и продуктов. Каждая основная интегрированная среда разработки имеет встроенную поддержку Git, а многие средства поддерживают непрерывную интеграцию, непрерывное развертывание, автоматическое тестирование, отслеживание рабочих элементов, метрики и интеграцию функций создания отчетов с Git.  Эта интеграция упрощает повседневный рабочий процесс.

Git является открытым исходным кодом и стал де-факто стандартом для управления версиями. Нет недостатка в средствах и ресурсах, доступных командам для использования. Объем поддержки сообщества для Git по сравнению с другими системами управления версиями упрощает получение помощи при необходимости.

Git работает с любой командой

Использование Git с средством управления исходным кодом повышает производительность команды, поощряя совместную работу, применяя политики, автоматив процессы и повышая видимость и трассировку работы. Команда может урегулировать отдельные средства для управления версиями, отслеживания рабочих элементов, а также непрерывной интеграции и развертывания. Кроме того, они могут выбрать решение, например GitHub или Azure DevOps , которое поддерживает все эти задачи в одном месте.

Запросы на вытягивание

Используйте запросы на вытягивание , чтобы обсудить изменения кода с командой, прежде чем объединить их в главную ветвь. Обсуждения в запросах на вытягивание являются бесценными для обеспечения качества кода и повышения знаний в вашей команде. Такие платформы, как GitHub и Azure DevOps, предлагают широкий интерфейс запроса на вытягивание, где разработчики могут просматривать изменения файлов, оставлять комментарии, проверять фиксации, просматривать сборки и голосовать за утверждение кода.

Политики ветвления

Teams может настроить GitHub и Azure DevOps для обеспечения согласованных рабочих процессов и процессов в команде. Они могут настроить политики ветви , чтобы убедиться, что запросы на вытягивание соответствуют требованиям перед завершением. Политики ветвей защищают важные ветви, предотвращая прямые отправки, требуя рецензентов и обеспечивая очистку сборок.

Следующие шаги

Установка и настройка Git

Изучение Git — учебные пособия, рабочие процессы и команды

Основы Git

Git — это бесплатная система управления версиями с открытым исходным кодом, первоначально созданная Линусом Торвальдсом в 2005 году.

В отличие от более старых централизованных систем управления версиями, таких как SVN и CVS, Git является распределенным: каждый разработчик имеет полную историю своего репозитория кода локально. Это делает первоначальное клонирование репозитория медленнее, но последующие операции, такие как фиксация, обвинение, сравнение, слияние и регистрация, значительно ускоряются.

Git также имеет отличную поддержку ветвления, слияния и перезаписи истории репозитория, что привело к появлению множества инновационных и мощных рабочих процессов и инструментов. Запросы на вытягивание — один из таких популярных инструментов, который позволяет командам совместно работать над ветками Git и эффективно просматривать код друг друга. На сегодняшний день Git является наиболее широко используемой системой контроля версий в мире и считается современным стандартом для разработки программного обеспечения.

Как работает Git

Вот общий обзор того, как работает Git:

  1. Создайте «репозиторий» (проект) с помощью инструмента хостинга git (например, Bitbucket)
  2. Скопируйте (или клонируйте) репозиторий на свой локальный компьютер
  3. Добавьте файл в локальное репо и «зафиксируйте» (сохраните) изменения
  4. «Отправьте» ваши изменения в вашу основную ветку
  5. Внесите изменения в свой файл с помощью инструмента хостинга git и зафиксируйте
  6. «Вытяните» изменения на свой локальный компьютер
  7. Создайте «ветку» (версию), сделайте изменение, зафиксировать изменение
  8. Открыть «pull request» (предложить изменения в основной ветке)
  9. «Объединить» вашу ветку с основной веткой

Начало работы с Git

Git Download

Mac OS/X

Download InstallerHomebrewMacPortsSourcetreeBuild Git для Mac OS X

Изучите Git

Изучение Git с помощью Bitbucket CloudУзнайте о проверке кода в Bitbucket CloudLearn Ветвление с помощью Bitbucket CloudLearn Отмена изменений с помощью Bitbucket Cloud

Новичок

Что такое контроль версийЧто такое GitПочему Git для вашей организацииУстановить архив GitGit SSHGitШпаргалка GitOpsGit

Начало работы

Настройка репозиторияСохранение измененийПроверка репозиторияОтмена измененийПерезапись истории

Совместная работа

СинхронизацияСоздание запроса на вытягиваниеИспользование ветвейСравнение рабочих процессов

Миграция на Git

SVN в Git — подготовка к миграцииПереход на Git с SVNPerforce на Git — зачем делать переходМиграция с Perforce на Git

Дополнительные советы

Расширенные руководства по GitСлияние и перебазированиеReset, Checkout и RevertРасширенный журнал GitGit HooksRefs и ReflogПодмодули GitGit subtreeGit LFSGit gcGit pruneБольшие репозитории в GitGit bashКак хранить точечные файлыGit cherry pickGitKGit-show

0004 9009 Просмотреть все руководства0034 Популярные сообщения

Мэтт Шелтон

Git или SVN? Как Nuance Healthcare выбрала модель ветвления Git?

Читать статью

Мэтт Шелтон

Работа с зависимостями Maven при переходе на Git

Прочитать статью

Просмотреть все статьи

Знаете ли вы.

..

Филиал

Определение:  Филиал представляет собой независимую линию развития. Ветки служат абстракцией для процессов редактирования/стадии/фиксации, описанных в Git Basics, первом модуле этой серии. Вы можете рассматривать их как способ запросить новый рабочий каталог, промежуточную область и историю проекта. Новые коммиты записываются в историю для текущей ветки, что приводит к разветвлению истории проекта.

Просмотреть все ссылки

Основные команды Git | Atlassian Git Tutorial

git добавить

Перемещает изменения из рабочего каталога в промежуточную область. Это дает вам возможность подготовить моментальный снимок, прежде чем заносить его в официальную историю.

Сохранение изменений: git addИзучение Git с помощью Bitbucket Cloud: копирование репозитория Git и добавление файловИспользование веток: git mergeПроверка репозитория: git status

ветка git

Эта команда является вашим универсальным инструментом администрирования филиала. Он позволяет создавать изолированные среды разработки в одном репозитории.

Использование веток: git branchИспользование веток: git checkoutИспользование веток: git mergeИзучение Git с Bitbucket Cloud: использование ветки Git для слияния файла

git checkout

Помимо проверки старых коммитов и старых версий файлов, git checkout также является средством навигации по существующим веткам. В сочетании с основными командами Git это способ работать над определенной линией разработки.

Использование веток: git checkoutОтмена изменений: git checkoutСравнение рабочих процессов: рабочий процесс Gitflow

гит чистый

Удаляет неотслеживаемые файлы из рабочего каталога. Это логический аналог git reset, который (обычно) работает только с отслеживаемыми файлами.

Отмена изменений: git clean

git clone

Создает копию существующего репозитория Git. Клонирование — наиболее распространенный способ для разработчиков получить рабочую копию центрального репозитория.

Git LFSСравнение рабочих процессов: разветвление рабочего процессаНастройка репозитория: git clone

git совершить

Делает подготовленный моментальный снимок и фиксирует его в истории проекта. В сочетании с git add это определяет основной рабочий процесс для всех пользователей Git.

Использование веток: git mergeПереписывание истории: git commit —amendИзучение Git с помощью Bitbucket Cloud: Скопируйте репозиторий Git и добавьте файлы Сохранение изменений: git add

git commit —amend

Передача флага —amend в git commit позволяет изменить самый последний коммит. Это очень полезно, когда вы забыли подготовить файл или упустили важную информацию из сообщения фиксации.

История перезаписи: git commit —amend

git config

Удобный способ задать параметры конфигурации для установки Git. Обычно вам нужно использовать это только сразу после установки Git на новую машину для разработки.

Настройка репозитория: git configGit LFSInstall Git: установка Git в Mac OS XInstall Git: установка Git в Linux

git fetch

При извлечении ветка загружается из другого репозитория вместе со всеми связанными фиксациями и файлами. Но он не пытается ничего интегрировать в ваш локальный репозиторий. Это дает вам возможность проверить изменения, прежде чем объединять их с вашим проектом.

Синхронизация: git fetchRefs и Reflog: RefspecsSyncing: git pull

git init

Инициализирует новый репозиторий Git. Если вы хотите поставить проект под контроль версий, это первая команда, которую вам нужно выучить.

Настройка репозитория: git init

git log

Позволяет просматривать предыдущие версии проекта. Он предоставляет несколько вариантов форматирования для отображения зафиксированных моментальных снимков.

Проверка репозитория: git logРасширенный журнал Git: фильтрация истории коммитовРасширенный журнал Git: форматирование вывода журналаРасширенные руководства по Git: обзор

слияние git

Мощный способ интеграции изменений из различных ветвей. После разветвления истории проекта с помощью ветки git git merge позволяет снова собрать ее вместе.

Слияние и перемещение: пошаговое руководство по рабочему процессуИспользование ветвей: git mergeСравнение рабочих процессов: рабочий процесс GitflowСлияние и перемещение: концептуальный обзор

git pull

Pulling — это автоматизированная версия git fetch. Он загружает ветку из удаленного репозитория, а затем сразу же объединяет ее с текущей веткой. Это Git-эквивалент svn update.

Синхронизация: git pullComparing Workflows: централизованный рабочий процессGit LFSComparing Workflows: Forking Workflow

git push

Отправка — это противоположность выборке (с некоторыми оговорками). Это позволяет вам переместить локальную ветку в другой репозиторий, что служит удобным способом публикации материалов. Это похоже на коммит svn, но он отправляет серию коммитов вместо одного набора изменений.

Синхронизация: git pushRefs и Reflog: RefspecsСравнение рабочих процессов: Gitflow WorkflowGit LFS

git перебазировать

Перебазирование позволяет перемещать ветки, что помогает избежать ненужных коммитов слияния. Полученную линейную историю часто намного легче понять и исследовать.

Слияние и перебазирование: пошаговое руководство по рабочему процессу История перезаписи: git rebase -iОбъединение и перебазирование: концептуальный обзор История перезаписи: git rebase

git rebase -i

Флаг -i используется для начала интерактивного сеанса перебазирования. Это обеспечивает все преимущества обычной перебазировки, но дает вам возможность добавлять, редактировать или удалять коммиты по ходу дела.

История перезаписи: git rebase -i

git reflog

Git отслеживает обновления в конце ветвей, используя механизм, называемый reflog. Это позволяет вам вернуться к наборам изменений, даже если на них не ссылается ни одна ветвь или тег.

История перезаписи: git reflog

git удаленный

Удобный инструмент для администрирования удаленных подключений. Вместо того, чтобы передавать полный URL-адрес командам fetch, pull и push, он позволяет вам использовать более значимый ярлык.

Синхронизация: удаленный git

сброс git

Отменяет изменения файлов в рабочем каталоге. Сброс позволяет очистить или полностью удалить изменения, которые не были отправлены в общедоступный репозиторий.

Отмена изменений: git resetReset, Checkout и Revert: OperationReset, Checkout и Revert на уровне фиксации: OperationsUndoing Changes на уровне файлов: git clean

git revert

Отменяет зафиксированный моментальный снимок.