Архив рубрики: git

Отмена последнего коммита в git

link

Допустим, вы сделали commit в git, но поняли, что он недостаточно хорош. В таком случае можно продолжить правки, а при следующем коммите набрать

    git commit -a --amend

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

Если вы сделали commit в git, но поняли, что он достаточно плох, то можно сделать и так:

    git reset --soft HEAD\^

or

    git reset --soft HEAD^

Эта команда отменит последний коммит (но не изменения, которые вы внесли, они сохранятся).

Если последний коммит отвратителен, то можно вообще его удалить:

    git reset --hard HEAD^

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

    git revert commit-sha1

Ну, а потом опубликовать поскорее его командой git push.

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

Хорошие материалы по git можно посмотреть здесь:

MANY git remote 

$ git remote set-url origin git@github.com:ppreyer/first_app.git

Long version:

As the error message indicates, there is already a remote configured with the same name. So you can either add the new remote with a different name or update the existing one if you don’t need it:

To add a new remote, called for example github instead of origin (which obviously already exists in your system), do the following:

$ git remote add github git@github.com:ppreyer/first_app.git

Remember though, everywhere in the tutorial you see «origin» you should replace it with «github». For example $ git push origin master should now be $ git push github master.

However, if you want to see what that origin which already exists is, you can do a $ git remote -v. If you think this is there by some error, you can update it like so:

$ git remote set-url origin git@github.com:ppreyer/first_app.git

git commands

link

Шпаргалка по git. Пошаговое руководство: как выполнить слияние веток в git, как создать новую ветку и репозиторий, как выписать ветку с github и т.п. Инструкции по git для начинающих.

Git – это распределенная система контроля версий. Это главное отличие git от svn. Каждый разработчик создает на своем компьютере отдельный, полноценный репозиторий.

В рамках этого репозитория можно делать все тоже самое, что и обычно в svn – создавать ветки, просматривать изменения, выполнять коммиты. Для того, чтобы можно было работать с удаленными репозиториями и обмениваться изменениями с другими разработчиками, в git есть две команды, не имеющие аналогов в svn – git push и git pull.

git push – вливание локальных изменений в удаленный репозиторий. git pull – вливание изменений из удаленного репозитория в локальный. Обмен данными обычно происходит с использованием протокола SSH.

Git поддерживают несколько крупных репозиториев – GitHub, SourceForge, BitBucket и Google Code. Удобно использовать один из них в качестве основного хранилища для корпоративных проектов.

Как выписать репозиторий с github

  1. Создаем новую директорию для проекта project_name, переходим в нее.
  2. Выполняем команду:

    “./” означает, что создать репозиторий нужно в текущей директории.

Результат: каталог с выписанной веткой master. Теперь можно создавать новые ветки, или выписывать с github существующие.

Как выписать ветку с github

С помощью команды “checkout” можно выписать уже существующую ветку с github:

Или так, что намного надежнее:

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

Т.е. сначала мы создаем новую ветку, а затем вливаем в нее изменения из ветки на github.

Как создать новую ветку в локальном репозитории

  1. Создаем новую ветку в локальном репозитории:
  2. Публикуем ее на github:

Как переключиться на другую ветку в git

 

Если вы случайно удалили какой-то файл, можно извлечь его из хранилища:

Как посмотреть список веток

Команда “branch” позволяет посмотреть список веток в локальном репозитории. Текущая ветка будет помечена звездочкой:

Как сделать commit

Создаем новую ветку, выполняем в ней нужные изменения.

  1. Список всех измененных и добавленных файлов можно просмотреть командой:
  2. Подготавливаем коммит, добавляя в него файлы командой:

    Или удаляем устаревшие файлы:

  3. Выполняем коммит:
  4. Как правило, в репозитории существует две основные ветки – dev и master. Dev – общая ветка разработчиков и тестировщиков. Именно в нее добавляются все новые разработки перед очередным релизом. Master – ветка для выкладки продукта на боевые сервера.После коммита надо влить в нашу ветку изменения из ветки dev и master:

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

  5. Переключаемся на ветку dev:
  6. Вливаем в dev изменения из ветки проекта:
  7. Заливаем последнюю версию ветки dev на удаленный сервер:

    push может не пройти, потому что удалённый origin/dev обогнал локальную его копию.

