Разработка, HowTo

Git: откат мержа, который не был запушен

Иногда мы делаем мерж некоторой ветки в master и случается такое, что нам нужно по какой либо причине откатить ветку (мы не делали push еще в удаленный репозитарий), либо просто пытаемся сделать git pull забыв, что есть непрокоммиченые изменения.

При git pull мы увидим следующую картину

Git Pull Failed
You have not concluded your merge (MERGE_HEAD exists). Please, commit your changes before you can merge.

И чтобы откатить наш неудачный мерж не нужно делать никаких reset —hard HEAD=1.

Достаточно сделать

git reset --hard ORIG_HEAD

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

Реклама
Разработка, HowTo, linux

Обновление нескольких git-репозитариев в папке

2016-03-08-22:48:31_580x134 Порой у нас в каталоге накапливается много-много git-репозитариев, которые хочется обновить в один заход. Для этого есть маленький скрипт, который обновляет все репозитарии, которые сможет найти в папке, переданной в качестве аргумента.

#!/bin/bash

if test "$#" -ne 1; then
    echo "usage: $0 <dirname>"
		echo "Find and update all git repos in specified folder"
    exit 1
fi

if [ -d $1 ]; then
	find $1 -type d -name .git | xargs -n 1 dirname | sort | while read line; do echo "Update repo $line" && pushd `pwd` > /dev/null && cd $line && git pull && popd > /dev/null; done
else
	echo "\"$1\" does not exists"
fi

Использование очень простое

$ gitup ~/projects

Репозитарий на github.

HowTo

GitLab: обновление бандлов ruby

gitlab bundle updateПосле очередного «незапланированного» обновления у меня вдруг отвалился gitlab.
В логах

/home/git/gitlab/vendor/bundle/ruby/2.1.0/gems/activesupport-4.1.9/lib/active_su
pport/dependencies.rb:247:in `require': Incorrect MySQL client library version! 
This gem was compiled for 5.5.42 but the client library is 5.6.25. (RuntimeError
)

Надо обновлять.
Беда в том, что в ruby я не нашел аналога pip update или что-то в таком духе.

Для обновления предустановленных бандлов нужно удалить старые и поставить новые (заново).

$ sudo -u git mv /home/git/gitlab/vendor/bundle{,.bkp}
sudo -u git -H bundle install --without development test postgres --deployment

Мануал по обновлению гитлаба: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/update/patch_versions.md.

Найдено в сети

Полезные ссылки

Алгоритмы

Python

PHP

  • Парсинг PHP в Go — основа для построения статических анализаторов и других удобных инструментов

JavaScript

Linux

Git

Софт

Arduino/Raspberry Pi и другое железо

Всякое

Разработка

Git: выделяем глобальный репозитарий для проекта

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

$ git push origin master
Counting objects: 30, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (16/16), done.
Writing objects: 100% (17/17), 3.31 KiB | 0 bytes/s, done.
Total 17 (delta 4), reused 0 (delta 0)
remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: error: is denied, because it will make the index and work tree inconsistent
remote: error: with what you pushed, and will require 'git reset --hard' to match
remote: error: the work tree to HEAD.
remote: error: 
remote: error: You can set 'receive.denyCurrentBranch' configuration variable to
remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into
remote: error: its current branch; however, this is not recommended unless you
remote: error: arranged to update its work tree to match what you pushed in some
remote: error: other way.
remote: error: 
remote: error: To squelch this message and still keep the default behaviour, set
remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
To /project/path
 ! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to '/project/path'

Вообще почему она возникает-то? Разве гит это не распределенная система контроля версий? Распределенная и даже чутка децентрализованная. Совсем-совсем распределенная. А это значит, что пушить изменения можно не только на одно хранилище, а вообще в любой репозитарий. Хоть чуваку за соседний комп. Таким образом разработчикии могут делиться своими наработками.

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

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

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

Способ первый. Мы заходим в репозитарий и просто чекаутим другую ветку проекта. Профит. 🙂

Способ второй. Мы узнаем, что существует два типа хранилищ: bare и non bare. Дефолтно при выполнении git init будет создано хранилище второго типа (и при чекауте чужого репощитария так же создается локальный non-bare репозитарий).

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

Гитхаб предоставляет хранилища именно такого типа.

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

А что делать?

Если реп у нас удаленный и для совместной работы — конвертируем его в bare

git config --bool core.bare true

Если нет — смотрим выше.

А еще можно сказать иниту, чтобы создавал bare сразу.

git init --bare