От парня, который удалил мастера.

Я уверен, что вы слышали это 100 раз раньше. Черт, я скажу еще 100 раз: используйте контроль версий.

А еще лучше использовать то, что все знают или слышали в мире программного обеспечения; выберите Git.

Разместите сервер репозитория в частном порядке, если вы не хотите использовать популярные, такие как GitHub, GitLab или Bitbucket - или не делайте этого, если это не ваше что-то.

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

В этом посте я расскажу вам кое-что (вы меня слышали) о git. Если вы не слышали об этом раньше, нажмите и "F" в чате, и давайте продолжим.

Основы

Что такое контроль версий

Контроль версий лучше всего можно описать как точки сохранения в вашем коде. Подумайте об этом так:

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

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

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

Почему вам следует использовать контроль версий

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

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

Фон Git

Git пришел от создателя Linux Линуса Торвальдса в 2005 году для ядра Linux. Каждый репозиторий (также известный как репозиторий) представляет собой полноценное репо с полной историей отслеживания и возможностями контроля версий, независимо от какого-либо центрального сервера. Другие могут получать данные напрямую с вашего компьютера, если вы настроили репо таким образом, но чаще всего обычно используют центральный сервер для совместного использования и размещения файлов для совместной работы.

Полную документацию по инструменту командной строки git (и git в целом) можно найти на git-scm.com.

Что такое репо

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

Используя репозитории, системы контроля версий создают файлы по мере роста проекта, а коммиты (изменения в файлах) добавляются и удаляются.

Инициализация репо

Инициализировать репо можно просто из командной строки (или у большинства удаленных провайдеров есть способ создания репо - на GitHub есть классная ссылка repo.new) с помощью команды в папке, которую вы хотите инициализировать:

/home/[username]/Documents/my-project $ git init

В этой папке, my-project, теперь у вас есть папка .git. Не трогайте вещи, если не знаете, что делаете. Работа с этой папкой может стоить вам локального репо.

Клонирование репо

Отличный способ войти в git - выполнить фиксацию в ранее созданном проекте, либо клонировав тот, который вы сделали из GitHub / GitLab / another-remote-host, с помощью следующей команды:

$ git clone https://github.com/[username]/my-project.git

Это клонирует репо по этой ссылке GitHub в текущий каталог в ./my-project. Конфликты имен будут обсуждаться в командной строке.

Клонирование перенесет все данные проекта на ваш локальный компьютер и создаст локальное рабочее дерево. Изменения здесь не влияют на удаленное репо, если они git push не связаны с коррелированной ветвью удаленного репо.

Совершает

Коммиты - это то, как пользователь «сохраняет» текущие изменения в рабочей папке.

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

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

$ git add --all

Использование флага --all добавляет все измененные файлы в текущий проект git.

Чтобы фактически запустить фиксацию, в консоли выполните:

$ git commit -m "[commit message]"

Создание собственного журнала с контролем версий

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

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

Если вы не на компьютере, почему бы не найти время, чтобы сохранить статью (вы знаете, что хотите 😏🖥💻), чтобы вы могли проверить ее позже.

Теперь, когда вы находитесь за компьютером, откройте терминал. Не волнуйтесь, это не так уж и страшно.

Перейдите в каталог по вашему выбору. Выберите что-то вроде:

1. $ cd /home/$USERNAME/Documents/my-journal
2. $ cd /$USERNAME/Documents/my-journal
3. $ cd C:/Users/

Теперь инициализируйте приложение с помощью:

$ git init

Затем создайте новый документ по вашему выбору. Word, Vim, Nano, Pages, Gedit, PyCharm, заметки, все, что вы можете использовать для текста и написания.

Напишите все, что придет в голову. Всего 750 слов об этом и пиши. Почему 750? Посетите 750words.com, и вы поймете почему.

Как только вы закончите - не волнуйтесь, сделайте это сейчас, и я буду здесь, когда вы вернетесь - давайте сохраним эти изменения. Вы помните, как ездили на работу и все такое. Мы просто просмотрели это (😬) ну, если вы не помните, теперь запускаем в терминале:

