Содержание

11. Алиасы

Цели

  • Научиться настраивать алиасы и шорткаты для команд git

01 Общие алиасы

Для пользователей Windows:

Выполнить:
git config --global alias.co checkout
git config --global alias.ci commit
git config --global alias.st status
git config --global alias.br branch
git config --global alias.hist "log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short"
git config --global alias.type 'cat-file -t'
git config --global alias.dump 'cat-file -p'

Также, для пользователей Unix/Mac:

git status, git add, git commit, git checkout — общие команды, для которых полезно иметь сокращения.

Добавьте следующее в файл .gitconfig в вашем $HOME каталоге.

Файл:
.gitconfig
[alias]
  co = checkout
  ci = commit
  st = status
  br = branch
  hist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph --date=short
  type = cat-file -t
  dump = cat-file -p

Мы уже успели рассмотреть команды

commit и status, в предыдущем уроке рассмотрели команду log и совсем скоро познакомимся с checkout. Главное, что стоит запомнить из этого урока, так это то, что теперь вы можете вводить git st там, где раньше приходилось использовать git status. Аналогичным образом, пишем git co вместо git checkout и git ci вместо git commit. Что лучше всего, команда git hist позволит избежать ввода очень длинной команды log.

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

02 Задайте алиас hist в файле .gitconfig

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

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

03 Type и Dump

Мы добавили несколько алиасов для команд, которых мы еще не рассматривали. С командой git branch разберемся чуть позже, а команда git cat-file используется для исследования git, в чем мы вскоре убедимся.

04 Алиасы команд (опционально)

Если ваша оболочка поддерживает алиасы или шорткаты, вы можете добавить алиасы и на этом уровне. Я использую:

Файл:
.profile
alias gs='git status '
alias ga='git add '
alias gb='git branch '
alias gc='git commit'
alias gd='git diff'
alias gco='git checkout '
alias gk='gitk --all&'
alias gx='gitx --all'

alias got='git '
alias get='git '

Сокращение gco для команды git checkout особенно полезно. Оно позволяет мне вводить:

gco <branch>

для переключения в отдельную ветку.

И да, я достаточно часто пишу вместо git get или got, поэтому создам алиасы и для них.

24. Создание ветки

Цели

  • Научиться создавать локальную ветку в репозитории

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

01 Создайте ветку

Давайте назовем нашу новую ветку «style».

Выполните:
git checkout -b style
git status

Примечание: git checkout -b <имяветки> является шорткатом для git branch <имяветки> за которым идет git checkout <имяветки>.

Обратите внимание, что команда git status сообщает о том, что вы находитесь в ветке «style».

02Добавьте файл стилей style.css
Выполните:
 
touch lib/style.css
Файл:
lib/style.css
h2 {
  color: red;
}
Выполните:
git add lib/style.css
git commit -m "Added css stylesheet"

03Измените основную страницу

Обновите файл hello.html, чтобы использовать стили style.css.

Файл:
lib/hello.html
<!-- Author: Alexander Shvets ([email protected]) -->
<html>
  <head>
    <link type="text/css" rel="stylesheet" media="all" href="style.css" />
  </head>
  <body>
    <h2>Hello, World!</h2>
  </body>
</html>
Выполните:
git add lib/hello.html
git commit -m "Hello uses style.css"

04Измените index.html

Обновите файл index.html, чтобы он тоже использовал style.css

Файл:
index.html
<html>

 
  <head>
    <link type="text/css" rel="stylesheet" media="all" href="lib/style.css" />
  </head>
  <body>
    <iframe src="lib/hello.html" />
  </body>
</html>
Выполните:
git add index.html
git commit -m "Updated index.html"

05 Далее

Теперь у нас есть новая ветка под названием style с 3 новыми коммитами. Далее мы узнаем, как осуществлять навигацию и переключаться между ветками.

30. Разрешение конфликтов

Цели

  • Научиться разрешать конфликты во время слияния

01 Слияние master с веткой style

Теперь вернемся к ветке style и попытаемся объединить ее с новой веткой master.

Выполните:
git checkout style
git merge master
Результат:
$ git checkout style
Switched to branch 'style'
$ git merge master
Auto-merging lib/hello.html
CONFLICT (content): Merge conflict in lib/hello.html
Automatic merge failed; fix conflicts and then commit the result.