Как решить конфликт бинарных файлов

Допустим, при слиянии с другой веткой git выдал ошибку. Команда git status возвращает информацию о конфликте:

Конфликтный файл является бинарным (это могут быть архивные файлы, изображения и т.п.), и решение конфликта стандартным способом, с помощью редактирования – не возможно.

Чтобы решить такой конфликт, надо просто выбрать – какая версия файла будет использоваться: ваша или из вливаемой ветки. Чтобы использовать свой вариант файла, вводим команду:

Если мы выбираем версию из вливаемой ветки:

“ours” – от английского “наш”, “theirs” – от английского “их”.

Как посмотреть историю изменений

git log – просмотр логов.

Вывод данных о каждом коммите в одну строку:

Для вывода информации git log использует просмотрщик, указанный в конфиге репозитория.

Поиск по ключевому слову в комментариях к коммиту:

Команда “git show” позволяет просмотреть, какие именно изменения произошли в указанном коммите:

Можно посмотреть построчную информацию о последнем коммите, имя автора и хэш коммита:

git annotate, выводит измененные строки и информацию о коммитах, где это произошло:

Как сделать откат

  1. git log – просмотр логов, показывает дельту (разницу/diff), привнесенную каждым коммитом.
  2. Копируем идентификатор коммита, до которого происходит откат.
  3. Откатываемся до последнего успешного коммита (указываем последний коммит):

    Можно откатить до последней версии ветки:

После того, как откат сделан, и выполнен очередной локальный коммит, при попытке сделать push в удаленный репозиторий, git может начать ругаться, что версия вашей ветки младше чем на github и вам надо сделать pull. Это лечится принудительным коммитом:

Как выполнить слияние с другой веткой

git merge выполняет слияние текущей и указанной ветки. Изменения добавляются в текущую ветку.

git pull забирает изменения из ветки на удаленном сервере и проводит слияние с активной веткой.

git pull отличается от git merge тем, что merge только выполняет слияние веток, а pull прежде чем выполнить слияние – закачивает изменения с удаленного сервера. mergeудобно использовать для слияния веток в локальном репозитории, pull – слияния веток, когда одна из них лежит на github.

Создание нового локального репозитория

git cherry-pick

git cherry-pick помогает применить один-единственный коммит из одной ветки к дереву другой.

  1. Для этого нужно выписать ветку, в которую будем вливать коммит:
  2. Обновить ее:
  3. Выполнить команду, указать код коммита:
  4. После этого обновить ветку на сервере:

Как раскрасить команды git

После создания репозитория в текущей директории появится субдиректория .git . Она содержит файл config .

Чтобы раскрасить вывод git, можно добавить в файл блок [color]:

Полезные ссылки по теме git

Основы работы с Git

Моя шпаргалка по работе с Git

Pro Git book, written by Scott Chacon. Русский перевод

sh auto fetsh and pull 

sh fetch.sh

fetch.sh:

#!/bin/bash 
echo 
echo "*************************************"
echo "*                      stencilapp                                   *"
echo "*************************************"
cd e:/ops/yd/sites/stencilapp
git stash -a
git clean -xfd
rm -rf .git/FETCH_HEAD
git pull

git in github 

echo # custom_joomla >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin git@github.com:shilovk/custom_joomla.git
git push -u origin master

…or push an existing repository from the command line

git remote add origin git@github.com:shilovk/custom_joomla.git
git push -u origin master

main git directory

mkdir /git
mkdir /git/project
cd /git/project
git —bare init
#chown -R deploy /git/project
cd /var/www/project
git remote add origin \
deploy@server:/git/project
git push origin master

