Почему не работает гит

Git: распространённые ошибки и способы их исправления

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

Ошибка в сообщении последнего коммита

После нескольких часов хорошей работы легко допустить ошибку в сообщении коммита. К счастью, это легко исправить с помощью следующей команды:

Эта команда откроет редактор и позволит внести изменения в последнее сообщение коммита. Никому кроме вас не стоит знать, что вы написали «Initial commment» с тремя «m».

Ошибка в имени ветки

Предположим, что на часах почти 15:00, а вы ещё не обедали. В результате, терзаемые голодом, вы назвали новую ветку feature-brunch . Вкуснятина, ничего не скажешь.

Эту проблему тоже можно решить. Переименовать ветку можно так же, как переименовывают файлы с помощью команды mv . Речь идёт о перемещении её в новое место с правильным именем:

Если вы уже отправили эту ветку в репозиторий, вам, для её переименования, потребуется сделать ещё пару дел. Старую ветку надо удалить, а новую — отправить в репозиторий:

Случайный коммит изменений в ветку master

Предположим, вы работаете над некоей новой возможностью, и, в спешке, забыли создать для неё новую ветку. Вы закоммитили уже кучу файлов и всё это лежит в ветке master . Переместить все эти изменения в новую ветку можно с помощью следующих трёх команд. Обратите внимание на то, что если вы не воспользовались, в применении к изменениям, командами commit или stash , они будут утеряны.

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

Работа с файлами, которые забыли добавить в последний коммит

Ещё одна распространённая оплошность при работе с Git заключается в том, что коммиты делают слишком рано и в них не попадают нужные файлы. Скажем, вы пропустили некий файл, забыли его сохранить, или вам нужно внести небольшое изменение в файл для того, чтобы последний коммит имел смысл. В подобной ситуации вам снова пригодится команда —amend . Добавьте пропущенный файл в индекс репозитория и запустите эту команду:

После этого вы можете изменить сообщение коммита, либо оставить его таким же, каким оно было.

Добавление не того файла в репозиторий

Как быть, если ваша ошибка представляет собой полную противоположность предыдущей? Что если вы добавили в индекс файл, который не собираетесь коммитить? Это может быть какой-нибудь ENV-файл, директория сборки проекта, фото вашей собаки, которое вы случайно сохранили не в той папке. Всё это можно исправить.

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

Если вы продвинулись достаточно далеко и успели изменение закоммитить, то знайте, что и это поправимо. Придётся лишь воспользоваться ещё несколькими командами:

В результате последний коммит будет отменён, изображение будет удалено, после чего новый коммит будет помещён туда, где ему положено быть.

Что делать, если всё пошло не так?

Методика, которую мы сейчас обсудим, помогает в ситуациях, когда всё идёт не так, как надо. Например, такое происходит, когда вы слишком увлекаетесь копированием готовых решений со StackOverflow, и, после работы, ваш репозиторий оказывается в худшем состоянии чем он был в самом начале. В такую ситуацию, пожалуй, попадали все мы.

Команда git reflog показывает список всего, что вы сделали. Затем она позволяет воспользоваться инструментами Git для отката изменений, для возврата к одному из прошлых состояний репозитория. Стоит отметить, что этот метод стоит рассматривать как последнее средство, и, прежде чем им воспользоваться, стоит как следует подумать. Итак, вывести список того, что было сделано, можно следующей командой:

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

Обратите внимание на самую левую колонку этого списка. Тут содержатся индексы. Если вам нужно вернуться назад, в некий момент прошлого, выполните следующую команду, заменив соответствующей ссылкой, например — dfa27a2 . Выглядит эта команда так:

Итоги

Мы рассмотрели некоторые способы борьбы с ошибками, возникающими при работе с Git. Надеемся, вы подобных ошибок не допустите и вам эти приёмы работы с Git не пригодятся. А если что-то пойдёт не так — вы будете знать, что делать.

Уважаемые читатели! Знаете о каких-нибудь интересных приёмах работы с Git? Если так — просим ими поделиться.

Источник

Git happens! 6 типичных ошибок Git и как их исправить