Если вы откроете lib/hello.html, вы увидите:

Файл:
lib/hello.html
<!-- Author: Alexander Shvets ([email protected]) -->
<html>
  <head>
<<<<<<< HEAD
    <link type="text/css" rel="stylesheet" media="all" href="style.css" />
=======
    <!-- no style -->
>>>>>>> master
  </head>
  <body>
    <h2>Hello,World! Life is great!</h2>
  </body>
</html>

Первый раздел — версия во главе текущей ветки (style). Второй раздел — версия ветки master.

02 Решение конфликта

Вам необходимо вручную разрешить конфликт. Внесите изменения в lib/hello.html для достижения следующего результата.

Файл:
lib/hello.html
<!-- Author: Alexander Shvets ([email protected]) -->
<html>
  <head>
    <link type="text/css" rel="stylesheet" media="all" href="style.css" />
  </head>
  <body>
    <h2>Hello, World! Life is great!</h2>
  </body>
</html>

03 Сделайте коммит решения конфликта
Выполните:
 
git add lib/hello.html
git commit -m "Merged master fixed conflict."
Результат:
$ git add lib/hello.html
$ git commit -m "Merged master fixed conflict."
Recorded resolution for 'lib/hello.html'.
[style 645c4e6] Merged master fixed conflict.

04 Расширенные возможности слияния

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

GitHub — kefiriaus/git-how-to

Описание самых основных моментов для начала работы с git

Установка имени и электронной почты

git config --global user.name "Your Name"
git config --global user.email "[email protected]"

Параметры установки окончаний строк

git config --global core.autocrlf input
git config --global core.safecrlf true

Создание репозитория

mkdir hello
cd hello
touch hello.html
git init

Добавление страницы в репозиторий

git add hello.html (Можно 'git add .' для добавление всех файлов каталога в репозиторий)
git commit -m "First Commit"

Проверка статуса репозитория

git status

Добавление изменений в репозиторий

git add hello.html
git status

Коммит изменений

#переход к созданию комментария в редакторе
git commit
#вывод комментария в командной строке
git commit -m 'название коммита'

#изменение существующего коммита
git add hello.html
git commit --amend -m "Add an author/email comment"

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

 
#история изменений
git log

#однострочная история изменений
git log --pretty=oneline


#немного вариантов
git log --pretty=oneline --max-count=2
git log --pretty=oneline --since='5 minutes ago'
git log --pretty=oneline --until='5 minutes ago'
git log --pretty=oneline --author=
git log --pretty=oneline --all


#удобный вывод истории изменений
git log --pretty=format:"%h %ad | %s%d [%an]" --graph --date=short

Алиасы и шорткаты для команд git в файле ~/. #аналогично git checkout [tagname]~1

#просмотр тегов git tag

#просмотр тегов в логах git hi master —all

#удаление тега git tag -d [tagname]

Отмена изменений для файла hello.html

#отмена изменений в рабочем каталоге
git checkout hello.html

 
#отмена проиндексированных изменений
git reset HEAD hello.html
git checkout hello.html


#отмена коммита в локальном репозитории
git revert HEAD --no-edit

Удаление коммита

#для того чтобы коммит не удалился сборщиком мусора ему нужно установить tag
git tag oops

#сброс коммита
git reset --hard [tagname]|[hash]


#показ удаленного коммита с тегом
git hi --all

Перемещение файла в пределах репозитория

Переместить файл hello.html в каталог lib
#средствами git
mkdir lib
git mv hello.html lib

#средствами OS
mkdir lib
mv hello.html lib
git add lib/hello.html
git rm hello.html

Создание ветки в репозитории

git checkout -b [branchname]

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

#без конфликта
git checkout dev
git merge master
git hi --all

 
#решение конфликта вручную
git checkout dev
git merge master
git hi --all
Auto-merging lib/hello.html
CONFLICT (content): Merge conflict in lib/hello.html
Automatic merge failed; fix conflicts and then commit the result.


#необходимо отредактировать файл
vim lib/hello.html
git add lib/hello.html
git commit -m "Merged master fixed conflict."

Преобразование

#сброс ветки dev до слияния
git checkout dev
git hi
git reset --hard [hash]

#сброс ветки master до конфликта
git checkout master
git hi
git reset --hard [hash]
git hist --all

Перебазирование (rebase вместо merge)