/var/www/project/.git/config:

[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = /git/project/
[branch "master"]
remote = origin
merge = refs/heads/master

Работа с git. Создание и удаление веток

1) Посмотреть все ветки

  • git branch
  • git branch -r

2) Удалить ветку на сервере

  • git push origin :crincum_poi

3) Удалить ветку локально

  • git branch -D crincum_poi

4) Создать ветку на сервере

  • git push origin master:crincum_poi

5)  Смерджить ветку таска MAP-23 в текущую ветку проекта crincum

  • git checkout master
  • git merge experimental

6) Процесс создания веток под таск

  • git checkout -b MAP-186  — создаем локальную ветку
  • git branch — проверяем, что переключились на текущую ветку
  • git push origin MAP-186:MAP-186 — пушим origin в новую удаленную ветку. Тем самым создаем ее.
  • Проверяем наличие удаленной ветки git branch -r и Работаем:)

7) Ошибка refusing to pull with rebase: your working tree is not up-to-date  .gitignore.: needs update.
Решение жестко сменить HEAD ветки. Правда могут потеряться какие то изменения, зато pull заработает:)

  • git reset —hard origin/master

Основы Git — Работа с удалёнными репозиториями

Основы Git — Работа с удалёнными репозиториями

Работа с удалёнными репозиториями

Чтобы иметь возможность совместной работы над каким-либо Git-проектом, необходимо знать, как управлять удалёнными репозиториями. Удалённые репозитории — это модификации проекта, которые хранятся в интернете или ещё где-то в сети. Их может быть несколько, каждый из которых, как правило, доступен для вас либо только на чтение, либо на чтение и запись. Совместная работа включает в себя управление удалёнными репозиториями и помещение (push) и получение (pull) данных в и из них тогда, когда нужно обменяться результатами работы. Управление удалёнными репозиториями включает умение добавлять удалённые репозитории, удалять те из них, которые больше не действуют, умение управлять различными удалёнными ветками и определять их как отслеживаемые (tracked) или нет и прочее. Данный раздел охватывает все перечисленные навыки по управлению удалёнными репозиториями.

Отображение удалённых репозиториев

Чтобы просмотреть, какие удалённые серверы у вас уже настроены, следует выполнить командуgit remote. Она перечисляет список имён-сокращений для всех уже указанных удалённых дескрипторов. Если вы склонировали ваш репозиторий, у вас должен отобразиться, по крайней мере, origin — это имя по умолчанию, которое Git присваивает серверу, с которого вы склонировали:

$ git clone git://github.com/schacon/ticgit.git
Initialized empty Git repository in /private/tmp/ticgit/.git/
remote: Counting objects: 595, done.
remote: Compressing objects: 100% (269/269), done.
remote: Total 595 (delta 255), reused 589 (delta 253)
Receiving objects: 100% (595/595), 73.31 KiB | 1 KiB/s, done.
Resolving deltas: 100% (255/255), done.
$ cd ticgit
$ git remote
origin

Чтобы посмотреть, какому URL соответствует сокращённое имя в Git, можно указать команде опцию -v:

$ git remote -v
origin  git://github.com/schacon/ticgit.git (fetch)
origin  git://github.com/schacon/ticgit.git (push)

Если у вас больше одного удалённого репозитория, команда покажет их все. Например, мой репозиторий Grit выглядит следующим образом.

$ cd grit
$ git remote -v
bakkdoor  git://github.com/bakkdoor/grit.git
cho45     git://github.com/cho45/grit.git
defunkt   git://github.com/defunkt/grit.git
koke      git://github.com/koke/grit.git
origin    git@github.com:mojombo/grit.git

Это означает, что мы легко можем получить изменения от любого из этих пользователей. Но, заметьте, что origin — это единственный удалённый сервер прописанный как SSH-ссылка, поэтому он единственный, в который я могу помещать свои изменения (это будет рассмотрено в главе 4).

Добавление удалённых репозиториев

