Category Archives: Version control
Gitlab-ci: build go app with docker as a docker image
Preparations [TO BE UPDATED LATER] My gitlab-ci.yml variables: PACKAGE_PATH: /go/src/gitlab.com/[username_for_gitlab]/[project_name] # https://docs.gitlab.com/ee/ci/docker/using_docker_build.html CONTAINER_TEST_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG CONTAINER_RELEASE_IMAGE: $CI_REGISTRY_IMAGE:latest stages: — dep — test — build # A hack to make Golang-in-Gitlab happy .anchors: — &inject-gopath mkdir -p $(dirname ${PACKAGE_PATH}) && ln -s ${CI_PROJECT_DIR} ${PACKAGE_PATH} && cd ${PACKAGE_PATH} dep: stage: dep image: golang:1.13.1-alpine before_script: — *inject-gopath script: go …
Count lines in git repository
git ls-files | xargs wc -l https://stackoverflow.com/questions/4822471/count-number-of-lines-in-a-git-repository
Как смигрировать репозиторий в новый remote
git.migrate:
Поиск в git по изменённому контенту
git log -S Например — git log -SaddedVariableName
Git-subtree для деплоя сайта на github-pages
Возьмём для примера проект https://github.com/bullgare/lzd_cllinics. Сборка для деплоя расположена в директории deploy/, и эта директория находится под контролем версий. Чтобы статический сайт был доступен по адресу http://bullgare.github.io/lzd_cllinics/, нужно содержимое этой директории запушить в отдельную ветку gh-pages. Проще всего сделать это так: git subtree push —prefix deploy origin gh-pages Эта команда сделает push закоммиченной директории deployв …
Git: несколько разных ключей для одного хоста на примере bitbucket.org
Всё очень просто, достаточно прописать в ssh-конфиге алиасы: Host work-bitbucket.org HostName bitbucket.org IdentityFile ~/.ssh/workid Host personal-bitbucket.org HostName bitbucket.org IdentityFile ~/.ssh/personalid И затем поправить путь к репозиторию гита: git remote set-url origin git@work-bitbucket.org:repo_name.git https://confluence.atlassian.com/bitbucket/configure-multiple-ssh-identities-for-gitbash-mac-osx-linux-271943168.html
Настройка гита для пулла из одного репозитория и пуша в другой
Можно настроить два разных remote, как описано здесь — https://blog.bullgare.com/2014/11/gitlab-flow/. Но если нужно исключительно делать fetch из одного репозитория, а push — только во второй, то лучше сделать так: # fetch repo git remote set-url origin git@bitbucket.org:repo1.git # push repo git remote set-url origin —push git@bitbucket.org:repo1.git Посмотреть текущие параметры репозиториев можно так: git remote -v …
Github Flow
По сравнению с git flow всё проще. Создаётся fork, разработка фичи ведётся в отдельной ветке. Потом создаётся pull request (merge request для gitlab), опционально назначаются ответственные за merge, в процессе обсуждений может продолжаться работа в ветке (изменения будут автоматически добавлены к request). После одобрения ветка мёржится в мастер/главную ветку https://guides.github.com/introduction/flow/index.html
Github: подготовка к pull-request
https://help.github.com/articles/fork-a-repo — как создать fork. Тут всё просто — в дополнение к очевидным вещам нужно добавить ещё один источник: git remote add upstream https://github.com/octocat/….. https://help.github.com/articles/syncing-a-fork — как продолжать обновлять из оригинального репозитория. Тут всё тоже не очень сложно: git fetch upstream git checkout master git merge upstream/master Если ветка уже создана, то git checkout <ветка> …
Git reset
Все виды команды `git reset`. Удалить всё лишнее, включая незакоммиченные изменения # Clear working directory tree from all changes $ git checkout -f HEAD Откатить последний коммит и вернуть файлы в незакоммченное состояние (т.е. изменения станут незакоммиченными, но готовыми для коммита) # Reset the latest commit, and leave the changes in …