git checkout dev
git rebase master
git hi

Rebase VS Merge

Конечный результат перебазирования очень похож на результат слияния. Ветка dev в настоящее время содержит все свои изменения, а также все изменения ветки master. Однако, дерево коммитов значительно отличается. Дерево коммитов ветки dev было переписано таким образом, что ветка master является частью истории коммитов. Это делает цепь коммитов линейной и гораздо более читабельной.
Когда использовать rebase, а когда merge?
Не используйте rebase:
  1. Если ветка является публичной и расшаренной. Переписывание общих веток будет мешать работе других членов команды.
  2. Когда важна точная история коммитов ветки (так как команда rebase переписывает историю коммитов).

Учитывая приведенные выше рекомендации, я предпочитаю использовать rebase для кратковременных, локальных веток, а merge для веток в публичном репозитории.

Клонирование репозитория

git clone hello cloned_hello

Имена удаленных репозиториев

git remote

#более подробно
git remote show origin

Локальные и удаленные ветки

#локальные
git branch

#локальные и удаленные
git branch -a

Извлечение изменений из удаленного репозитория

cd ../cloned_hello
git fetch
git hist --all

#слияние с локальным репозиторием
git merge origin/master


#или вместо fetch и merge
cd ../cloned_hello
git pull
git hist --all

Добавление локальной ветки, отслеживающей изменения удаленной ветки

git branch --track dev origin/dev
git branch -a
git hist --max-count=2

Чистый репозиторий

git clone --bare hello hello.git

Добавление удаленного репозитория

cd hello
git remote add shared ../hello.git

Отправка изменений в удаленный репозиторий

git checkout master
git add README
git commit -m "Added shared comment to readme"
git push shared master

Извлечение изменений с удаленного репозитория

cd ../cloned_hello
git remote add shared ../hello.git
git branch --track shared master
git pull shared master
cat README

Запуск git сервера

#из рабочей директории
git daemon --verbose --export-all --base-path=.

Подключение к git серверу

git clone git://localhost/hello.git network_hello
cd network_hello
ls

курсов: b35apo: en: documentation: githowto: start [CourseWare Wiki]

Как использовать GIT с ключом SSH

При разработке приложений с участием нескольких разработчиков управление исходным кодом может быть эффективно реализовано в системе версий, в нашем случае GITu. Он также может удобно обеспечить распределение исходного кода между, например, домашний компьютер, рабочее место в классе и комплекты разработки МЗАПО из единого репозитория git. Для обучения и выполнения проектов в FEL, GitLab предоставляет хостинг и управление репозиторием GIT. После регистрации в CTU студенты FEL могут использовать GitLab для своих проектов.Если у вас не установлен (повторно) локальный пароль GitLab, используйте кнопку входа в систему SSO для аутентификации.

Для удобной работы с репозиторием GIT рекомендуется зарегистрировать свой публичный SSH-ключ на Git-сервере (SSH-ключ).

Если вы еще не используете SSH-ключ, вы можете создать его (в Linux) с помощью команды ssh-keygen , следуя инструкциям в разделе «Удаленный доступ». По умолчанию публичная и приватная части ключа сохраняются в каталоге .ssh в вашем домашнем каталоге:

 ssh-keygen
кошка ~ /.ssh / id_rsa.pub

Публичная часть ключа ( id_rsa.pub ) регистрируется в вашем профиле GitLab — ни в коем случае не включайте приватную часть ( id_rsa ) вашего ключа:

Значок вашего профиля в правом верхнем углу → Настройки → SSH-ключи

Защищенная ветка GitLab

Ветвь master защищена от обратного изменения ранее записанной истории после создания репозитория. Если вам нужно удалить что-то из его истории и пойти другим путем, то вам нужно отменить набор защиты.Настройки защиты веток и отмены указываются в разделе «Настройки» → «Репозиторий» → «Защищенные ветки» GitLab. Будьте осторожны с использованием, вы нарушите историю для проверки других репозиториев, и, возможно, другим потребуются команды git reset origin / master, чтобы снова встать на путь.

Связанные ресурсы

15 лет Git: как начать работу или узнать что-то новое

Если за последние два десятилетия в программном обеспечении что-то изменилось, то Git находится в верхней части списка.

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

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

Терминология Git

