git blame
Еще одну прикольную штуку для меня открыли - git blame. Натравите его на файл и он попытается для каждой строчки найти и связать коммит, который изменял эту строчку. Вооружившись грепом можно поискать уже более конкретно то что нужно. Например, кто и в каком коммите поменял значение какой-либо переменной?
#git
Еще одну прикольную штуку для меня открыли - git blame. Натравите его на файл и он попытается для каждой строчки найти и связать коммит, который изменял эту строчку. Вооружившись грепом можно поискать уже более конкретно то что нужно. Например, кто и в каком коммите поменял значение какой-либо переменной?
git blame ./group_vars/whatever_servers | grep whatever_variable
325ac9b0 (Username 2018-01-24 13:47:19 +0300 7) whatever_variable: "{{ whatever_variable | default(true) }}"
#git
git config
Немного полезного конфига гита для рабочих станций.
#git
Немного полезного конфига гита для рабочих станций.
[user]
name = Bykva Bykva
email = bykva@bykva.bykva
[color]
diff = auto
status = auto
branch = auto
ui = true
[alias]
st = status
ci = commit
co = checkout
br = branch
tree = log --graph --decorate --pretty=oneline --abbrev-commit
debrelease = "!\
test -f debian/changelog || exit 1; \
hash=\"$(md5sum debian/changelog)\"; \
debchange -r; \
newhash=\"$(md5sum debian/changelog)\"; \
[ \"$hash\" != \"$newhash\" ] || exit 1; \
version=\"$(head -1 debian/changelog |sed -e 's/) .*//' -e 's/.* (//')\"; \
tagname=\"$(head -1 debian/changelog |sed -e 's/) .*//' -e 's/.* (//' -e 's/~/_/g' -e 's/:/%/')\"; \
git ci -m \"prepare for release $version\" debian/changelog || exit 1; \
git tag -s -m \"release $version\" \"$tagname\" || exit 1; \
debchange -i ''; \
git ci -m 'bump version for future' debian/changelog"
[core]
quotepath = false
pager = less -F -X
[url "git://git.debian.org/d-i/"]
insteadOf = git+ssh://git.debian.org/git/d-i/
[push]
default = simple
[pull]
rebase = true
[gitflow "branch"]
develop = development
#git
Приятные новости от gitlab! Теперь для создания проекта можно просто пушить в несуществующий репозиторий и он создастся.
Подробнее: https://docs.gitlab.com/ee/gitlab-basics/create-project.html#push-to-create-a-new-project
и.. куча других нововведений: https://habrahabr.ru/post/350660/
#gitlab #git
$ git push --set-upstream ssh://git@gitlab.example.com:12345/group/project.git master
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (5/5), 1.12 KiB | 0 bytes/s, done.
Total 5 (delta 0), reused 0 (delta 0)
remote:
remote: The private project group/project was successfully created.
remote:
remote: To configure the remote, run:
remote: git remote add origin git@gitlab.example.com:group/project.git
remote:
remote: To view the project, visit:
remote: http://gitlab.example.com/group/project
remote:
To ssh://gitlab.example.com:12345/group/project.git
* [new branch] master -> master
Branch master set up to track remote branch master from ssh://git@gitlab.example.com:12345/group/project.git.
Подробнее: https://docs.gitlab.com/ee/gitlab-basics/create-project.html#push-to-create-a-new-project
и.. куча других нововведений: https://habrahabr.ru/post/350660/
#gitlab #git
обращение по DNS в kubernetes между namespace
Исходные данные:
service name = jenkins
namespace = jenkins
Тогда, например, для пуша в jenkins можно сформировать такой web-hook:
#kubernetes #jenkins #git
Исходные данные:
service name = jenkins
namespace = jenkins
Тогда, например, для пуша в jenkins можно сформировать такой web-hook:
http://<user>:<token>@jenkins.jenkins.svc.cluster.local:8080/job/my-super-job/build
#kubernetes #jenkins #git
Список тегов, используемых в канале:
—-------------------------------
Лекции и материалы
—-------------------------------
#Занятие
#Лекции
Лекция
#junior
—---------
Linux
—---------
#ssh
#bash
#bash_tips_and_tricks
#awk
#tmux
#console
#utils
#troubleshooting
#nmap
#apt
#bind
#sound
#power_management
—----------
DevOps
—----------
#jenkins
#ansible
#git
#kubernetes
#deploy
#ceph
#docker
#puppet
—------------------
Virtualization
—------------------
#vmware
vagrant
—------------------
Networking
—---------------—
#networking
#proxy
#socks
—---------
InfoSec
—---------
#vulns
#security
#ctf
—-------------
Windows
—-------------
#RDTS
#windows_server2012
#RDP
—------------
Datacenters
—---------—
#ovh
#hetzner
—-------
Other
—-------
#android
#jira
—------------------------------------------------
Ссылки и сторонние материалы
—------------------------------------------------
#read
#thirdparty
Updated: 29.05.18
—-------------------------------
Лекции и материалы
—-------------------------------
#Занятие
#Лекции
Лекция
#junior
—---------
Linux
—---------
#ssh
#bash
#bash_tips_and_tricks
#awk
#tmux
#console
#utils
#troubleshooting
#nmap
#apt
#bind
#sound
#power_management
—----------
DevOps
—----------
#jenkins
#ansible
#git
#kubernetes
#deploy
#ceph
#docker
#puppet
—------------------
Virtualization
—------------------
#vmware
vagrant
—------------------
Networking
—---------------—
#networking
#proxy
#socks
—---------
InfoSec
—---------
#vulns
#security
#ctf
—-------------
Windows
—-------------
#RDTS
#windows_server2012
#RDP
—------------
Datacenters
—---------—
#ovh
#hetzner
—-------
Other
—-------
#android
#jira
—------------------------------------------------
Ссылки и сторонние материалы
—------------------------------------------------
#read
#thirdparty
Updated: 29.05.18
git undoing operations
Хорошая статья, которая показывает как правильно и красиво поступить в ситуации, когда нужно что-то откатить\удалить в ветке коммитов.
https://sethrobertson.github.io/GitFixUm/fixup.html
#git #troubleshooting
Хорошая статья, которая показывает как правильно и красиво поступить в ситуации, когда нужно что-то откатить\удалить в ветке коммитов.
https://sethrobertson.github.io/GitFixUm/fixup.html
#git #troubleshooting
Git commit messages
Как правильно комиттить в гит. Хорошая статья с хабра:
https://habr.com/post/416887/
#thirdparty #read #git
Как правильно комиттить в гит. Хорошая статья с хабра:
https://habr.com/post/416887/
#thirdparty #read #git
Хабр
Как следует писать комментарии к коммитам
Предисловие от переводчика На протяжении многих лет разработки ПО, будучи участником многих команд, работая с разными хорошими и опытными людьми, я часто наблю...
progit_v2.1.3.epub
5.7 MB
Книга про гит на русском. Это для тех людей, кто вдруг ее еще не видел. Или вдруг еще даже не пользовался никогда гитом. Самое время начать!
#git
#git
GIT отделить ветку в отдельный репозиторий
вариант 1:
вариант 2:
#git
вариант 1:
git push url://to/new/repository.git branch-to-move:new-branch-name
вариант 2:
git clone -b newbranch CurrentRepo NewRepo
#git
мини-заметка без заголовка
^^^ это не заголовок
(типа пошутил, да)
шобы хранить файлы libreoffice в гите, так чтобы гит не считал их как бинарники (и соответственно на изменение каждой запятой не создавал его клон), можно сменить формат на Flat XML, например fodt, fods.
#git
^^^ это не заголовок
(типа пошутил, да)
шобы хранить файлы libreoffice в гите, так чтобы гит не считал их как бинарники (и соответственно на изменение каждой запятой не создавал его клон), можно сменить формат на Flat XML, например fodt, fods.
#git
заставляем git использовать указанный ssh ключ при деплое чужого контейнера в k8s
Решал задачу по внедрению поисковика по коду: https://github.com/etsy/hound.
В рамках этой задачи было принято решение написать helm пакет для уже готового docker на docker hub. Сам helm можно потыкать здесь: https://github.com/bykvaadm/hound-helm-chart
Отдельно в этой заметке хотел бы отметить небольшую проблему, решаемую в рамках задачи: научить hound ходить в приватные репозитории по указанному приватному ключу. При этом не хотелось ни модифицировать контейнер автора, ни делать persistent volume, ни какой либо init-контейнер.
Способов заставить git ходить с указанным ключом довольно много, но большинство из них подразумевает что вы правите какой-то конфиг или модифицируете строку запуска git. Ни того ни другого делать в чужом контенере не хотелось. В итоге как один из наиболее простых способов был взят вариант с использованием wrapper. wrapper - это скрипт, который будет вызван git'ом при запуске ssh, вместо запуска ssh. Таким образом внутри wrapper можно писать любую логику, подставляя в зависимости от ситуации нужные параметры. на выходо wrapper должен заменять собой вызов ssh с какими-то параметрами. В моем случае так сложно делать не надо и wrapper скрипт получился такой:
Здесь я указываю чтобы не чекался fingerprint и путь к конкретному ключу. В итоге для helm пишется configmap и secret. один кладет wrapper, а другой - приватный ключ.
Теперь все что остается - задать в deployment переменную окружения GIT_SSH, в которой указать путь к wrapper.
#git #helm #kubernetes
Решал задачу по внедрению поисковика по коду: https://github.com/etsy/hound.
Hound is an extremely fast source code search engine. The core is based on this article (and code) from Russ Cox: Regular Expression Matching with a Trigram Index.
В рамках этой задачи было принято решение написать helm пакет для уже готового docker на docker hub. Сам helm можно потыкать здесь: https://github.com/bykvaadm/hound-helm-chart
Отдельно в этой заметке хотел бы отметить небольшую проблему, решаемую в рамках задачи: научить hound ходить в приватные репозитории по указанному приватному ключу. При этом не хотелось ни модифицировать контейнер автора, ни делать persistent volume, ни какой либо init-контейнер.
Способов заставить git ходить с указанным ключом довольно много, но большинство из них подразумевает что вы правите какой-то конфиг или модифицируете строку запуска git. Ни того ни другого делать в чужом контенере не хотелось. В итоге как один из наиболее простых способов был взят вариант с использованием wrapper. wrapper - это скрипт, который будет вызван git'ом при запуске ssh, вместо запуска ssh. Таким образом внутри wrapper можно писать любую логику, подставляя в зависимости от ситуации нужные параметры. на выходо wrapper должен заменять собой вызов ssh с какими-то параметрами. В моем случае так сложно делать не надо и wrapper скрипт получился такой:
#!/bin/sh
ssh -o StrictHostKeyChecking=no -i /etc/ssh-key/id_rsa $@
Здесь я указываю чтобы не чекался fingerprint и путь к конкретному ключу. В итоге для helm пишется configmap и secret. один кладет wrapper, а другой - приватный ключ.
Теперь все что остается - задать в deployment переменную окружения GIT_SSH, в которой указать путь к wrapper.
#git #helm #kubernetes
Поиск по git
Поиск коммитов, связанных с файлом (даже если удален)
Поиск коммитов, фильтруя по тексту коммита
#git
Поиск коммитов, связанных с файлом (даже если удален)
git log --all -- somefile
Поиск коммитов, фильтруя по тексту коммита
git log -g --grep=STRING
#git
git revert multiply commits
Дано:
Хотим:
Решение:
еще это можно решить так:
#git
Дано:
A <-- B <-- C <-- D <-- master <-- HEAD
Хотим:
A <-- B <-- C <-- D <-- [(CD)^-1] <-- master <-- HEAD
Решение:
$ git revert --no-commit D
$ git revert --no-commit C
$ git commit -m "the commit message"
еще это можно решить так:
$ git checkout -f B -- .
$ git commit -a
#git
Untrack files already added to git repository based on .gitignore
1)
#git
1)
git rm -r --cached .
2) git add .
3) git commit -m ".gitignore fix"
#git
git stage only one line
Поковырял вчера доки, в итоге оказалось что стейжить одну строчку можно, но есть нюансы. о чем идет речь? например у вас есть файл, в котором условно вы работаете и в какой-то момент, не важно зачем хотите сделать коммит, но поместить туда не все наработки а только часть их. Раньше я прекрасно с этим справлялся, используя
UPD говорят что еще довольно удобно такие операции делать в
#git
Поковырял вчера доки, в итоге оказалось что стейжить одну строчку можно, но есть нюансы. о чем идет речь? например у вас есть файл, в котором условно вы работаете и в какой-то момент, не важно зачем хотите сделать коммит, но поместить туда не все наработки а только часть их. Раньше я прекрасно с этим справлялся, используя
git add -p
и работал с hunk'ами, которые для меня разбивал гит. хочешь добавить в коммит кусок? жми y, не хочешь - жми n. Все было хорошо, пока изменения которые я хочу добавить и которые не хочу не попали в один hunk. В таком случае можно попросить git выполнить разбиение этого hunk на несколько, с помощью команды s (split). И тут появляется нюанс - изменяемые строки не должны быть соседними. Во всем остальном разбиение произойдет без проблем.UPD говорят что еще довольно удобно такие операции делать в
tig
. Сам не проверял, за вопросами по работе tig приходите в чят#git
git reset modifications only in one file
Полный откат изменений -
UPD доп инфо для прочтения: https://stackoverflow.com/questions/6561142/difference-between-git-checkout-filename-and-git-checkout-filename/6561160#6561160
#git
Полный откат изменений -
git reset --hard
, но когда нужно только один файл откатить - подойдет такая команда:git checkout -- path_to_file/file_name
UPD доп инфо для прочтения: https://stackoverflow.com/questions/6561142/difference-between-git-checkout-filename-and-git-checkout-filename/6561160#6561160
#git
Forwarded from Maxim Terehov
Еще одна полезная особенность cherry-pick
Если master сильно отличается от stage ветки, ввиду каких-либо обновлений продукта на бою по воле заказчиков, а разработка требует изменять файлы сначала в stage для получения одобрения заказчика. То можно использовать cherry-pick, выдергивая только те коммиты, которые уже вылили на stage и были протестированы заказчиком. Часто касается проектов на поддержке. Когда нет времени актуализировать хосты разработчиков.
Последовательность действий в таких случаях следующая:
Вот и всё, нужный нам коммит перенесен в master и находится в верхней точке ветки. Таким образом можно переносить и несколько коммитов по надобности, последовательно выполняя cherry-pick от раннего к позднему коммиту.
#git
Если master сильно отличается от stage ветки, ввиду каких-либо обновлений продукта на бою по воле заказчиков, а разработка требует изменять файлы сначала в stage для получения одобрения заказчика. То можно использовать cherry-pick, выдергивая только те коммиты, которые уже вылили на stage и были протестированы заказчиком. Часто касается проектов на поддержке. Когда нет времени актуализировать хосты разработчиков.
Последовательность действий в таких случаях следующая:
git checkout stageВносите необходимые изменения по задаче которая у вас стоит
git checkout -b task_1_stage
git commit -m"#1 example changes for task 1"После одобрения заказчиком на стейдже
git checkout stage
git merge task_1_stage
git checkout master* - ID: идентификатор коммита в ветке task_1_stage
git checkout -b task_1_master
git cherry-pick ID*
git checkout master
git merge task_1_master
Вот и всё, нужный нам коммит перенесен в master и находится в верхней точке ветки. Таким образом можно переносить и несколько коммитов по надобности, последовательно выполняя cherry-pick от раннего к позднему коммиту.
#git