Содержание

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 новыми коммитами. Далее мы узнаем, как осуществлять навигацию и переключаться между ветками.

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 в файле ~/.gitconfig

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

Алиасы для bash в файле ~/.bashrc

alias gs='git status '
alias ga='git add '
alias gb='git branch '
alias gc='git commit'
alias gd='git diff'
alias go='git checkout '
alias gk='gitk --all&'
alias gx='gitx --all'
alias gh='git hi'
alias gt='git tag'
alias ght='git hi master --all'
alias gtype='cat-file -t'
alias gdump='cat-file -p'

Переход/Возврат к комиту/тегу/ветке

git checkout [hash]|[tag]|[branchname]

Работа с тегами

#создание тега
git tag [tagname]

#переключение по тегу
git checkout [tagname]


#переключение по тегу к предыдущей версии
git checkout [tagname]^
#аналогично
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

8. Подтверждение изменений

Голы

  • Чтобы научиться фиксировать в репозиторий

01 Фиксация изменений

Ну хватит про постановку. Давайте зафиксируем поэтапные изменения в репозитории.

Когда вы ранее использовали git commit для фиксации первой версии hello.html в репозиторий, вы включили флаг -m , который дает комментарий в командной строке.Команда фиксации позволяет интерактивно редактировать комментарии для фиксации. А теперь давайте посмотрим, как это работает.

Если вы опустите флаг -m в командной строке, git отобразит вас в редакторе по вашему выбору из списка (в порядке приоритета):

  • Переменная среды GIT_EDITOR
  • Настройка конфигурации ядра. Редактора
  • VISUAL переменная среды
  • Переменная среды EDITOR

У меня для переменной EDITOR установлено значение emacsclient (доступно для Linux и Mac).

Давайте зафиксируем сейчас и проверим статус.

Пробег: 
 git совершить

В своем редакторе вы увидите следующее:

Результат: 
 |
# Пожалуйста, введите сообщение фиксации для ваших изменений. Линии начинаются
# с '#' будут проигнорированы, а пустое сообщение прерывает фиксацию.
# На ветке мастера
# Изменения, которые необходимо зафиксировать:
# (используйте "git reset HEAD <файл> ...", чтобы отключить сцену)
#
# изменено: hello.html
#

В первой строке введите комментарий: «Добавлен тег h2».Сохраните файл и выйдите из редактора (чтобы сделать это в редакторе по умолчанию, нажмите ESC, затем введите : wq и нажмите Enter). Вы должны увидеть…

Результат: 
 git commit
В ожидании Emacs ...
[master 569aa96] Добавлен тег h2
 1 файл изменен, 1 вставка (+), 1 удаление (-)

«Ожидание Emacs…» получается из программы emacsclient , отправляющей файл работающей программе emacs и ожидающей ее закрытия. Остальные данные — стандартные сообщения фиксации.

02 Проверка статуса

В конце проверим статус.

Пробег: 
 git статус

Вы увидите…

Результат: 
 $ git status
# На ветке мастера
ничего не фиксировать (рабочий каталог чист)

Рабочий каталог чистый, можно продолжать работу.

курсов: 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, чтобы снова встать на путь.

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

Git: как создавать и применять патчи

Вы можете конвертировать коммиты git в файлы патчей.Они могут быть использованы для применения к другому репозиторию [1] или кем-то еще (например, отправлены при отправке им по электронной почте).

Создание патча

  1. Внесите изменения и зафиксируйте их.
  2. Запустите git format-patch COMMIT_REFERENCE , чтобы преобразовать все коммиты, начиная с упомянутого коммита (не включая его), в файлы патчей.

Например, вы подготовили 2 коммита. Бега:

 
 Копировать 
  git format-patch HEAD ~~

Это создаст 2 файла, по одному для каждого коммита, начиная с HEAD ~~ , например:

 
 Копия 
  0001-make-stuff-more-awesome.пластырь
0002-разрешить-пользователям-быть-заблокирован.patch

Когда фиксация находится в Gitlab , вы можете добавить «.patch» к URL-адресу фиксации, чтобы получить ответ в формате исправления. Сохраните страницу (Ctrl + S) в файл патча и продолжите ниже.

Применение патчей

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