Как и в любом специализированном инструменте, в Git много жаргона.Такие термины, как «клонировать», «объединить» и «перебазировать», в лучшем случае загадочны, а в худшем могут казаться почти исключающими. Попытка понять, что означают все эти термины, может быть непосильной, но не если вы воспользуетесь небольшим руководством из превосходной статьи Мэтью Броберга по Git Terminology 101. Всего за одно быстрое прочтение вы сможете с реальным пониманием слушать разговоры о Git.

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

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

Общие службы Git

Одно из наиболее распространенных применений Git — это общедоступная служба хостинга Git, такая как GitLab и GitHub.В своей статье «Как клонировать, изменять, добавлять и удалять файлы в Git» Кедар Виджай Кулкарни демонстрирует повседневные задачи, которые большинство разработчиков выполняет с помощью Git. Это не является обязательным чтением для не-разработчиков, но обязательно для всех, кто хочет внести свой вклад в проект в общедоступной службе хостинга Git. В этой статье рассматривается Github, поскольку это одна из наиболее распространенных на сегодняшний день платформ, но принципы применимы к любому веб-интерфейсу для Git, включая популярные фреймворки с открытым исходным кодом, такие как GitLab, Gogs и Gitea.

Попробуйте это прохождение Git

Вы предпочитаете экскурсии бесцельным исследованиям? Иногда самый простой способ чему-то научиться — это имитировать чьи-то точные шаги. Вы знаете, что конечный результат — это гарантированный успех, поэтому при выполнении упражнения вы чувствуете себя уверенно, а ваш мозг и пальцы получают пользу от повторения, которое укрепляет память. Если это ваш стиль обучения, следуйте практическому упражнению Алана Форми-Дювалля для Git и узнайте, как выглядит успешный сеанс Git.

Приложения Git

Хотите верьте, хотите нет, но у Git больше интерфейсов, чем текста, который вы вводите в терминал. Очевидно, что в сети есть веб-интерфейсы хостов Git, но вы также можете использовать клиенты Git на своем компьютере. Если вам нужна лишь небольшая помощь, прочтите статью Джесси Даффилда о Lazygit или статью Олафа Андерса о Tig. Чтобы получить полное представление о графическом приложении, прочтите мою статью о Git-cola, Sparkleshare и других. И да, есть даже интерфейсы для ваших мобильных устройств!

Подробнее о Git

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

Avnet HDL git HOWTO (Vivado 2020.2 и новее) | element14

Это обновление популярного сообщения в блоге Avnet HDL git HOWTO (Vivado 2020.1 и ранее).

Возможно, вы знаете, что Avnet предоставляет BSP PetaLinux и другие эталонные проекты для SOM Xilinx Zynq и Zynq UltraScale + Zed (MicroZed, PicoZed и UltraZed) и плат разработки (MiniZed и Ultra96), но знаете ли вы, что Avnet предоставляет Xilinx Vivado TCL и сценарии Linux bash для пользователей, чтобы создавать эти проекты? Avnet предоставляет репозитории git на github для всего, что необходимо пользователям для создания и настройки этих эталонных проектов.Дизайн Xilinx Zynq или Zynq MPSoC, захваченный и встроенный в Vivado, является основой аппаратной платформы для любого программного обеспечения, которое будет создано для работы на нем. Эта статья в блоге будет посвящена созданию эталонной аппаратной платформы с использованием сценария сборки Vivado TCL из репозитория Avnet «hdl» на github.

Прежде чем мы начнем

Смелые предположения:

Пользователь знаком с:

  • команды git
  • Командная строка Linux
  • Инструменты Xilinx Vivado
Программные требования:
  • Ubuntu v16.04 LTS или v18.04 LTS 64-разрядная ОС хоста
  • Инструменты Vivado установлены и лицензированы