В предыдущих разделах мы упомянули и немного продемонстрировали добавление удалённых репозиториев, сейчас мы рассмотрим это более детально. Чтобы добавить новый удалённый Git-репозиторий под именем-сокращением, к которому будет проще обращаться, выполните git remote add [сокращение] [url]:

$ git remote
origin
$ git remote add pb git://github.com/paulboone/ticgit.git
$ git remote -v
origin  git://github.com/schacon/ticgit.git
pb  git://github.com/paulboone/ticgit.git

Теперь вы можете использовать в командной строке имя pb вместо полного URL. Например, если вы хотите извлечь (fetch) всю информацию, которая есть в репозитории Павла, но нет в вашем, вы можете выполнить git fetch pb:

$ git fetch pb
remote: Counting objects: 58, done.
remote: Compressing objects: 100% (41/41), done.
remote: Total 44 (delta 24), reused 1 (delta 0)
Unpacking objects: 100% (44/44), done.
From git://github.com/paulboone/ticgit
 * [new branch]      master     -> pb/master
 * [new branch]      ticgit     -> pb/ticgit

Ветка master Павла теперь доступна локально как pb/master. Вы можете слить (merge) её в одну из своих веток или перейти на эту ветку, если хотите её проверить.

Fetch и Pull

Как вы только что узнали, для получения данных из удалённых проектов, следует выполнить:

$ git fetch [имя удал. сервера]

Данная команда связывается с указанным удалённым проектом и забирает все те данные проекта, которых у вас ещё нет. После того как вы выполнили команду, у вас должны появиться ссылки на все ветки из этого удалённого проекта. Теперь эти ветки в любой момент могут быть просмотрены или слиты. (В главе 3 мы перейдём к более детальному рассмотрению, что такое ветки и как их использовать.)

Когда вы клонируете репозиторий, команда clone автоматически добавляет этот удалённый репозиторий под именем origin. Таким образом, git fetch origin извлекает все наработки, отправленные (push) на этот сервер после того, как вы склонировали его (или получили изменения с помощью fetch). Важно отметить, что команда fetch забирает данные в ваш локальный репозиторий, но не сливает их с какими-либо вашими наработками и не модифицирует то, над чем вы работаете в данный момент. Вам необходимо вручную слить эти данные с вашими, когда вы будете готовы.

Если у вас есть ветка, настроенная на отслеживание удалённой ветки (для дополнительной информации смотри следующий раздел и главу 3), то вы можете использовать команду git pull. Она автоматически извлекает и затем сливает данные из удалённой ветки в вашу текущую ветку. Этот способ может для вас оказаться более простым или более удобным. К тому же по умолчанию команда git clone автоматически настраивает вашу локальную ветку master на отслеживание удалённой ветки master на сервере, с которого вы клонировали (подразумевается, что на удалённом сервере есть ветка master). Выполнение git pull, как правило, извлекает (fetch) данные с сервера, с которого вы изначально склонировали, и автоматически пытается слить (merge) их с кодом, над которым вы в данный момент работаете.

Push

Когда вы хотите поделиться своими наработками, вам необходимо отправить (push) их в главный репозиторий. Команда для этого действия простая: git push [удал. сервер] [ветка]. Чтобы отправить вашу ветку master на сервер origin (повторимся, что клонирование, как правило, настраивает оба этих имени автоматически), вы можете выполнить следующую команду для отправки наработок на сервер:

$ git push origin master

Эта команда срабатывает только в случае, если вы клонировали с сервера, на котором у вас есть права на запись, и если никто другой с тех пор не выполнял команду push. Если вы и кто-то ещё одновременно клонируете, затем он выполняет команду push, а затем команду push выполняете вы, то ваш push точно будет отклонён. Вам придётся сначала вытянуть (pull) их изменения и объединить с вашими. Только после этого вам будет позволено выполнить push. Смотри главу 3 для более подробного описания, как отправлять (push) данные на удалённый сервер.

Инспекция удалённого репозитория