$ git add .
$ git commit -m “[type]: [message]”
$ git push origin [master|main|mainline|whatever master is now]

Но вот почему люди меняют хозяина на главного. И ссылку на забавный твит я увидел.

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

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

Замечательные советы

Рабочее дерево

Рабочее дерево относится к состоянию файлов в кассе или каталоге. Например, проект можно клонировать из удаленного репо. Без каких-либо изменений рабочее дерево и HEAD указывают на один и тот же коммит без изменений. Как только файлы меняются, они перестают соответствовать (в том же HEAD), и рабочие деревья становятся другими. Когда изменения фиксируются и отправляются, ваше локальное дерево и удаленное дерево снова сопоставляются с той же ссылкой на фиксацию HEAD. Ссылка на документацию.

Разветвление

Важно использовать ветки в репозитории git. Ну, по сути, вам действительно нужна только одна ветка («master» или «main» или что-то еще), но использование более чем одной ветки очень важно при работе с командой. Это если вы не хотите продолжать исправлять конфликты слияния при каждой фиксации.

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

Чтобы начать работу с ветвлением (вы можете использовать тот же проект журнала, что и раньше, но это не обязательно, поскольку мы будем говорить в основном теоретически с примерами) в репозитории по вашему выбору, выполните следующее, чтобы проверить, какие ветки у вас есть в настоящее время:

$ git branch

Вы должны увидеть список (только master, если вы только инициализировали проект) появившихся веток, которые в настоящее время являются частью репозитория. В списке будет использоваться удаленное имя (обычно origin) перед навигационной цепочкой ветки (например: origin:master, origin:feature/cool-stuff и т. Д.).

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

Чтобы использовать другую ветку (скажем, у нас есть dev, а также master, но сейчас мы находимся на master), просто запустите:

$ git checkout dev or $ git switch dev

Вот и все. Все просто, правда?

Затем при создании новой ветки у нас есть три варианта:

1. $ git checkout -b new-feature
2. $ git branch new-feature
3. $ git switch -c new-feature
  1. Checkout
    Checkout (с флагом -b для ветки) обновит рабочее дерево, чтобы оно соответствовало указанной версии в индексе или указанном дереве, а затем создаст ветвь из этой версии. Осмотр гарантирует, что у вас никогда не возникнет ветвление с оторванной головой, и избавит от многих головных болей. Более подробную информацию можно найти на git-checkout.
  2. Ветка
    Забавно, что опция branch не первая у меня, но меня сначала научили оформлять заказ. Однако Branch просто создаст ветку. Он не переключается автоматически на только что созданную ветку, например checkout или switch. Он также имеет возможность слияния двух ветвей при использовании ссылок на ветки $ git branch master...dev, но не делает это таким чистым, как проверка. Дополнительную информацию можно найти на git-branch.
  3. Переключатель
    Использование параметра switch (с флагом -c для создания) создаст новую заданную ветвь и переключится на эту ветвь. Для переключения не требуется чистый репозиторий, и его можно --detach ‘исключить из основной ветки, а также автоматически переключаться из удаленного репозитория. Более подробную информацию можно найти на git-switch.

Git Flow

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

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

Например, поток, который я считаю лучшим и использую во всех моих проектах, следует этому документу (написанному в разметке):

