Исправлено: Gitignore не работает —

Очень часто при создании проектов в PhpStorm от компании JetBrains при первом коммите народ по привычке нажимает «ОК» на все вопросы IDE и папка .idea попадает в git-репозиторий, которой там совсем не место. Удаляется оттуда она очень просто.

Отправка новых файлов на удалённый репозиторий

  1. Перейдите в директорию (папку) с привязанным репозиторием
  2. Поместите в данную директорию свои файл/файлы, которые хотите отправить на удалённый репозиторий GitHub
  3. Кликните правой кнопкой мыши и нажмите на «Git Bash Here»
  4. Откроется окно консоли. Теперь переходим к командам для отправки на удалённый репозиторий. Введите команду для добавления директории в список отправки
  5. Команда для отправки через git на GitHub Shell git add newFIles/
    1 git add newFIles/

    и нажмите клавишу Enter, в консоле ничего появится не должно;

  6. Следующим шагом добавим файл для добавления его в список отправки
  7. Команда для отправки через git на GitHub Shell git add
    1 git add

    и нажмите клавишу Enter, в консоле ничего появится не должно;

  8. Теперь проверим какие файлы и директории были добавлены, да и вообще убедимся в каких частях нашего проекта были изменения. Введите команду
  9. Команда для отправки через git на GitHub Shell git status
    1 git status

    и нажмите клавишу Enter, в консоле появится список на отправление Появились новые файлы: один новый файл в корне проекта, четыре новых файла в директории newFiles;

  10. Теперь необходимо создать текстовую запись (можно сказать, что это запись в журнале изменений) о наших изменениях. Называется этот процесс «создание коммита» или «create commit«. Помните, каждый коммит должен быть атомарен, то есть каждый коммит должен отражать одно изменение в проекте. Хорошей практикой является следующая аксиома: «сделал одну правку в проекте — закоммитил и отправил» и таким образом вносить все правки в свой проект. Не беспокойтесь, что коммитов из-за этого может быть много, это не страшно, страшно тогда, когда в ваших коммитах невозможно разобраться. Текст для коммитов должен быть осмысленным и отображать суть внесённых правок. С коммитами можно провести такую ассоциацию: «Коммит — это запись в журнале изменений проекта. Записывается кто внёс правку, какую человек внёс правку и дату внесения изменения». По этим самим коммитам можно вернуться к определённому моменту развития проекта и работать от этого момента, поэтому каждый коммит должен отражать одно изменение. Жёстким требованием это не является (бывают разные случаи, например нет возможности отправить), но рекомендуется поступать именно так. Закомитимся Введите следующую команду для того, чтобы создать коммит
  11. Команда для отправки через git на GitHub Shell git commit -m «Отправка тестовых текстовых файлов»
    1 git commit m «Отправка тестовых текстовых файлов»

    и нажмите клавишу Enter Появилось сообщение о создании новых элементов;

  12. Отправляем в репозиторий GitHub, то есть «пушимся»
  13. Команда для отправки через git на GitHub Shell git push
    1 git push

    файлы благополучно отправлены. Подобное сообщение будет и с отправкой на Ваш репозиторий.

  14. Убедимся, что всё так. Зайдите на страницу своего репозитория на GitHub Обратите внимание на выделенные области, появились новый файл и одна директория, которая содержит в себе четыре файла. Также в заголовке прописано какой был последний коммит в данный репозиторий;

Таким не хитрым образом мы разобрались с «отправка файлов в удалённый репозиторий на GitHub»!

revert, checkout, reset

Команды revert, checkout, reset позволяют отменять изменения в репозитории и управлять ими. Поведение похожее, поэтому команды действительно легко спутать. Рассмотрим подробно каждую из них.

git revert

Команда git revert – безопасный способ отменить операцию без потери истории коммитов. Команда отменяет действия прошлых коммитов, создавая новый, содержащий все отменённые изменения. Эта команда полезна, когда вы уже запушили изменения в удаленный репозиторий, так как она сохраняет нетронутым исходный коммит.