Если хотите получить побольше информации об одном из удалённых репозиториев, вы можете использовать команду git remote show [удал. сервер]. Если вы выполните эту команду с некоторым именем, например, origin, вы получите что-то подобное:

$ git remote show origin
* remote origin
  URL: git://github.com/schacon/ticgit.git
  Remote branch merged with 'git pull' while on branch master
    master
  Tracked remote branches
    master
    ticgit

Она выдаёт URL удалённого репозитория, а также информацию об отслеживаемых ветках. Эта команда любезно сообщает вам, что если вы, находясь на ветке master, выполните git pull, ветка master с удалённого сервера будет автоматически влита в вашу сразу после получения всех необходимых данных. Она также выдаёт список всех полученных ею ссылок.

Это был пример для простой ситуации, и наверняка вы встретились с чем-то подобным. Однако, если вы используете Git более интенсивно, вы можете увидеть гораздо большее количество информации от git remote show:

$ git remote show origin
* remote origin
  URL: git@github.com:defunkt/github.git
  Remote branch merged with 'git pull' while on branch issues
    issues
  Remote branch merged with 'git pull' while on branch master
    master
  New remote branches (next fetch will store in remotes/origin)
    caching
  Stale tracking branches (use 'git remote prune')
    libwalker
    walker2
  Tracked remote branches
    acl
    apiv2
    dashboard2
    issues
    master
    postgres
  Local branch pushed with 'git push'
    master:master

Данная команда показывает какая именно локальная ветка будет отправлена на удалённый сервер по умолчанию при выполнении git push. Она также показывает, каких веток с удалённого сервера у вас ещё нет, какие ветки всё ещё есть у вас, но уже удалены на сервере. И для нескольких веток показано, какие удалённые ветки будут в них влиты при выполнении git pull.

Удаление и переименование удалённых репозиториев

Для переименования ссылок в новых версиях Git’а можно вылолнить git remote rename, это изменит сокращённое имя, используемое для удалённого репозитория. Например, если вы хотите переименовать pb в paul, вы можете сделать это следующим образом:

$ git remote rename pb paul
$ git remote
origin
paul

Стоит упомянуть, что это также меняет для вас имена удалённых веток. То, к чему вы обращались как pb/master, стало paul/master.

Если по какой-то причине вы хотите удалить ссылку (вы сменили сервер или больше не используете определённое зеркало, или, возможно, контрибьютор перестал быть активным), вы можете использовать git remote rm:

$ git remote rm paul
$ git remote
origin

Git на сервере — Настраиваем сервер

Настраиваем сервер

Давайте рассмотрим настройку доступа по SSH на стороне сервера. В этом примере мы будем использовать метод authorized_keys для аутентификации пользователей. Мы подразумеваем, что вы используете стандартный дистрибутив Linux типа Ubuntu. Для начала создадим пользователя ‘git’ и каталог .ssh для этого пользователя:

$ sudo adduser git
$ su git
$ cd
$ mkdir .ssh

Затем нужно добавить открытый SSH-ключ какого-нибудь разработчика в файлauthorized_keys этого пользователя. Предположим, вы уже получили несколько ключей по электронной почте и сохранили их во временные файлы. Напомню, открытые ключи выглядят вот так:

$ cat /tmp/id_rsa.john.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4L
ojG6rs6hPB09j9R/T17/x4lhJA0F3FR1rP6kYBRsWj2aThGw6HXLm9/5zytK6Ztg3RPKK+4k
Yjh6541NYsnEAZuXz0jTTyAUfrtU3Z5E003C4oxOj6H0rfIF1kKI9MAQLMdpGW1GYEIgS9Ez
Sdfd8AcCIicTDWbqLAcU4UpkaX8KyGlLwsNuuGztobF8m72ALC/nLF6JLtPofwFBlgc+myiv
O7TCUSBdLQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPq
dAv8JggJICUvax2T9va5 gsg-keypair

