особенности работы с гит (в качестве напоминалки)
# сконфигурировать гит чтобы он пушил только туда где находится:
git config --global push.default simple
чтобы удобно работать с пул-реквестами делаем форк репозитория через интерфейс битбакета.
сделали в bitbucket форк репо, который будет центральным, а до этого текущий каталог указывал на то, что стало центральным (upstream).
переименовываем в апстрим текущую запись:
$ git remote rename origin upstream
добавляем указатель origin на личный клон центрального репо:
$ git remote add origin git@bitbucket.org:lup_/che-xxx.git
переключаем upstream с текущего remote (upstream) на личный remote (origin):
$ git push -u origin master
на случай если за время клонирования что-то изменилось делаем синхронизацию с личным репозиторием:
$ git pull origin master
Синхронизация с upstream (локальные изменения сохраняются)
$ git pull --rebase upstream
$ git push --force origin
Почистить удаленные ветки
В локальном репозитории:
$ git remote prune upstream
В удаленном репозитории:
git checkout master && git branch -r --merged | grep -v master | grep -v release | sed -e 's/origin\//:/' | xargs git push origin
Отключить push в upstream
Можно поставить неверный url для push:
$ git remote set-url --push upstream no_push
При попытке выполнить комманду push git не сможет это сделать из-за неверного url.
Сбросить все локальные изменения:
git reset --hard - сбросить все изменения, но оставив коммиты
git reset --hard @{u} - сбросить до точки с которой делался последний pull все изменения удалив незапушенные коммиты и локальные изменения (@{u} - сокращение от последнего коммита на remote)
######### замещаем удаленный master на origin пустой веткой (кроме битбакета)
git push origin :master
# на битбакете такая команда не пройдет, хотя она верная:
$ git push origin :master
remote: error: refusing to delete the current branch: refs/heads/master
To https://someuser@bitbucket.org/olli_che/che-all-ci.git
! [remote rejected] master (deletion of the current branch prohibited)
error: failed to push some refs to 'https://some_user@bitbucket.org/olli_che/che-all-ci.git'
$ git push origin :master
######### полная замена origin/master на upstream/master
Если есть два remote - upstream и origin, то положить в origin/master то что в upstream/master можно так:
$ git checkout -b upstream-master upstream/master
Branch upstream-master set up to track remote branch master from upstream.
Switched to a new branch 'upstream-master'
$ git push --force origin upstream-master:master
# переходим в локальный мастер чтобы можно было грохнуть промежуточную ветку в которой мы были
$ git checkout master
# удаляем upstream-master - промежуточная ненужная
$ git branch -d upstream-master
# создаем локальную ветку origin-master состоящую из origin/master
$ git checkout -b origin-master origin/master
# переходим в неё
$ git checkout origin-master
# грохаем локальный master со всеми локальными изменениями
$ git branch -d master
error: The branch 'master' is not fully merged.
If you are sure you want to delete it, run 'git branch -D master'.
$ git branch -D master
Deleted branch master (was 0090b24).
$
# переименовываем её в master
$ git branch -m origin-master master
# теперь состояние должно соответсвовать origin/master:
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Untracked files:
(use "git add ..." to include in what will be committed)
che-devops/buffer/
che-static/npm-debug.log.385926107eb49862879c899a86de3309
nothing added to commit but untracked files present (use "git add" to track)
$
# cоответсвенно git pull должен отдавать "up to date":
git pull
Already up-to-date.
$
#########
для удаления unnamed commit'ов (тех что не принадлежат ни одной ветке) есть команда 'git gc' (но она работает только локально, так что если такие коммиты образовались в remote - опять приедут и её надо запускать на remote).
### сделать пул-реквест из одного коммита, есть две удаленные точки - upstream куда пул-реквест и origin - мой клон в котором есть ещё коммиты которые не должны пока попасть в upstream
$ git log | less - копируем оттуда sha id коммита который нужно впилить.
#создаем ветку которая копия мастера
$ git branch upstream-master upstream/master
#переходим в неё
$ git checkout upstream-master
# выкачиваем из remote всё что туда успели влить
$ git pull
# cоздаем из полученного отдельную ветку в которой будет наш коммит
$ git branch fix-for-ci-config
#переходим в неё
$ git checkout fix-for-ci-config
# впиливаем наш коммит
$ git cherry-pick e6e022715321ae606389752b11877107ba9bf654
[fix-for-ci-config 301bf4f] fix for host/passwd for CI environment for mysql (does anyone use it? no errors on build.)
Date: Tue Apr 5 14:09:51 2016 +0300
1 file changed, 2 insertions(+), 2 deletions(-)
$
# можно убедиться что это именно то, что нужно по тексту изменений:
$ git diff HEAD^
# кладем ветку с нашим коммитом в origin, при этом битбакет сразу показывает по какому url сходить чтобы сделать пул-реквест с ней:
$ git push origin fix-for-ci-config
Counting objects: 192, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (61/61), done.
Writing objects: 100% (192/192), 30.15 KiB | 0 bytes/s, done.
Total 192 (delta 140), reused 176 (delta 125)
remote:
remote: Create pull request for fix-for-ci-config:
remote: https://bitbucket.org/my-bitbucket-user-name/my-repo-named-origin/pull-requests/new?source=fix-for-ci-config&t=1
remote:
To https://my-bitbucket-user-name@bitbucket.org/my-bitbucket-user-name/my-repo-named-origin.git
* [new branch] fix-for-ci-config -> fix-for-ci-config
$
Пул реквесты создаются непосредственно из морды к репозиторию и к гит непосредственного отношения не имеют - это функция апи репозитоия, а не гит-команда.
git config --global push.default simple
чтобы удобно работать с пул-реквестами делаем форк репозитория через интерфейс битбакета.
сделали в bitbucket форк репо, который будет центральным, а до этого текущий каталог указывал на то, что стало центральным (upstream).
переименовываем в апстрим текущую запись:
$ git remote rename origin upstream
добавляем указатель origin на личный клон центрального репо:
$ git remote add origin git@bitbucket.org:lup_/che-xxx.git
переключаем upstream с текущего remote (upstream) на личный remote (origin):
$ git push -u origin master
на случай если за время клонирования что-то изменилось делаем синхронизацию с личным репозиторием:
$ git pull origin master
Синхронизация с upstream (локальные изменения сохраняются)
$ git pull --rebase upstream
$ git push --force origin
Почистить удаленные ветки
В локальном репозитории:
$ git remote prune upstream
В удаленном репозитории:
git checkout master && git branch -r --merged | grep -v master | grep -v release | sed -e 's/origin\//:/' | xargs git push origin
Отключить push в upstream
Можно поставить неверный url для push:
$ git remote set-url --push upstream no_push
При попытке выполнить комманду push git не сможет это сделать из-за неверного url.
Сбросить все локальные изменения:
git reset --hard - сбросить все изменения, но оставив коммиты
git reset --hard @{u} - сбросить до точки с которой делался последний pull все изменения удалив незапушенные коммиты и локальные изменения (@{u} - сокращение от последнего коммита на remote)
######### замещаем удаленный master на origin пустой веткой (кроме битбакета)
git push origin :master
# на битбакете такая команда не пройдет, хотя она верная:
$ git push origin :master
remote: error: refusing to delete the current branch: refs/heads/master
To https://someuser@bitbucket.org/olli_che/che-all-ci.git
! [remote rejected] master (deletion of the current branch prohibited)
error: failed to push some refs to 'https://some_user@bitbucket.org/olli_che/che-all-ci.git'
$ git push origin :master
######### полная замена origin/master на upstream/master
Если есть два remote - upstream и origin, то положить в origin/master то что в upstream/master можно так:
$ git checkout -b upstream-master upstream/master
Branch upstream-master set up to track remote branch master from upstream.
Switched to a new branch 'upstream-master'
$ git push --force origin upstream-master:master
# переходим в локальный мастер чтобы можно было грохнуть промежуточную ветку в которой мы были
$ git checkout master
# удаляем upstream-master - промежуточная ненужная
$ git branch -d upstream-master
# создаем локальную ветку origin-master состоящую из origin/master
$ git checkout -b origin-master origin/master
# переходим в неё
$ git checkout origin-master
# грохаем локальный master со всеми локальными изменениями
$ git branch -d master
error: The branch 'master' is not fully merged.
If you are sure you want to delete it, run 'git branch -D master'.
$ git branch -D master
Deleted branch master (was 0090b24).
$
# переименовываем её в master
$ git branch -m origin-master master
# теперь состояние должно соответсвовать origin/master:
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Untracked files:
(use "git add ..." to include in what will be committed)
che-devops/buffer/
che-static/npm-debug.log.385926107eb49862879c899a86de3309
nothing added to commit but untracked files present (use "git add" to track)
$
# cоответсвенно git pull должен отдавать "up to date":
git pull
Already up-to-date.
$
#########
для удаления unnamed commit'ов (тех что не принадлежат ни одной ветке) есть команда 'git gc' (но она работает только локально, так что если такие коммиты образовались в remote - опять приедут и её надо запускать на remote).
### сделать пул-реквест из одного коммита, есть две удаленные точки - upstream куда пул-реквест и origin - мой клон в котором есть ещё коммиты которые не должны пока попасть в upstream
$ git log | less - копируем оттуда sha id коммита который нужно впилить.
#создаем ветку которая копия мастера
$ git branch upstream-master upstream/master
#переходим в неё
$ git checkout upstream-master
# выкачиваем из remote всё что туда успели влить
$ git pull
# cоздаем из полученного отдельную ветку в которой будет наш коммит
$ git branch fix-for-ci-config
#переходим в неё
$ git checkout fix-for-ci-config
# впиливаем наш коммит
$ git cherry-pick e6e022715321ae606389752b11877107ba9bf654
[fix-for-ci-config 301bf4f] fix for host/passwd for CI environment for mysql (does anyone use it? no errors on build.)
Date: Tue Apr 5 14:09:51 2016 +0300
1 file changed, 2 insertions(+), 2 deletions(-)
$
# можно убедиться что это именно то, что нужно по тексту изменений:
$ git diff HEAD^
# кладем ветку с нашим коммитом в origin, при этом битбакет сразу показывает по какому url сходить чтобы сделать пул-реквест с ней:
$ git push origin fix-for-ci-config
Counting objects: 192, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (61/61), done.
Writing objects: 100% (192/192), 30.15 KiB | 0 bytes/s, done.
Total 192 (delta 140), reused 176 (delta 125)
remote:
remote: Create pull request for fix-for-ci-config:
remote: https://bitbucket.org/my-bitbucket-user-name/my-repo-named-origin/pull-requests/new?source=fix-for-ci-config&t=1
remote:
To https://my-bitbucket-user-name@bitbucket.org/my-bitbucket-user-name/my-repo-named-origin.git
* [new branch] fix-for-ci-config -> fix-for-ci-config
$
Пул реквесты создаются непосредственно из морды к репозиторию и к гит непосредственного отношения не имеют - это функция апи репозитоия, а не гит-команда.