Чтобы применить патч как фиксацию (с его сообщением о фиксации), используйте git am some.патч . \
Чтобы применить все исправления, просто запустите:

 
 Копировать 
  git am * .patch

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

 
 Копировать 
  git am 0002-allow-users-to-be-locked.patch # Может больше не работать для вас

Затем у вас есть 2 нерасположенных коммита из файла патча, созданного ранее.

Дополнительная информация

[1] Обратите внимание, что вы можете добавить другие репозитории / каталоги git в качестве удаленного источника.Иногда вы не хотите (или не можете этого сделать), но все равно можете использовать патчи.

Ознакомьтесь с нашей новой электронной книгой:

Научитесь структурировать большие базы кода Ruby on Rails с помощью инструментов, которые вы уже знаете и любите.

Использование 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 howto — Тут git

ветви

В каком статусе находится моя ветка?

Как пройти в мастер-ветку

Как удалить локальную и удаленную ветку 

 git push --delete origin feature- <номер>
git branch --delete feature- <число>

Как отменить локальные модификации файлов

Иногда лучший способ почувствовать проблему — это погрузиться в нее и играть с кодом.

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

 git checkout - Gemfile # сбросить указанный путь
git checkout - lib bin # также работает с несколькими аргументами

Как отменить локальные коммиты

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

 git reset HEAD ~ 2 # отменить последние две фиксации, сохранить изменения
git reset --hard HEAD ~ 2 # отменить последние две фиксации, отменить изменения

Как удалить файл из git (git reset, git reset –hard HEAD)

или для всех файлов:

Как удалить файл из git (git rm –cached filename)

Если файлы находятся в индексе git:

Как удалить изменения в файле из git (git checkout — имя файла)

С оболочкой zsh:

Написание для чистой истории (git rebase)

Как сжать мои последние X-коммиты вместе с помощью Git?

Сдавите свои коммиты git для чистой истории

Зафиксируйте рано и совершайте часто. blob / {print substr ($ 0,6)}’ | sort —numeric-sort —key = 2 | cut —complement —characters = 13-40 | numfmt —field = 2 —to = iec-i —suffix = B —padding = 7 —round = ближайший 

 76981b406428 54B ПРОЧИТАТЬ.мкр
00ce6b3a9383 67B README.md
71af4f16135f 74B машинописный текст / typescript.rst
923b1678531b 113B frameworks / angular / versions / 7.0 / 7.0.rst
0c27ee76f6f5 122B машинописный текст / версии / 3.1 / 3.1.rst
25d7d6868b40 127B .gitignore
9bc137c5d6a6 167B frameworks / angular / angular.rst
b82fc8b50da9 172B машинописный текст / typescript.rst
eb9dec0b3e56 174B фреймворков / угловой / версии / версии.rst
9f0c65eb24ec 178B машинописный текст / версии / versions.rst
4a8067c30497 197B frameworks / frameworks.rst
c0d826815143 201B Pipfile
539c544b94d1 211B.gitlab-ci.yml
d84c41553ed5 211B рамки / угловые / версии / 7.0 / 7.0.rst
a157a70df495 221B frameworks / angular / versions / versions.rst
1c42b7d1ef77 261B frameworks / angular / версии / versions.rst
a785c282288e 344B каркасы / angular / angular.rst
c252df948d7c 397B frameworks / angular / angular.rst
efc3c9483260 515B index.rst
427e6b8eaf08 549B requirements.txt
c968cda42acf 549B requirements.txt
298ea9e213e8 580B Makefile
31824fd89ccb 598B index.rst
f06d7c779d0b 598B index.rst
d6d9d6d54873 761B Makefile
27f573b87af1 787B марка.летучая мышь
bf081acb1295 883B frameworks / angular / angular.svg
32a043e5b580 2,5KiB conf.py
ec8c00ef69df 8,3KiB frameworks / angular / AngularJS_logo.svg.png
177e0572915e 11 КБ Pipfile.lock
2396b9a349dc 11 КБ Pipfile.lock
399efb7822c0 20 КБ юмор / black_hole_node_modules.png

Как удалить большие файлы из репозитория git?

Пример 

 git clone --mirror git: // example.com / some-big-repo.git
 
 java -jar ~ / projects / bfg-1.13.0.jar --strip-blobs-large-than 1M some-big-repo.git
 
 Удаленные файлы