Вы просто добавляете их в свой файл authorized_keys:

$ cat /tmp/id_rsa.john.pub >> ~/.ssh/authorized_keys
$ cat /tmp/id_rsa.josie.pub >> ~/.ssh/authorized_keys
$ cat /tmp/id_rsa.jessica.pub >> ~/.ssh/authorized_keys

Теперь вы можете создать пустой репозиторий для них, запустив git init с параметром --bare, что инициализирует репозиторий без рабочего каталога:

$ cd /opt/git
$ mkdir project.git
$ cd project.git
$ git --bare init

Затем Джон, Джози или Джессика могут отправить первую версию своего проекта в этот репозиторий, добавив его как удалённый и отправив ветку. Заметьте, что кто-то должен заходить на сервер и создавать голый репозиторий каждый раз, когда вы хотите добавить проект. Пусть gitserver — имя хоста сервера, на котором вы создали пользователя ‘git’ и репозиторий. Если он находится в вашей внутренней сети, вы можете настроить DNS-запись дляgitserver, ссылающуюся на этот сервер, и использовать эти команды:

# на компьютере Джона 
$ cd myproject
$ git init
$ git add .
$ git commit -m 'initial commit'
$ git remote add origin git@gitserver:/opt/git/project.git
$ git push origin master

Теперь остальные могут склонировать его и отправлять (push) туда изменения так же легко:

$ git clone git@gitserver:/opt/git/project.git
$ cd project
$ vim README
$ git commit -am 'fix for the README file'
$ git push origin master

Этим способом вы можете быстро получить Git-сервер с доступом на чтение/запись для небольшой группы разработчиков.

В качестве дополнительной меры предосторожности вы можете ограничить возможности пользователя ‘git’ только действиями, связанными с Git’ом, с помощью ограниченной оболочкиgit-shell, поставляемой вместе с Git’ом. Если вы выставите её в качестве командного интерпретатора пользователя ‘git’, то этот пользователь не сможет получить доступ к обычной командной оболочке на вашем сервере. Чтобы её использовать, укажите git-shell вместо bash или csh в качестве командной оболочки пользователя. Для этого вы должны отредактировать файл /etc/passwd:

$ sudo vim /etc/passwd

В конце вы должны найти строку, похожую на эту:

git:x:1000:1000::/home/git:/bin/sh

Замените /bin/sh на /usr/bin/git-shell (или запустите which git-shell, чтобы проверить, куда он установлен). Отредактированная строка должна выглядеть следующим образом:

git:x:1000:1000::/home/git:/usr/bin/git-shell

Теперь пользователь ‘git’ может использовать SSH-соединение только для работы с Git-репозиториями и не может зайти на машину. Вы можете попробовать и увидите, что вход в систему отклонён:

$ ssh git@gitserver
fatal: What do you think I am? A shell?
Connection to gitserver closed.

bitbucket

Uploading or pushing a Git or Mercurial project to an empty repository

You can upload an existing repository to a empty project in Bitbucket. When you do this, Bitbucket maintains your commit history.

Pushing a Git project

This kind of push overwrites the contents of the Bitbucket repository. You should use it with great caution.

  1. Create an empty repository in Bitbucket.
  2. Open a shell on your local machine (GitBash terminal for Windows users).
  3. Verify your SSH key is working. 
    $ ssh -T git@bitbucket.org
conq: logged in as tutorials.

You can use git or hg to connect to Bitbucket. Shell access is disabled.

    The message should report you are logged in as your Bitbucket account. In this example, my ssh key was on my tutorials account. If you don’t get this message, stop and troubleshoot your SSH connection to Bitbucket. (See Use the SSH protocol with Bitbucket for information about doing this.)

  4. Navigate to the root directory of the repository you want to push. 
    $ cd ~/repos/originalrepo
  5. Push the local repo up to Bitbucket 
    $ git push --mirror git@bitbucket.org:tutorials/exploratory

    This command pushes your local repository to the Bitbucket server.