Откатиться с помощью commit-хэшей:

revert, checkout, reset

git revert [SHA]

Можно и с помощью диапазонов:

git revert HEAD~[num-of-commits-back]Действие git revert

git checkout

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

Для переключения между ветками:

git checkout [название ветки]

revert, checkout, reset

Для проверки более старого коммита с помощью хэша:

git checkout [SHA]

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

git checkout HEAD~[num-of-commits-back]

Чтобы отменить все локальные незакоммиченные изменения:

git checkout

Чтобы отменить определенное локальное незакоммиченное изменение:

git checkout — [имя файла]

revert, checkout, reset

Действие git checkout

git reset

Команда git reset – это мощный способ отменить операцию. Существует три возможных аргумента:

—mixed

Значение по умолчанию. Команда git reset —mixed аналогична git reset. Вы переключите HEAD на последний коммит, и все изменения, добавленные после него, будут доступны в качестве неотслеживаемых (untracked) изменений в вашем рабочем каталоге.

—soft

HEAD переключается на последний коммит, однако, изменения, добавленные после этой фиксации, остаются с пометкой staged.

—hard

revert, checkout, reset

Используйте команду git reset —hard только тогда, когда вы знаете, что делаете. Вы переключите HEAD на последний коммит и уничтожите изменения, сделанные после него. Это действие не может быть отменено.

Действие git reset

Вы не должны использовать git reset, когда вы уже запушили данные на удаленный репозиторий. Удаление коммита другого члена команды нарушит его рабочий процесс.

Используйте git reset — [имя файла], чтобы отменить изменения в файле, который еще не был зафиксирован.

Удаление удаленной remote ветки

В Git версии v1.7.0, вы можете удалить remote ветку используя

$ git push <remote_name> —delete <branch_name>

что возможно легче запомнить, чем команду

$ git push <remote_name> :<branch_name>

которая была добавлена в Git v1.5.0 «чтобы удалить удаленную remote ветку или тег tag.»

Начиная с Git v2.8.0 вы также можете использовать git push с опцией -d как ярлык вместо —delete.

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

Удалить удаленную remote ветку

Цитата из 3-ей главы книги  Pro Git Скотта Чакона:

Удаление Удалённых Веток

Полагаю вы завершили с работой в удаленной ветке, вы и ваши сотрудники закончили с новой фичей и смержили ее в вашу mster ветку на удаленном репозитории. Вы можете удалить удаленную ветку используя довольно тупой синтаксис git push [remotename] :[branch]. Если вы хотите удалить вашу bugfix ветку с фиксом багов на сервере, вы запускаете следующую команду:

$ git push origin :serverfix To [email protected]:schacon/ — [deleted] serverfix

Бабах! И не больше такой ветки на вашем сервере. Наверное вам захочется поставить закладку на эту страницу, потому что вам еще понадобится эта команда, и вы скорее всего забудете как она пишется. Способ чтобы запомнить эту команду, вспомнить прошлую git push [remotename] [localbranch]:[remotebranch] синтаксис которой мы рассматривали немного ранее. Если вы оставите [localbranch] , тогда вы буквально скажите следующее “Возьми ничего с моей стороны и сделай это [remotebranch].”

Я использовал git push origin :bugfix и это отлично работает.

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

git fetch —all —prune

чтобы распространить изменения.

Что заставляет .gitignore не работать?

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

Вот некоторые решения, которые могут работать для вас. Каждое решение может быть неприменимо в вашем случае, поэтому убедитесь, что вы переключаетесь на следующее, если начальные условия не выполняются.

Решение 1. Проверка файла .gitignore

Появился интересный случай, когда мы увидели, что файл .gitignore создан в неправильном формате. Эта конкретная проблема возникла, когда пользователи создали файл с помощью стандартного приложения «Блокнот» в ОС Windows. Оказывается, Блокнот пишет файл в Unicode вместо формата ANSI. В этом решении мы сохраним изменения в Блокноте в правильном формате .gitignore и посмотрим, решит ли это проблему.