-------------

    Имя файла Git id
    -------------------------------------------------- ----
    db.dump | 82a870b1 (2,0 ГБ), 05948004 (2,0 ГБ)
    db.zip | aae0628c (307,4 МБ)
    db_col.sql | a7369b9b (60,2 МБ)
    db_col.zip | aae0628c (307,4 МБ)
    тран.zip | b81913ef (1,1 МБ)


Всего было изменено 330 идентификаторов объектов. Полная информация находится здесь:

    /tmp/log_col.git.bfg-report/2018-09-27/16-05-06

Запуск BFG завершен! Когда будете готовы, запустите: git reflog expire --expire = now --all && git gc --prune = now --aggressive


-
Вы можете переписать историю в Git - не позволяйте Трампу делать это по-настоящему!
Администрация Трампа постоянно лгала, чтобы заставить людей сдаться.
говорят правду. Не сдавайтесь: https://www.aclu.org/
-

Настроить хук git

Git: как найти измененные файлы в ветке

29 февраля 2020 г.

( Обновление 2020-03-01: есть способ лучше, см. Ниже )

Ситуация

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

Почему?

GitHub показывает это: полезно видеть в PR. (возможно, ждем сюрпризов)

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

Как этого не делать ..

Сначала я нашел все коммиты в ветке, вручную .

Затем я попытался ввести git log --name-only COMMIT1 COMMIT2 … что было довольно близко.

Список файлов был там … теперь мне нужно было извлечь его из вывода. Мне также нужно было удалить дубликаты (с помощью сортировки | uniq или awk).

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

Лучший способ

Сначала я нашел все коммиты в ветке, вручную .

Давайте пропустим этот шаг, я вернусь к нему через минуту.

Я не знал, что git diff также имеет флаг --name-only !

  # git diff --name-only  
> git diff --name-only fc5ca53 origin / eval-quantile-libs
Gopkg.замок
Makefile
README.md
attack.go
внутренний / cmd / jsonschema / main.go
lib / metrics.go
lib / metrics_test.go
lib / target.schema.json
lib / targets.go
библиотека / target_test.go
>

Да! Только файлы, без дубликатов.

А как насчет «найти все коммиты?» Нашел на обычном месте.

  # git merge-base  
> git merge-base master origin / eval-quantile-libs
fc5ca537bf4f01de94b0458729f455289351397e
>

Давайте еще раз проверим git log --graph :

( нажмите для увеличения )

Выглядит правильно: человек git-merge-base говорит:

Найдите как можно более хороших общих предков для слияния

Все вместе

При подстановке команд можно объединить обе команды в одной строке:

  # git diff --name-only $ (git merge-base  ) 
> git diff --name-only $ (git merge-base master origin / eval-quantile-libs) origin / eval-quantile-libs
Gopkg.замок
Makefile
README.md
attack.go
внутренний / cmd / jsonschema / main.go
lib / metrics.go
lib / metrics_test.go
lib / target.schema.json
lib / targets.go
библиотека / target_test.go
>

Это немного утомительно, вы можете использовать HEAD , если вы уже находитесь в филиале:

  # git diff --name-only $ (git merge-base  ) 
> git diff --name-only $ (git merge-base master HEAD) # <- неявный HEAD
# опущено - но результат тот же!
>

и если master — обычная справочная ветка, вы можете все это автоматизировать:

  # определить функцию:
> git-mod-files () {
> git diff --name-only $ (git merge-base $ {1: -master} HEAD)
>}
> git-mod-files # по умолчанию master
# опущено - но результат тот же!
> git-mod-files origin / inline-body # может указать другую ветку
.github / КОДЕКСЫ
Gopkg.lock
Makefile
README.md
attack.go
внутренний / cmd / jsonschema / main.go
lib / metrics.go
lib / metrics_test.go
lib / target.schema.json
lib / targets.go
библиотека / target_test.go
>

Дополнение

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

Согласно man git-diff :

  git diff [<параметры>] <фиксация> ... <фиксация> [-] [<путь> ...]
Эта форма предназначена для просмотра изменений в ветке, содержащей и до
второй , начиная с общего предка обоих
<совершить>."git diff A ... B" эквивалентно "git diff $ (git
merge-base A B) B ". Вы можете опустить любой из , который имеет
тот же эффект, что и при использовании HEAD.

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