Требования к оборудованию:
  • ПК с достаточным объемом оперативной памяти для создания проекта целевого устройства (https: // www. xilinx.com/products/design-tools/vivado/memory.html). Вообще говоря, чем больше устройство, тем больше требуется оперативной памяти. Например, Avnet UltraZed-EV SOM использует устройство Zynq UltraScale + 7EV (самое большое устройство, которое в настоящее время используется на любой плате разработки Avnet или SOM), для которого необходимо установить 11 ГБ ОЗУ.
  • Не менее 100 ГБ свободного места на диске

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

Создание папки репозиториев

Репозитории git должны быть установлены в одну и ту же родительскую папку, поскольку сценарии сборки используют относительные пути для ссылки на необходимые входные файлы. Выберите папку, в которой вы хотите клонировать репозитории git, и запустите сценарии. В этой папке вам потребуется не менее 100 ГБ свободного дискового пространства. Например, вы можете клонировать репозитории в папку / home / / git / avnet.

$ cd ~

$ mkdir -p git / avnet

$ cd git / avnet

Клонировать репозитории

Клонировать репозитории Avnet «hdl» и «bdf». В репозитории «bdf» хранятся файлы определений плат Vivado (BDF), необходимые для создания или открытия любых проектов, предназначенных для известного SOM или платы разработки. Xilinx предоставляет BDF для своих плат (ZC702, ZCU102 и т. Д.) И включает их в установку Vivado. Avnet предоставляет этот репозиторий для BDF, нацеленных на их SOM и платы разработчиков.

$ git clone https://github.com/avnet/bdf.git

В репозитории git «hdl» хранятся все сценарии сборки TCL и входные файлы проекта (файлы ограничений, источники IP и т. Д.) ).

$ git clone https://github.com/avnet/hdl.git

Проверить правильную ветку git

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

$ cd bdf $ git checkout master

$ cd ../hdl $ git checkout 2020.2

Структура файлов репозитория

Репозиторий Avnet для Gitiv projects содержит следующие подкаталоги:

Справочник Описание
плат Содержит подпапки для каждой известной комбинации SBC, SOM и несущей платы.Каждая папка SBC или SOM имеет подпапку для источников, специфичных для проекта (ограничения, сценарии TCL и т. Д.) Для каждого доступного варианта дизайна.
ip Содержит вложенные папки IP-адреса, созданного Avnet, который используется в различных проектах.
проекты Содержит подпапки для конкретных проектов, в которых будет построен проект Vivado. Эта папка игнорируется git.
сценария Эта подпапка и подпапка project_scripts содержат сценарии сборки TCL для платы и конкретной конструкции.
программное обеспечение Устарело. Он не используется ни в одном из текущих сценариев сборки. Он по-прежнему является частью репозитория по устаревшим причинам.

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

Анатомия скрипта сборки

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

скрипт сборки make_u96v2_sbc_base.tcl.

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

  • Имя целевой платы: board = u96v2_sbc
  • Название проекта, который мы создаем: project = base
  • Следует ли также создавать отдельное программное обеспечение через Xilinx SDK: sdk = no
  • Следует ли закрывать проект Vivado после завершения сценария: close_project = yes
  • Архитектура целевого устройства: dev_arch = zynqmp

Эти аргументы передаются сделать.tcl, который затем:

  • Проверьте аргументы, чтобы убедиться, что они действительны
  • Задайте переменную среды TCL для расположения файлов BDF (относительно репозитория hdl git)
  • Задайте переменные среды, чтобы указать расположение плата, IP и файлы проекта
  • Запустите сценарий сборки для конкретного проекта в подпапке project_scripts: u96v2_sbc_base.tcl
  • Создайте любое указанное программное обеспечение с помощью Xilinx SDK (устарело, SDK теперь заменен на Vitis)

Для конкретного проекта скрипт сборки в папке project_scripts (u96v2_sbc_base.tcl) выполнит следующее:

  • Создайте проект Vivado, если он еще не существует
  • Примените любые настройки свойств проекта для конкретной платы (полученные из файла BDF)
  • Создайте любые IP-блоки Avnet, используемые в
  • Создайте дизайн блока Vivado и добавьте блок Zynq или Zynq UltraScale + Processing System (PS). подпапка для определенных плат)
  • Добавьте периферийные устройства, IP-блоки, межсоединения AXI, устройства ввода-вывода и т. д.на устройство Programmable Logic (PL) (извлекается из подпапки Boards для конкретной платы)
  • Импортируйте все необходимые файлы проектных ограничений
  • Создайте файл оболочки HDL и добавьте его в проект
  • Выполните синтез и реализацию для сборки проекта
  • Создайте файл архива для дизайна ( _ _ .xsa)

Инициализируйте среду сборки

Перед запуском Vivado для запуска скрипта сборки мы сначала необходимо создать сценарии оболочки, чтобы установить необходимые переменные среды для инструментов Xilinx Vivado и SDK.