Прим. перев.: На днях в блоге для инженеров любимого нами проекта GitLab появилась небольшая, но весьма полезная заметка с инструкциями, которые помогают сохранить время и нервы в случае различных проблем, случающихся по мере работы с Git. Вряд ли они будут новы для опытных пользователей, но обязательно найдутся и те, кому они пригодятся. А в конец этого материала мы добавили небольшой бонус от себя. Хорошей всем пятницы!

Все мы делаем ошибки, особенно при работе с такими сложными системами, как Git. Но помните: Git happens!

Если вы только начинаете путь с Git, обучитесь основам работы с ним в командной строке. А здесь я расскажу о том, как можно исправить шесть наиболее распространённых ошибок в Git.

1. Упс… Я ошибся в сообщении к последнему коммиту

После нескольких часов кодинга легко допустить ошибку в сообщении коммита. К счастью, это легко исправить:

С этой командой откроется текстовый редактор и позволит внести изменения в сообщение к последнему коммиту. И никто не узнает, что вы написали «addded» с тремя «d».

2. Упс… Я забыл добавить файл к последнему коммиту

Другая популярная ошибка в Git — слишком поспешный коммит. Вы забыли добавить файл, забыли его сохранить или должны внести небольшое изменение, чтобы коммит стал осмысленным? Вашим другом снова будет —amend .

Добавьте недостающий файл и выполните эту верную команду:

Теперь вы можете либо откорректировать сообщение, либо просто сохранить его в прежнем виде (с добавленным файлом).

3. Упс… Я добавил файл, который не должен быть в этом репозитории

Но что, если у вас обратная ситуация? Что, если вы добавили файл, который не хотите коммитить? Обманчивый ENV-файл, директорию сборки или фото с котом, что было случайно сохранено в неправильном каталоге… Всё решаемо.

Если вы сделали только stage для файла и ещё не коммитнули его, всё делается через простой reset нужного файла (находящегося в stage):

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

Коммит будет откачен, картинка удалена, а затем сделан новый коммит.

Прим. перев.: Как замечено в комментариях к оригинальной статье, эту проблему тоже можно решить с помощью уже упомянутого —amend . По всей видимости, данным пунктом автор хотел показать, какие ещё есть способы изменения истории коммитов для исправления ошибки.

4. Упс… Я коммитнул изменения в master

Итак, вы работаете над новой фичей и поспешили, забыв создать новую ветку для неё. Вы уже коммитнули кучу файлов и все эти коммиты оказались в master’е. К счастью, GitLab может предотвращать push’ы прямо в master. Поэтому мы можем откатить все нужные изменения в новую ветку следующими тремя командами:

Примечание: Убедитесь, что сначала коммитнули или stash‘нули свои изменения — иначе все они будут утеряны!

Будет создана новая ветка, в master’е — произведён откат до состояния, в котором он был до ваших изменений, а затем сделан checkout новой ветки со всеми вашими изменениями.

5. Упс… Я сделал ошибку в названии ветки

Самые внимательные могли заметить в предыдущем примере ошибку в названии ветки. Уже почти 15:00, а я всё ещё не обедал, поэтому мой голод назвал новую ветку (branch) как future-brunch. Вкуснотища!

Переименуем эту ветку аналогичным способом, что используется при переименовании файла с помощью команды mv, то есть поместив её в новое место с правильным названием:

Если вы уже push’нули эту ветку, понадобится пара дополнительных шагов. Мы удалим старую ветку из remote и push’нем новую:

Прим. перев.: Удалить ветку из remote ещё можно с помощью:

6. Oops… I did it again!

Последняя команда на тот случай, когда всё пошло не так. Когда вы накопировали и навставляли кучу решений со Stack Overflow, после чего в репозитории всё стало ещё хуже, чем было в начале. Все мы однажды сталкивались с подобным…

git reflog показывает список всех выполненных вами операций. Затем он позволяет использовать магические возможности Git’а по путешествию во времени, т.е. вернуться к любому моменту из прошлого. Должен отметить, что это ваша последняя надежда — не стоит прибегать к ней в простых случаях. Итак, чтобы получить список, выполните:

Каждый наш шаг находится под чутким наблюдением Git’а. Запуск команды на проекте выше выдал следующее:

Обратите внимание на самый левый столбец — это индекс. Если вы хотите вернуться к любому моменту в истории, выполните следующую команду, заменив на соответствующее значение (например, dfa27a2 ):

Итак, теперь у вас есть шесть способов выбраться из самых частых Gitfalls (игра слов: pitfall переводится как «ловушка, ошибка» — прим. перев.).

Бонус от переводчика

Во-первых, ценное замечание ко всему написанному выше (кроме пункта 5). Нужно учитывать, что эти действия меняют историю коммитов, поэтому их следует проводить, только если изменения не были отправлены в remote (push’нуты). В противном случае старый плохой коммит уже будет на remote-ветке и придётся либо выполнять git pull (который сделает merge, и тогда попытка «почистить» историю приведёт к худшим последствиям), либо git push —force , что чревато потерей данных при работе с веткой нескольких человек…

Теперь — небольшие полезные дополнения из нашего опыта:

• Если вы (случайно или нет) сменили ветку и вам нужно вернуться на предыдущую, самый быстрый способ — использовать git checkout — .
• Если вы случайно добавили к коммиту файл, который не должен быть туда добавлен, но ещё не сделали коммит — используйте git reset HEAD path/to/file . Похожая ситуация описана в пункте 3, но в действительности она шире, т.к. относится к любым ненужным изменениям в коммите (не только к случаю лишнего файла).
• Хорошей практикой, чтобы не закоммитить лишнего, является использование параметра -p при добавлении файла к коммиту ( git add -p ). Это позволяет сделать review каждого изменения, которое уйдёт в коммит. Но стоит помнить, что он не добавляет к коммиту untracked-файлы — их нужно добавлять без этого параметра.
• Ряд хороших рекомендаций (в том числе и более сложных), можно найти в статье 2014 года «Git Tutorial: 10 Common Git Problems and How to Fix Them». В частности, обратите внимание на использование git revert и git rebase -i .

Источник

Траблы с GIT, не работают любые команды с сервером

Порядка недели назад столкнулся с весьма странной проблемой.
Сижу под виндой, с гит работал в основном через VS 2015, есть проект, уже довольно давно лежит на гите, никогда раньше с коммитами и синхронизацией проблем не возникало, но неделю назад перестала работать вообще любая связь с Git o_O

Поскольку о причинах этих проблем есть лишь догадки, прошу помочь с их разрешением, собственно сами проблемы:
1) Связь с сайтом работает через раз, например главную страницу Git на русском у меня не грузит.
2) Локальный репозиторий все прекрасно пушит и держит, однако при попытке publish, тобишь попытки подгрузить изменения в проект получаю несколько видов ошибок, дальше в скринах.

Понимаю их суть, и понимаю что обрубает не просто так, если работать через addfile через сайт, то могу подгрузить нужные файлы, но мне нужен коммит, а не просто подгружать файлики, каждый раз, гемороясь с их конфликтами.

Собственно таким же макаром не создается даже pull request и любая попытка работы с репозиторием, проблемы раньше никогда не возникало и я в смятении. При этом получить инфу с сервера он вполне способен.

Из того чем пытался решить:
1) В конфигах выставил прокси, помогло на 1 коммит.
2) Пробовал менять DNS на гугловский, 0 эффекта.
3) Пытался закинуть коммиты через все инструменты, пытался обнулять репозитории, для проверки даже создал новый пустой проект попытался закинуть его в репозиторий, не прокатило те же самые ошибки.

Из догадок о причине:
1) Поскольку сервер просто обрывает соединение догадка лишь одна — роскомпозор?

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

P.S. Репозиторий публичный, но создатель я, все нужные пароли и логины прописаны, никаких изменений с софтом тем более гитовским не проводил, с железом тоже, все такое же как год назад.

Помощь в написании контрольных, курсовых и дипломных работ здесь.

Источник

Почему git не распознает, что мой файл был изменен, поэтому git add не работает