Для более полного списка способов написания  см. «УКАЗАНИЕ
REVISIONS "в gitrevisions (7). Однако" diff "касается
сравнение двух конечных точек, а не диапазонов, и обозначений диапазонов
("<фиксация>..  "и"  ...  ") не означают диапазон как
определены в разделе «УКАЗАНИЕ ДИАПАЗОНОВ» в gitrevisions (7).

Если глаза потускнели, важная часть:

  «git diff A ... B» эквивалентно «git diff $ (git merge-base A B) B».

Это выглядит подозрительно близко к тому, что я придумал 🤔
По крайней мере, я был на правильном пути…

  # явное: git diff --name-only master ... HEAD
> git diff --name-only master...
Gopkg.lock
Makefile
README.md
attack.go
внутренний / cmd / jsonschema / main.go
lib / metrics.go
lib / metrics_test.go
lib / target.schema.json
lib / targets.go
библиотека / target_test.go
>

Ага, выглядит хорошо!

Обсудить в Twitter

Твитнуть Следуйте @jpalardy

Руководство по Git для новичков — как написать хорошее сообщение о фиксации

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

Последнее обновление Время читать 3 мин.

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

Когда я начал писать год назад, я написал статью о том, как начать и создать свой первый репозиторий с помощью Git.

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

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

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

Хороший пример коммита

Ниже вы можете найти пример последних коммитов на GitHub для AngularJS, популярного фреймворка, разработанного инженерами Google. Как видите, сообщения ясны, и мы можем лучше понять, какая работа была проделана в разных частях.

Например, 24 июля 2019 года компания «gkalpak» обновила «SauceConnect» и перешла на последнюю версию Safari (веб-браузер). Git фиксирует историю репозитория Angular.js GitHub

Почему все не делают коммитов одинаково?

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

Не волнуйтесь; вы часто найдете похожие способы написания сообщения.

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

Я дам вам более подробную информацию об этих правилах позже в этой статье.

Почему важно хорошо писать коммит

Я составил краткий список преимуществ использования хорошего сообщения коммита.

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

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

  • Лучшее понимание: Вам необходимо создавать четкие и понятные сообщения; это поможет вам и вашему соавтору работать над проектом. Ниже вы можете найти пример истории коммитов git только с неясными сообщениями.Как видите, сложно понять, что сделано.

Плохой git коммитит пример Пример от Джейсона МакКрири

Примечание: Если вы хотите иметь больше примеров плохих коммитов и в то же время получать удовольствие, учетная запись Twitter с именем «gitlost» каждый день пишет в Твиттере смешные и неотфильтрованные коммиты. .

Пример автоматически сгенерированного журнала изменений Git

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

  • Всегда проверяйте свою грамматику. Сообщение, полное ошибок, никогда не бывает приятным. Для этого я рекомендую вам использовать инструмент грамматики. Если вы пишете на английском языке, вы можете использовать Grammarly, Reverso или GrammarCheck. Эти инструменты не идеальны, но они устранят большинство ваших ошибок.
  • Одна фиксация, одно изменение. Старайтесь совершать часто. В идеале каждое изменение должно выполняться в отдельном коммите.Вам будет легче вернуться к предыдущей работе.
  • Будьте ясны. Когда вы пишете коммит, старайтесь быть максимально прозрачным. Я рекомендую вам использовать простой английский, чтобы сразу перейти к делу.
  • Подробная информация о том, что вы сделали. Найдите время, чтобы перечитать свой код, чтобы написать то, что вы сделали. В случае, если вам нужно много подробностей, я рекомендую вам использовать часть описания коммита.

ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ: Я хочу поделиться с вами более подробной информацией о команде git commit.Если вы не используете программное обеспечение git, вы должны знать, что вы можете создать подробный коммит, набрав эту команду:

  $ git commit -m "Title" -m "Description"

Это то же самое, что и раньше, но с вторая часть для описания. Итак, «-m ‘title’» — это короткий заголовок коммита, а «-m ‘description’» — описание, если вам нужно предоставить более подробную информацию.

  • Используйте руководство git. Если вы хотите иметь четкую историю коммитов git, я рекомендую вам следовать руководству.Это руководство о том, как совершать коммит. В моем случае я выбрал этот простой от Udacity.

    No related posts.