$ source / tools / Xilinx / Vivado / <версия Vivado> /settings64.sh

Примечание! <Версия Vivado> ДОЛЖНА СООТВЕТСТВОВАТЬ ветке git, которая была проверкой репозитория «hdl».

Запустите сценарий сборки Vivado

из командной строки:

$ cd ~ / git / avnet / hdl / scripts

$ vivado -mode -mode batch -source ./make_u96v2_sbc Начнется сборка, и в окне терминала будет отображаться прогресс по мере создания конструкции блока и построения конструкции

После завершения сборки вы можете открыть проект в Vivado.

$ vivado &

Нажмите Открыть проект на панели графического интерфейса быстрого запуска и перейдите в подпапку projects / .

Выберите имя проекта и нажмите OK, чтобы открыть его.

Выполните шаги в . Изучите завершенный проект ниже.

Из графического интерфейса Vivado:

Запустите версию Vivado, которая соответствует ветви, извлеченной из репозитория «HDL», и перейдите в окно консоли TCL.

Перейдите в папку <> / hdl / Scripts.

Запустить сценарий сборки.

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

Изучите завершенный проект

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

Ценность известного хорошего дизайна и начальная точка

Ключевая идея, лежащая в основе этих сценариев сборки TCL и этого репозитория github «hdl», состоит в том, чтобы быстро создать заведомо хороший дизайн, ориентированный на Avnet SOM или SBC , легко и многократно.Возможность начать разработку Xilinx с заведомо хорошей отправной точки имеет решающее значение при проектировании со сложными устройствами, такими как Zynq и Zynq MPSoC. Существует множество деталей конфигурации IP-устройств PS и PL, от настройки контроллера памяти и настроек синхронизации, ограничений ввода-вывода и т. Д., Которые могут вызвать многочасовые мучения для отладки, если они не будут выполнены правильно. Для инженеров Avnet эти сценарии сборки имеют дополнительное преимущество, обеспечивая отправную точку, когда пришло время обновить опубликованный эталонный проект.Общедоступные пользователи также могут использовать эти репозитории и вносить свой вклад.

Git — Как исправить плохую фиксацию

О нет, это беспорядок!

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

Изменить сообщение фиксации

Ой … Вы обнаружили орфографическую ошибку в сообщении фиксации.Не беспокойтесь, вы можете изменить его: 

  git commit --amend -m "новое сообщение"
Войти в полноэкранный режимВыйти из полноэкранного режима

Добавить файлы в последнюю фиксацию

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

  git add <имя_файла>
git commit --amend HEAD ~ 1
Войти в полноэкранный режимВыйти из полноэкранного режима

Отменить фиксацию

Если вы хотите отменить последнюю фиксацию, но сохранить изменения: 

  git reset - мягкая ГОЛОВКА ~ 1
Войти в полноэкранный режимВыйти из полноэкранного режима

Если вы хотите отменить и фиксацию, и изменения: ⚠️ Убедитесь, что вы хотите потерять изменения: 

  git reset --hard HEAD ~ 1
Войти в полноэкранный режимВыйти из полноэкранного режима

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

  git reset --hard origin / <название_ответки>
Войти в полноэкранный режимВыйти из полноэкранного режима

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

  git revert HEAD
Войти в полноэкранный режимВыйти из полноэкранного режима

Если вы только что разрешили некоторые конфликты, завершили слияние и отправили в исходную точку. Но подождите, что-то пошло не так …

Безопасный способ отменить фиксацию слияния, которая уже была отправлена ​​в удаленную ветку, — это использовать команду git revert : 

  git revert -m 1
Войти в полноэкранный режимВыйти из полноэкранного режима

commit_id — это идентификатор фиксации слияния, который вы хотите отменить.

Примечания:

  • Вы также можете отменить любое количество коммитов. Например:

    • git reset HEAD ~ 3 (возврат на три коммита до HEAD).
    • git reset --hard (возврат к определенной фиксации).

  • Используйте git reset , если фиксация еще не отправлена, и вы не хотите вносить плохую фиксацию в удаленную ветку.

  • Используйте git revert , чтобы отменить фиксацию слияния, которая уже была отправлена ​​в удаленную ветку.

  • Используйте git log для просмотра истории коммитов.

  • Если хотите, вы также можете создать новую фиксацию с исправлением.

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