Я пытаюсь отправить свои файлы в github с помощью bash. Они уже там, и я загружаю более новую версию с новыми строками, кодом и т. Д. Но когда я пытаюсь, git add а потом появляется сообщение git status :

ничего не фиксировать, рабочий каталог чист

И файл, который я использую, был только что изменен.

У меня была проблема, когда однажды я установил для индекса git значение «считать неизменным» в моем файле.

Вы можете указать git, чтобы он перестал игнорировать изменения в файле:

Если это не поможет, сброса может быть достаточно для других странных случаев.

На практике я обнаружил, что удалил кешированный файл и заставил его работать:

В git rm —cached средстве для только удалить файл из индекса, и reset говорит мерзавец перезагрузить индекс GIT от последней фиксации.

Проверьте свой .gitignore файл . Вы можете обнаружить, что файл или расширение файла, или путь к файлу, с которым вы пытаетесь работать, совпадает с записью .gitignore , что объясняет, почему этот файл игнорируется (и не распознается как измененный файл).

Это случилось со мной, когда у меня была аналогичная проблема.

Как уже говорилось, файлы, вероятно, были помечены флажком «предположить-без изменений», который в основном сообщает git, что вы не будете изменять файлы, поэтому ему не нужно отслеживать изменения с их помощью. Однако это может повлиять на несколько файлов, и если это большое рабочее пространство, вы можете не захотеть проверять их все по одному. В этом случае вы можете попробовать: git update-index —really-refresh

По сути, это заставит git отслеживать изменения всех файлов, независимо от флагов «предполагать без изменений».

Звучит безумно, но иногда вы не в правильном репо, даже если думаете, что это так. Например, вы могли переместить родительский каталог, но забыли переключить репозиторий в текстовом редакторе. Или наоборот: вы находитесь в правильном репозитории в текстовом редакторе, но не в том репозитории в командной строке. В первой ситуации вы вносите изменения в правильный файл, но это не та папка, которая открыта в вашей командной строке, поэтому на самом деле это не тот файл. Во второй ситуации вы действительно отредактировали правильный файл, но git вашей командной строки не распознает изменение, потому что вы находитесь не в правильном каталоге в командной строке.

Что ж, у нас недостаточно ответов на этот вопрос, поэтому я дам вам несколько предположений:

1) вы сохранили свои изменения, чтобы исправить тип: git stash pop

2) у вас были изменения и вы их зафиксировали, вы должны увидеть свою фиксацию в git log

3) у вас были какие-то git reset —hard изменения, ваши изменения могут быть там в журнале ссылок, введите, git reflog —all а затем проверьте или выберите ссылку, если вы когда-нибудь ее найдете.

4) вы проверяли одно и то же репо несколько раз и ошиблись.

Произошла такая странная вещь. Плагин Eclipse Kepler git автоматически отмечал все мои папки проекта как игнорируемые в папке .gitignore.

Когда я заходил commit в Team меню, все они снова игнорировались. Насколько я могу судить, это произошло потому, что я установил их как производные в родительском проекте. Снятие отметки с них как dervied исправлено. Я никогда раньше не видел этого на Индиго. Надеюсь, это кому-то поможет.

TL; DR; Вы вообще находитесь в правильном репозитории?

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

На самом деле на моей машине, у меня было два отдельных GIT репозиториев repo1 и repo2 настроен в том же корневом каталоге с именем source . Эти два репозитория по сути являются репозиториями двух продуктов, над которыми я работаю в своей компании. Дело в том, что, как правило, структура каталогов исходного кода всех продуктов в моей компании одинакова.

Поэтому, не осознавая, я изменил файл с точно таким же именем, в repo2 котором я должен был изменить repo1 . Таким образом, я просто продолжал работать команду git status на repo1 и продолжал давать то же сообщение

ничего не фиксировать, рабочий каталог чист

в течение получаса. Затем мой коллега заметил это как независимую пару глаз и обратил на это мое внимание, что я был в неправильном, но очень похожем хранилище. В тот момент, когда я переключился на repo1 Git, я начал замечать измененные файлы.

Источник