Освоение Git для эффективной разработки кода и совместной работы

Git - это бесплатный инструмент, который позволяет эффективно изменять код, предоставляя систему распределенного контроля версий. Это один из самых полезных инструментов, которым я научился, когда начал изучать программирование. Работал ли я над своими побочными проектами, сотрудничал с друзьями или работал в профессиональной среде, Git оказался чрезвычайно полезным. Лучшая аналогия, которую я могу вам дать, - это написание отчета для группового проекта на такой платформе, как Google Doc. Ваши коллеги могут одновременно работать над собственным сегментом отчета, не внося непосредственного изменения в вашу часть. Git достигает этих целей, позволяя создавать ветки из основной ветки и позволяя нескольким людям совместно работать над проектом. Я объясню, что такое ветки Git, после прохождения процесса установки. Если вы только начинаете или просто кодируете проекты в одиночку, Git по-прежнему может помочь вам отслеживать историю кодирования, отменять изменения и поддерживать эффективный рабочий процесс.

У вас есть выбор при работе с Git. Я начал свое путешествие на Github еще будучи студентом во время учебы в бакалавриате. Регистрация в качестве студента дает возможность получить бесплатную частную учетную запись Github в Github Education. Если вы студент, ознакомьтесь со скидками здесь. Помимо Github, я также использовал Gitlab для совместной работы над проектами. Вы можете выбрать Github или Gitlab, поскольку они оба предоставляют схожие функции. В этом руководстве основное внимание будет уделено настройке с помощью Github. Если вы хотите перенести репозитории с одной платформы на другую, пожалуйста, обратитесь к документам по миграции здесь или оставьте комментарий ниже, и я буду счастлив написать по нему учебное пособие.

Установка

Linux

$ sudo apt install git-all

Если у вас возникли проблемы или вам нужна установка для других дистрибутивов на базе Unix, посетите здесь.

macOS

Сначала проверьте, установлен ли у вас Git, выполнив следующее:

$ git --version

Если у вас нет последней версии, должен появиться запрос на установку. В противном случае ссылку для установки последней версии можно найти здесь.

Окна

Для Windows нажмите здесь, и загрузка должна начаться автоматически. Это Git для Windows, и, согласно официальной документации Git, Git для Windows отличается от самого Git. Git Windows поставляется с Git BASH, в котором есть эмулятор BASH, поэтому Git можно легко запускать в Windows с помощью функций командной строки. Таким образом, опыт, полученный при запуске команд git в Windows, при необходимости можно легко перенести на другие системы. Другой вариант установки - это установка рабочего стола Github.

Создать учетную запись Github

Войдите в процесс регистрации и создайте учетную запись: https://github.com/join?source=header-home

После того, как вы создали учетную запись Github и вошли в систему, теперь вы можете создавать репозитории. Репозиторий - это место, куда вы помещаете свой проект (ы). Вы можете выбрать один проект для каждого репозитория или у вас может быть репозиторий со многими ветвями. В последнем случае ваши ветки могут быть связаны, но я видел, как пользователи создавали несвязанные ветки в том же репозитории, также известном как сиротские ветки.

ветви

Если вы новичок в управлении версиями и Git, все это может показаться немного запутанным. Мне нравится думать о репозиториях как о еде. Давайте относиться к этому как к обеду благодарения. У вас в тарелке индейка, фарш, клюквенный соус и картофельное пюре. Тарелка, на которой вы будете подавать себе все разные блюда, является хранилищем. Вы можете взять четыре маленькие тарелки (четыре хранилища) и подавать каждый предмет еды на соответствующей тарелке. Другой вариант, возможно, состоит в том, чтобы обслуживать себя каждый из четырех предметов (веток) на большей тарелке (хранилище). Ветка - это снимок вашей основной ветки (главная ветка, напоминающая самое близкое видение моего проекта). Вы делаете этот конкретный снимок и добавляете дополнительные изменения / функции, не затрагивая основную (главную) ветку. Независимо от того, какой метод вы предпочитаете, у вас есть возможность организовать свои проекты с помощью Git в простой и лаконичной форме. Лично я предпочитаю иметь один репозиторий, представляющий проект, а затем внутри репозитория проекта я буду создавать ветки, которые добавляют функции в мой проект.

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