# Repository Git Flow
The repo git flow is describing how the projects branching works; the "flow" of how the project is built.
For this project, there will be four types of branches:
- master
- release
- hotfix/*
- feature/*
## Master Branch
The master branch is a very special branch. This is the current "stable" working version of the project. It is protected from force pushes meaning that you cannot just add a commit or a merge and push it. Any work added to the master must go through a pull request so that the code can be reviewed, tested and accepted. New features should stem from master, but it's not mandatory.
## Release Branch
The release branch is where the released stable version of the project will be housed. When the project reaches a point it's ready to be released to the public (ie: the game is to be launched) the version of the project that will be deployed is the current version of master merged via pull request into the release branch. The pull request is the final say before the CI/CD pipelines begin their work deploying the version to the various streams (ie: game download page, web servers, etc).
## Hotfix/* Branches
Hotfix branches (branches, as hotfix/ is a folder structure) will be used to create a bug fix off the master branch. Hotfixes work in that they are specifically created for a single issue/bug, and when the bug is fixed (attempt only to touch code related to the bug, and add a test case so the bug can be caught again) it added to a pull request to master and merged back in directly. This keeps the branch focused and narrow so as not to interfere with feature branches. Speaking of...
## Feature/* Branches
Much the same as hotfix branches, feature branchs are a bit broader, encompassing a new feature to the project itself. Feature branches should try to be narrow in scope (ie: feature/multiplayer is too broad, feature/matchmaking is a bit better, feature/server-and-connection is pretty okay too; just try to be specific and focus on one thing that is ready for master (production)).

Я считаю, что это наиболее эффективно при работе над проектами с командами. Для простоты я добавил ветку release в несколько проектов. Тем не менее, я все еще помню, что ветвь master|main всегда должна быть ветвью стабильного выпуска. Это просто означает, что когда функции добавляются в проект, они являются законченными функциями, по крайней мере, с некоторым тестированием.

Есть еще несколько отличных статей о потоке, которые я бы порекомендовал почитать. Тем более ГитКракен.

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

Структурирование коммитов

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

Супер трюки

Git Blame

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

Ты думаешь, это Джо, было пять коммитов Джо и две Джен. Не просматривая все коммиты построчно (было изменено более 1000 строк!), Просто запустите blame ._ 35_, если быть точным.

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

Или вы можете изменить псевдоним с помощью следующей команды:

$ git config --global alias.praise blame

Git Bisect

Я нашел отличную статью о git bisect и о том, как ее можно использовать в рабочих процессах.

Пример (действительно из поста):

Допустим, вы вводите ошибку между 5 коммитами (commit1 последняя известная работа - commit2 - commit3 ошибка, но не знаю - commit4 - commit5) Используя подкоманду git bisect, вы может пройти через ваши коммиты и найти, какой из них не строится правильно - точнее, в каком коммите есть введенная ошибка.

Мне пришлось твитнуть об этом и сохранить то, что я узнал, в образе carbon.now.sh. Скажем, приведенный выше пример - это проект npm:

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

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

Git Commit Amend

Вы просто что-то зафиксировали, а затем файл обновился. Ват. Хорошо, теперь вы хотите добавить это в последний коммит перед тем, как нажать. Достаточно просто с флагом --amend.

Бег: git add --all; git commit --amend сделает свое дело. Это добавит файлы, а затем запустит диспетчер слияния в настроенном $EDITOR из интерфейса командной строки. Если это VIM (⌨️👍), просто :wq из него.

Диспетчер учетных данных Git

Я не изучил его полностью - и когда я это сделаю, я обновлю блог здесь - но GitHub только что выпустил сообщение в блоге о новом универсальном (Windows и macOS только с запланированными Linux) git credential manager, который будет позволяют пользователям хранить информацию с несколькими учетными данными на своих машинах для быстрого создания и развертывания приложений. А пока ознакомьтесь с readme GitHub для получения дополнительной информации.

Это все, что у меня есть по теме Git. Но не обошлось и без финальной истории ...

Почему я удалил Мастера

Итак, история возвращается в школу, когда мы завершали проект, используя Git; один из моих первых разов, я мог бы добавить. Когда проект был завершен, и я хотел сохранить историю коммитов, я решил удалить мастер, повторно перейти от разработки, а затем просто отправить изменения в удаленную ветку. Глупо, я знаю, но не думаю, что ты все равно сейчас заметишь, какой проект 😀.

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

Всего наилучшего и оставайтесь в безопасности - Спенсер