Замечания: Вы должны удалить расширение .txt из файла, когда создаете новый файл с помощью Блокнота.

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

Сохранить как — Блокнот

  1. Сейчас перед кодирование, Выбрать ANSI. Теперь удалите расширение файла .txt и сохраните файл с именем ‘.gitignore». Выберите правильный каталог и сохраните.

Выбор ANSI в качестве типа кодировки

  1. Теперь перейдите в каталог и проверьте, создан ли правильный файл. Теперь протестируйте его снова с помощью Git и посмотрите, работает ли функция игнорирования должным образом.

Разработчики должны воздерживаться от использования Блокнота по умолчанию в Windows. Вместо этого вы должны использовать соответствующий «блокнот для программистов». Некоторые примеры включают Notepad ++ и т. Д. В них таких проблем не будет.

Замечания: Если ваш файл уже сохранен в формате UNICODE, вы должны правильно сохранить содержимое в формате ANSI, если вы хотите, чтобы Git правильно обнаружил ваш файл.

Решение 2. Проверка файла, который вы пытаетесь игнорировать

Другое условие, при котором работает .gitignore — это то, что ваш файл не должен быть часть хранилища еще. Это очень важный аспект, так как если это правда, файл не будет проигнорирован, как есть уже добавлено в хранилище. Git не может игнорировать это, даже если вы поместите его имя или правило в файл .gitignore. Так по сути, Git только игнорирует неотслеживаемые файлы.

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

Решение 3. Повторное добавление файлов в репозиторий

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

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

  1. Выполните следующую команду. Это приведет к удалению и удалению путей к вашим файлам из индекса git рекурсивным способом.

git rm -r — кэшировано.

  1. После того, как это выполнено, вы должны выполнить следующую команду. Это добавит все ваши файлы обратно, и так как .gitignore будет иметь правила, будут обновлены только правильные файлы.

мерзавец добавить.

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

git commit -m «.gitignore сейчас работает»

Теперь проверьте ваши файлы и посмотрите, решена ли проблема, и вы можете снова использовать .gitignore без каких-либо проблем.

Где физически хранится конфигурация

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

  • Системная конфигурация: C:\Program Files\Git\mingw64\etc\gitconfig Задается из командной строки с параметром –system
  • Пользовательская конфигурация: C:\Users\Имя\.gitconfig Задается из командной строки с параметром –global
  • Конфигурация репозитория: C:\…\hello\.git\config Задается без параметров Просто выполняете команду git config в нужном репозитории. Например, задать имя в текущем репозитории:

Дальнейшие коммиты

Давайте изменим несколько файлов после того, как мы их закоммитили. После того, как мы их изменили, git status сообщит о том, что у нас есть измененные файлы.

Можно посмотреть, что же изменилось в этих файлах с момента предыдущего коммита, с помощью команды git diff. Если вы хотите просмотреть изменения для конкретного файла, можно использовать git diff <файл>.

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

git add -u

Можно избежать использования этой команды, если добавить параметр -a к git commit. Эта команда проиндексирует все измененные файлы, и закоммитит их. Но такой подход может быть довольно опасным, так по ошибке можно закоммитить то, что не хотелось. Например, скажем, что вы открыли файл, и случайно его изменили. При индексировании измененных файлов вы будете оповещены об изменениях в каждом файле. Но если вы отправите на коммит все измененные файлы не глядя с помощь. git commit -a, то будут закоммичены все файлы, включая те, которые вы коммитить не хотели.

Как только вы проиндексировали файлы, можно приступать к коммиту. Как упоминалось ранее, к коммиту можно указать сообщение с помощью ключа -m. Но также можно указывать и многострочные комментарии с помощью команды git commit, которая открывает консольный редактор для ввода комментария.

git commit

Читайте также:  20 команд netstat для управления сетью Linux и Windows