Другие системы контроля версий

Git для хранения данных

Это означает, что Git будет знать обо всех изменениях в вашем локальном репозитории после его инициализации (подробнее об инициализации ниже).

состояния

В данной ветке у вас есть файлы, и в любой момент ваши файлы могут находиться в одном из трех состояний:

  1. Изменено
  2. Постановочный
  3. Преданный идее

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

Создайте свой первый репозиторий

Теперь, когда у нас есть опыт работы с репозиториями и ветвями, давайте создадим наш первый репозиторий. Щелкните в правом верхнем углу, чтобы открыть ссылку «новый репозиторий».

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

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

Заполнить удаленный репозиторий локальными файлами

$ git init

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

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

git remote add origin https://github.com/<username>/<your_repository_name>.git

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

$ git add <file_path>
# commit all files
$ git add .

На данный момент файлы находятся в «промежуточной области».

$ git commit -m “write your commit message here.”

Теперь файлы должны быть безопасно зафиксированы и записаны в локальную базу данных. Теперь, наконец, коммиты можно отправить в удаленный репозиторий с помощью:

$ git push

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

$ git push <remote> — all

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

$ git push <remote> — force

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

Сделайте локальную копию из удаленного репозитория

В приведенном выше примере основное внимание уделяется сценарию, когда на вашем локальном компьютере выполняется работа по разработке, которую вы затем отправляете в удаленный репозиторий. Ситуацию можно изменить, если вам нужно использовать содержимое удаленного репозитория, чтобы начать локальную разработку. В этом случае вам необходимо клонировать интересующий репозиторий, и для этого убедитесь, что у вас есть доступ. Например, вы хотите разработать с помощью начальной загрузки. Вы заходите в репозиторий bootstrap на github: https://github.com/twbs/bootstrap. Нажмите кнопку клонирования или загрузки в репозитории, чтобы скопировать ссылку на удаленный репозиторий.

Клонировать репозиторий с помощью

$ git clone https://github.com/twbs/bootstrap.git

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

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

$ git pull <remote>

Git pull предоставляет вам информацию из удаленного репозитория с помощью (1) git fetch и (2) git merge под капотом. Получение происходит с узла, на котором локальный репозиторий отделился от основной ветки. Вы можете использовать git fetch в любое время, если потребуется отслеживание. Git fetch загружает информацию, недоступную в вашем локальном репозитории, а затем git merge интегрирует информацию в ваш локальный репозиторий. Другая команда, очень похожая на git merge, - это git rebase. Основное преимущество использования git rebase перед git merge заключается в том, что интеграция новой информации происходит в конце последней фиксации в ветке. Это приводит к более линейной истории коммитов, что не всегда бывает при использовании git merge. В случае git pull второй шаг слияния изменений также можно заменить на перебазирование, используя следующее:

$ git pull --rebase <remote>

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

# 1 - stash local changes
$ git stash
# 2 - pull remote changes 
$ git pull 
# 3 - view stashed list
$ git stash list
# 4 - access what you JUST stashed
$ git stash apply 
# 5 - access an older stash from the stashed list on #3
$ git stash apply <stashed-id-from-list>

На этом этапе вы можете спросить, в чем разница между тем, чего мы пытаемся достичь с помощью git clone и git pull? Во-первых, у них разные цели. Git clone берет информацию из удаленного репозитория и делает ее локальную копию. Это разовое действие. Git pull - это команда, используемая для обновления вашего локального репозитория небольших изменений по мере обновления удаленной ветви. Это используется более одного раза, и желательно каждый раз, когда изменение было зафиксировано там, где ваша локальная ветвь отстает.

Конфигурации Git

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

  1. имя пользователя:
$ git config — global user.name <username>

2. Электронная почта:

$ git config — global user.email <email>

3. Сглаживание

$ git config --global alias.<alias> <git-command>