Использование Git — как вернуться к предыдущей фиксации | Толани Бенсон | Startup

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

Вот быстрое и простое руководство о том, как повернуть время вспять в вашем проекте и вернуться к предыдущей версии.

Фото: Icons8 Team на Unsplash

Найдите версию, которую вы хотите вернуть, на

У вас есть два варианта:

1) В терминале вы можете ввести:

 $ git log --oneline

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

2) Вы можете просмотреть историю своих коммитов в репозитории GitHub через веб-сайт GitHub. Это позволяет вам проверять состояние всех файлов в репо при каждой фиксации, чтобы убедиться, что вы возвращаетесь к правильной версии.

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

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

Вернуться к выбранной фиксации в вашей локальной среде

Используйте git checkout и идентификатор (точно так же, как вы бы проверяли ветку), чтобы вернуться:

 $ git checkout .

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

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

Добавьте эту версию в промежуточную область и отправьте на удаленный

Точно так же, как и с любой обычной фиксацией, вы должны добавить все файлы и нажать на удаленную, чтобы сохранить это состояние.

 $ git add. 
 $ git commit -m "Возврат к " 
 $ git push

Дайте себе чуть более информативное сообщение о фиксации — возможно, почему вы возвращаетесь !!

Вот и все! Вы повернули время вспять в своем проекте! Ура!

Git: как перенастроить функциональную ветку из одной ветки в другую

В двух словах: используйте git rebase source-commit --onto target-branch

  • target-branch означает «ветвь, на которой вы хотите основываться»
  • source-commit означает «фиксация перед первой фиксацией функции»

Допустим, my-feature-branch основан на master , и мы хотим, чтобы он был основан на production .Рассмотрим эту историю (самый верхний = последний):

  • фиксация 6 [my-feature-branch]
  • совершить 5
  • фиксация 4 [мастер]
  • совершить 3
  • совершить 2 [производство]
  • совершить 1

Здесь master имеет коммиты, которых еще нет в production (номера 3 и 4).

Простое выполнение простого git rebase production из my-feature-branch не сработает, так как он переместит коммиты с 3 по 6 в производство, эффективно объединяя master в production .Это не то, что мы хотим.

Вместо этого мы хотим отрубить наши коммиты с master (номера 5 и 6) и разместить их на production . Нам нужно сделать это (находясь в my-feature-branch ):

 
 Копировать 
  git rebase --onto production master

Это говорит git, что вы перемещаете коммиты с master на production , и вы получите эту историю в своей недавно перебазированной ветке:

  • фиксация 6 [my-feature-branch]
  • совершить 5
  • совершить 2 [производство]
  • совершить 1

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

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

Вы ищете экспертов DevOps?

У вашей команды разработчиков есть полный список запросов на добавление функций, рутинной работы и рефакторинга. вкупе со сроками? Мы с этим знакомы. С нашим «DevOps как услуга» Предлагая, мы поддерживаем команды разработчиков с инфраструктурой и опытом эксплуатации.

Git: как настроить git для отправки только вашей текущей ветки

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

  • ничего — ничего не нажимать.
  • соответствие — нажать все соответствующие ветви. Все ветви с одинаковыми именами на обоих концах считаются совпадающими. Это значение по умолчанию.
  • восходящий поток — переместить текущую ветвь в восходящую ветвь.
  • tracking — устаревший синоним для восходящего потока .
  • текущая — переместить текущую ветку в одноименную ветку.

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

 
 Копировать 
  $ git config --global push.default
соответствие

Итак, чтобы изменить это, чтобы выдвигать только текущие ветки, просто скажите:

 
 Скопируйте 
  git config --global push.ток по умолчанию

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

Независимо от того, какой вариант вы используете, вы можете вручную выполнить команду git push origin my-branch , чтобы явно протолкнуть только текущую ветку.

Предупреждение с текущим

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

Хотя обычно это именно то, что вам нужно, не настраивает отслеживание между вашей локальной и удаленной ветвями . Это означает, что git pull не будет работать, и Git не будет уведомлять вас, когда ваша локальная и удаленная ветки различаются.

Чтобы создать ветвь с тем же именем на удаленных устройствах отслеживания и , используйте параметр -u :

 
 Копировать 
  git push -u

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

No related posts.