Пример, псевдоним git status только до git s:

$ git config --global alias.s status

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

4. Доступ к глобальному файлу конфигурации.

$ git config --global --edit

Просмотр истории

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

$ git log

Если вы просто запустите команду git log, человеческому глазу будет сложно уследить за результатом. Однако у нас есть варианты украшения журналов, передачи однострочных сообщений фиксации и добавления элемента графика.

# --all shows you the log history in its entirety
# --oneline compresses the commit messages to a single line. 
# --decorate adds branch names and tags from commits
# --graph is a textual graph representation
$ git log --all --decorate --oneline --graph

Еще одна полезная функция - поиск журналов фиксации по шаблонам. Если вы хотите перейти к конкретному изменению, внесенному вами в проект, в котором много соавторов, выполните следующие действия:

$ git log — authors=<username>

Если это сообщение фиксации, содержащее определенную фразу или шаблоны, выполните поиск, используя:

$ git log --grep=”<pattern>”

Изменения для конкретных файлов для каждого коммита можно проанализировать с помощью stat:

$ git log --stat

Изменение истории

Rebase

Используя rebase, вы также можете изменить сроки фиксации. Обычно рекомендуется не перемещать коммиты, которые уже были отправлены в публичный репозиторий. Передача только git rebase берет коммиты из текущей ветки и автоматически применяет их к переданной ветке. Я лично ценю функцию интерактивного перебазирования, где вы можете решить, как коммиты должны быть перенесены на новую базу.

# rebase current branch onto base(tag, commit ID, branch name, etc.)
$ git rebase <base>
# interactive changes
$ git rebase -i <base>

Изменение последней фиксации (ов)

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

# change last commit message
$ git commit --amend

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

Удаление файла из истории фиксации

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

$ git filter-branch --tree-filter 'rm -f sensitive_file.txt' HEAD

Добавление .gitignore

Сценарий, описанный выше, не должен был произойти, если вы создали файл с именем .gitignore и указали свой «чувствительный_файл.txt» как элемент в этом файле. Создание этого файла в вашем локальном каталоге с последующим добавлением файлов резервных копий, конфигураций и т. Д. Избавит вас от беспорядка в вашем удаленном репозитории. Наряду с конкретными именами файлов вы также можете указать шаблоны. Например, если у вас есть * .txt в вашем файле .gitignore, он проигнорирует все текстовые файлы.

Глядя на различия

Изменения в текущем рабочем каталоге можно напрямую сравнить с последней фиксацией в удаленной ветке с помощью:

$ git diff HEAD

HEAD относится к последней фиксации в ветке, в которой вы находитесь.

Отменить изменения

До сих пор мы подробно обсуждали три различных состояния файлов git. Одно из таких состояний - постановка. Если вы хотите отменить поэтапный файл, используйте

$ git reset
# to reset specific files use a file path
$ git reset <file>

После того, как ветка была отправлена, мы все еще можем отменить, изменив конкретную фиксацию с помощью revert. Параметр ‹commit›, показанный ниже, представляет собой конкретную ссылку на фиксацию. Наблюдайте за своими журналами фиксации с помощью git log (упомянутого выше), а затем используйте команду фиксации для команды ниже.

$ git revert <commit>

Заключение

Мы прошли долгий путь от обучения созданию репозиториев Git до понимания того, как исправить наши «ошибки». Понимание Git и привыкание к списку команд в этой статье может занять некоторое время, но это только вопрос времени и практики. Если есть определенные команды, которые невозможно запомнить, используйте метод псевдонима, о котором мы говорили (см. Раздел о конфигурациях Git). Даже если у вас нет проекта, для которого в настоящее время можно использовать Git, создайте фиктивный репозиторий и для практики работайте только с текстовыми файлами. Убедитесь, что ваши проекты хорошо документированы с помощью README.md (см. Раздел о создании вашего первого репозитория) и часто используйте фиксацию. Благодаря этому руководству у вас будет достаточно знаний, чтобы теперь совместно работать над проектами, изменять историю своих проектов и сохранять безупречное портфолио.