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

Что такое Git и GitHub?

Информационный раздел репозитория GitHub.

Git — это программа с открытым исходным кодом, созданная Линусом Торвальдсом , известной в Linux. Git отслеживает изменения в документах и позволяет нескольким людям удаленно работать с одним и тем же документом. В техническом плане это называется распределенной системой контроля версий (или распределенной VCS). Git не может произвольно сохранять версии ваших документов через определенные промежутки времени. Вместо этого он сохраняет изменения в ваших документах, только когда вы сообщаете об этом.

Ваши документы образуют репозиторий (или репо), который является просто причудливым термином для папки вашего проекта. Например, ваша папка «Документы» в Windows была бы хранилищем, если бы вы использовали Git для управления ею (но не делайте этого).

Когда вы сохраняете изменения в ваших документах в Git, это называется «фиксация». Коммит — это просто запись самых последних изменений, которые вы внесли в документ. Каждому коммиту присваивается длинная строка из цифр и букв в качестве идентификатора.

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

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

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

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

Вместе Git и GitHub позволили мне контролировать историю версий на детальном уровне. И мои записи легко получить на любом ПК, который может работать с командной строкой Bash, в которую в настоящее время входят машины с Windows, Mac, Linux и Chrome OS.

Принудительная публикация

Git предотвращает перезапись истории центрального репозитория, отклоняя push-запросы, если нельзя выполнить их ускоренное слияние. Так, если история удаленного репозитория отличается от вашей истории, необходимо загрузить удаленную ветку командой pull и выполнить ее слияние с локальной веткой командой merge, а затем попробовать выполнить команду push еще раз. Это похоже на то, как в SVN необходимо синхронизироваться с центральным репозиторием с помощью команды перед тем, как сделать коммит набора изменений.

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

Создание нового репозитория Git в Visual Studio 2019

Если ваш код не связан с GIT, можно начать с создания нового репозитория GIT. Для этого в строке меню выберите GIT > Создать репозиторий GIT. Затем в диалоговом окне Создание репозитория GIT введите свои данные.

С помощью диалогового окна Создание репозитория GIT можно легко отправить новый репозиторий в GitHub. По умолчанию новый репозиторий является частным. Это означает, что доступ к нему есть только у вас. Если снять соответствующий флажок, репозиторий будет общедоступным. Это означает, что любой пользователь в GitHub сможет его просмотреть.

Dica

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

Вы можете создать исключительно локальный репозиторий GIT, выбрав параметр Только локальный. Вы также можете связать локальный проект с любым существующим пустым удаленным репозиторием, размещенным в Azure DevOps или у любого другого поставщика Git, с помощью параметра Существующий удаленный репозиторий.

Просмотр истории коммитов

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

Помимо автора и даты, у каждого комита есть идентификатор, который называется hash. Пример: 2934ee19f4d4ca37ff9bea9dc8208ef5362d789e. Необязательно использовать такую длинную запись, git поймет и по первым 5 символам, какой hash вам нужен.

Команда имеет очень большое количество опций для поиска коммитов по разным критериям.

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

6 ответов

Решение

git покажет изменения в коммитах, которые влияют на индекс, такие как , Он не хранит журнал всех команд git, которые вы выполняете.

Однако большое количество команд git так или иначе влияют на индекс, например, при создании новой ветви. Эти изменения появятся в истории коммитов, которую вы можете просмотреть ,

Однако есть деструктивные изменения, которые git не может отследить, такие как ,

Итак, чтобы ответить на ваш вопрос, git не хранит абсолютную историю Команды, которые вы выполнили в хранилище. Тем не менее, часто можно интерполировать, какую команду вы выполнили через историю коммитов.

-1

2011-09-15 18:14

Вы можете увидеть историю с помощью git-reflog ( пример здесь):

183

2011-09-15 18:19

Журнал ваших команд может быть доступен в вашей истории оболочки.

Если просмотр списка выполненных команд не для вас, экспортируйте список в файл.

Вы можете ограничить экспортируемый дамп, чтобы показывать только команды с «git», передавая его с помощью grep

История может содержать строки, отформатированные как таковые

Используя номер, вы можете повторно выполнить команду с восклицательным знаком

2013-01-19 18:03

Если вы используете CentOS или другой вариант Linux, просто сделайте + в командной строке и введите ,

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

2014-03-19 17:13

Введите свой терминал , Технически это не мерзко, но я думаю, что это то, что вы хотите.

2017-09-08 01:03

Если вы используете Windows PowerShell, вы можете набрать «git» и нажать F8. Продолжайте нажимать F8 для циклического перебора всех ваших команд git.

Или, если вы используете Cygwin, вы можете сделать то же самое с ^R.

2011-09-15 18:38

Я обнаружил, что в моей версии git bash «2.24.0.windows.2» в моей «домашней» папке для пользователей Windows будет файл с именем «.bash-history» без расширения файла в этой папке. Он создается только после выхода из bash.

Вот мой рабочий процесс:

перед выходом из bash введите «history >> history.txt»
выйти из командной строки bash
удерживайте Win+R, чтобы открыть окно команды Выполнить
введите оболочку: профиль
откройте «history.txt», чтобы подтвердить, что мой текст был добавлен
В новой строке нажмите , чтобы ввести метку времени.
сохранить и закрыть текстовый файл истории
Удалите файл «.bash-history», чтобы в следующем сеансе была создана новая история.

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

2019-11-30 00:24

Команда git rm

Для удаления файлов в системе Git, как уже упоминалось выше, имеется специальная команда . Ее отличие от обычной консольной команды (в том же Linux) заключается в особенности самой системы Git.

Как хорошо известно, в системе Git файл может одновременно существовать в трех ипостасях: в области “Working Directory”, в области “Staging Area”, в области “Repository”. Удаление файла из области “Working Directory” не приведет к его удалению из областей “Staging Area” и “Repository”.

Поэтому, чтобы удалить файл, нужно (в идеале) выполнить три команды подряд для удаления файла из Рабочей области “Working Directory”, затем из области индекса “Staging Area” и потом из области репозитория “Repository”:

Команда является ни чем иным, как “вшитым” в Git сокращением двух первых команд:

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

Удалим его командой :

Видим, что файл был сразу удален из двух областей: рабочего каталога “Working Directory” и области индексации “Staging Area”. Но в репозитории файл все же остался, о чем говорит вывод команды .

Любой последующий commit зафиксирует удаление этого файла:

Начало работы с Git в Visual Studio 2019

Мы подробно расскажем вам о том, как использовать новый интерфейс Git в Visual Studio. Однако если вы хотите сначала ознакомиться с кратким обзором, посмотрите следующее видео: Длительность видео: 05:27 мин.

Существует три способа начать использование Git в Visual Studio для повышения производительности:

. Если у вас уже есть код и он не связан с Git, можно начать с создания нового репозитория Git.
. Если код, с которым вы хотите работать, не находится на вашем компьютере, можно клонировать любые существующие удаленные репозитории.
. Если у вас уже есть код на компьютере, его можно открыть с помощью пункта меню Файл > Открыть > Решение/проект (или Папка). Visual Studio автоматически определяет, имеется ли инициализированный репозиторий GIT.

Observação

Начиная с версии 16.8 Visual Studio 2019 включает полностью интегрированный интерфейс для работы с учетными записями GitHub. Теперь вы можете добавить в цепочку ключей учетные записи GitHub и GitHub Enterprise. Вы сможете добавлять и использовать их так же, как и учетные записи Майкрософт. Это позволит упростить доступ к ресурсам GitHub в Visual Studio. Дополнительные сведения см. на странице Работа с учетными записями GitHub в Visual Studio.

Dica

Если у вас нет учетной записи GitHub, можно начать с выполнения действий, описанных в разделе Создание учетной записи GitHub для использования с Visual Studio.

Перенесите свой настольный репозиторий в облако

Использование Git в командной строке.

При первом подключении репозитория к GitHub вы должны использовать несколько специализированных команд. Первый из них:

  git remote добавить источник https://github.com/ /MyNovel.git

Это говорит Git, что удаленный репозиторий является источником «MyNovel». Затем URL указывает Git на этот удаленный источник. Не зацикливайтесь на термине «происхождение»; это просто соглашение. Вы можете назвать это «пушистым», если хотите — происхождение проще, поскольку это самый распространенный способ использования Git.

Когда вы загружаете новые изменения с помощью Git, это называется «push». Когда вы загружаете изменения, это называется «pull» или «fetch». Теперь пришло время отправить ваш первый коммит в GitHub. Вот что вы делаете:

  git push -u мастер оригинала

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

Если вы хотите больше безопасности для ваших загрузок GitHub, вы можете использовать ключ SSH. Это позволяет использовать один пароль для загрузки ключа SSH, поэтому вам не нужно каждый раз вводить полные учетные данные GitHub. Кроме того, только кто-то с ключом SSH может загрузить изменения файла.

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

Это оно! Теперь, когда вы хотите зафиксировать изменения в ваших файлах, вы можете сделать это с помощью этих трех коротких команд (после перехода в папку «MyNovel»):

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

Перевод: «Привет, Git этап для фиксации всех неотслеживаемых файлов, а также новых изменений в файлах, которые вы уже отслеживаете».

  git commit -m "1000 слов о новом обзоре iPhone."

Перевод: «Эй, Git, сохрани эти изменения вместе с этим сообщением».

  мастер происхождения git push

Перевод: «Привет, Git, загрузи изменения в исходную версию этого проекта на GitHub из моей мастер-копии на этом ПК».

Начало работы с Git

Давайте рассмотрим технические детали того, как все это работает. Мы начнем с ПК, а затем перейдем в облако с GitHub.

Для начала вам понадобится терминальная программа на macOS или Linux. Если ваш компьютер работает под управлением Windows 10, вам необходимо установить Ubuntu или другой дистрибутив Linux через подсистему Windows для Linux (WSL), что довольно просто. Вы можете ознакомиться с нашим руководством по установке оболочки Linux Bash в Windows 10 . Или, если вы используете более старую версию Windows, вы можете использовать Cygwin для получения оболочки Bash .

Откройте свой терминал и перейдите к папке, которую вы хотите использовать в качестве Git-репозитория. Для наших целей, скажем, у нас есть папка с именем «MyNovel» в папке «Документы»

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

Далее перейдите к папке MyNovel в терминале. Чтобы сделать это в Windows 10, команда:

  cd / mnt / c / Users /  / Documents / MyNovel

Любая команда WSL, которая взаимодействует с файлами, сохраненными в Windows, должна использовать

Также обратите внимание, что строчная буква «c» обозначает диск, на котором вы находитесь. Если ваши файлы находятся на диске «D: /», то вы используете

Для macOS и Linux команда намного проще:

  cd ~ / Documents / MyNovel

Отсюда команды одинаковы.

Теперь нам нужно инициализировать папку MyNovel как Git-репозиторий. Эта команда работает, если вы только начинаете новый роман или у вас уже есть некоторые сохраненные файлы внутри.

  мерзавец

Ваша папка теперь является Git-репозиторием. Не веришь мне? Введите это в:

  ls -a

Эта команда просит компьютер перечислить все в текущей папке, включая скрытые элементы

Вы должны увидеть что-то в верхней части под названием «.git» (обратите внимание на точку). В скрытой папке «.git» хранится история версий вашего документа

Вам никогда не нужно открывать это, но оно должно быть там.

Первый коммит

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

Чтобы установить адрес электронной почты и адрес, сделайте следующее:

  git config --global user.email ""

 git config --global user.name ""

Вот и все. Теперь перейдем к первому коммиту.

Давайте предположим, что в папке «MyNovel» есть три документа: «Глава 1», «Глава 2» и «Глава 3». Чтобы сохранить изменения, мы должны указать Git отслеживать эти файлы. Для этого введите:

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

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

Для наших целей постановка не так важна, но может быть полезной. Если вы вносите изменения в Главу 2 и Главу 3, но хотите зафиксировать изменения только в Главе 2, вы должны выполнить Главу 2 следующим образом:

  git add Chapter2.doc

Это говорит Git, что вы хотите подготовить изменения в Главе 2 для фиксации, но не в Главе 3.

Теперь пришло время для первого коммита:

  Git commit -m "Это мой первый коммит".

«-M» называется флагом, и он говорит Git, что вы хотите сделать коммит и прикрепить сообщение, которое вы видите между кавычками. Мне нравится использовать мои коммит-сообщения для отметки количества слов. Я также использую их для записи специальной информации, такой как: «Этот коммит включает интервью с генеральным директором Acme Widgets».

Если я пишу историю, я мог бы включить сообщение, которое гласит: «Этот коммит имеет новую сцену, где собака убегает». Полезные сообщения облегчают поиск ваших коммитов позже.

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

Инструмент 1: Добавление членов команды

Как правило, существует два способа настройки Github для совместной работы:

Организации. Владелец организации может создавать множество команд с разными уровнями доступа для различных репозиториев
Сотрудники. Владелец репозитория может добавлять коллабораторов с доступом Read + Write для одного репозитория

Organizations

Если вы контролируете несколько команд и хотите установить разные уровни доступа для каждой команды с различными членами и добавить каждого участника в разные репозитории, то организация будет для вас наилучшим вариантом. Любая учетная запись пользователя Github уже может создавать бесплатные организации для репозиториев с открытым исходным кодом. Чтобы создать организацию, просто перейдите на страницу настроек своей организации:

Чтобы получить доступ к странице команд для вашей Организации, вы можете просто перейти на , чтобы просмотреть их или даже посетить Для создания новых команд с тремя уровнями доступа, такими как:

Pull Only: выборка и слияние с другим репозиторием или локальной копией. Доступ только для чтения.
Push and Pull: (1) наряду с обновлением удаленного репозитория. Читайте + Запись.
Push, Pull & Administrative: (1), (2) наряду с правами на информацию о выставлении счетов, созданием команд, а также удаление аккаунтов организации. Чтение + запись + доступ администратора

Соавторы

Коллабораторы (соавторы) используются для предоставления возможности «читать + писать» в один репозиторий, принадлежащий личной учетной записи. Чтобы добавить Collaborators (другие личные учетные записи Github), перейдите на страницу :

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

Инструмент 2: Pull Requests

Pull Requests — отличный способ внести свой вклад в репозиторий, сделав его форк. В конце дня, если мы хотим, мы можем отправить pull request владельцу репозитория, чтобы объединить наши изменения кода. Сам pull request может включать обсуждение качества кода, функций или даже общей стратегии.

Давайте теперь рассмотрим основные шаги для pull request.

Инициирование pull request

В Github есть две модели для pull request:

Модель Fork & Pull — используется в общедоступном репозитории, на который у вас нет push-доступа
Share Repository Model — используется в частном репозитории, на который у нас есть push-доступ. В этом случае форк не требуется.

Здесь мы видим рабочий процесс между двумя пользователями ( и ) для модели Fork and Pull:

Определите репозиторий Github, в который вы хотите внести свой вклад, и нажмите кнопку «Fork», чтобы создать клон репозитория в вашей собственной учетной записи Github:
Это создаст точную копию репозитория в вашем собственном аккаунте
Выберите URL-адрес SSH, чтобы он запрашивал вашу парольную кодовую фразу SSH вместо имени пользователя и пароля каждый раз, когда вы делаете или . Затем мы будем клонировать этот репозиторий на наш локальный компьютер:
Как правило, мы создадим новую ветку git для каждой новой задачи. Это хорошая практика, потому что в будущем, если мы продолжим обновление ветки после некоторых обсуждений, запрос на перенос будет автоматически обновляться. Давайте создадим новую ветку, чтобы внести очень простое изменение в файл :
После внесения соответствующих дополнений для создания новых функций мы просто передадим новые изменения и проверку в ветку git master:
На этом этапе мы запушим ветку в удаленный репозиторий. Для этого мы сначала перейдем на ветку с новой задачей, а так же на псевдоним для удаленного репозитория. Затем мы будем пушить изменения с помощью :
На нашей развязанной странице Github репозитория мы перейдем к ветке с новой функцией, а затем нажмите кнопку «Pull Request».
После отправки пул реквеста он напрямую приведет нас к странице запроса в исходном репозитории. Мы увидим наш запрос на pull.
После обсуждения возможно, что владелец форкнутого репозитория может захотеть добавить изменения в новую функцию. В этом случае мы выберем одну и ту же ветку на нашей локальной машине, зафиксируем ее и запушим ее обратно на Github. Когда мы заходим на страницу запроса в оригинальном репозитории, он будет автоматически обновляться!

Слияние пул реквеста

Если вы являетесь владельцем оригинального репозитория, существует два способа слияния входящего пул реквеста:

Слияние непосредственно на Github: если мы делаем слияние непосредственно на Github, то убедитесь, что нет конфликтов, и реквест готов к объединению в ведущую ветку. Владелец оригинального хранилища может просто щелкнуть зеленую кнопку «Слить запрос», чтобы сделать это:
Слияние на наших локальных машинах: в других случаях могут возникнуть конфликты слияния, и после нажатия кнопки «Информация» у Github будут четкие инструкции о том, как мы можем объединить ветвь на нашей локальной машине, потянув за изменения из ветви контрибьютера:

Существуют различные модели создания веток, используемые для управления версиями в командах разработки программного обеспечения. Вот две популярные модели рабочего процесса git: (1) рабочий процесс Github, который имеет простую ветвящуюся модель и использует запросы на pull, и (2) Gitflow, который имеет более обширное разветвление. Модель, которая в конечном итоге будет выбрана, определенно будет меняться в зависимости от команды, проекта и ситуации.

Инструмент 6: Непрерывная интеграция

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

Это определенно уменьшает ошибки интеграции и делает быструю итерацию намного более эффективной. В этом примере мы увидим, как можно использовать Travis CI вместе с Github для CI для обнаружения ошибок, а также для рекомендаций слияния, когда проходят все тесты.

Настройка Travis CI

Мы будем использовать простой проект «hello world» для node.js вместе с grunt.js в качестве инструмента сборки для настройки Travis CI проекта. Вот файлы, находящиеся в проекте:

Файл — это проект nodejs. Здесь мы намеренно не будем оставлять точку с запятой, чтобы грант не смог собрать билд:
определяет зависимости:
Инструмент сборки имеет для простоты только одну задачу (линтинг) :
— это файл конфигурации Travis, который заставит Travis запускать наши тесты:
Затем войдите в Travis со своей учетной записью Github и включите привязку репозитория под вкладкой репозитория.
Если прошлый шагне вызывает сборку, нам придется вручную настроить сервисный хук. Чтобы настроить его вручную, скопируйте токен под вкладкой профиля.
Вернитесь в репозиторий Github, чтобы настроить сервисные хуки Github Travis с помощью токена.
Сначала нам нужно сделать вручную для запуска первой сборки Travis, и если все будет в порядке, просто посетите , чтобы увидеть что сборка прошла!

Travis CI и пул реквесты

Раньше, без какого-либо CI в процессе пул реквеста, этапы выполнялись примерно так: 1) создание запроса (2) слияние (3), тестируем все ли работает. Когда Travis CI подключится к пул реквесам, мы сможем инвертировать шаги 2 и 3, что еще больше ускорит принятие решений о том, следует ли сливать изменения, так как Travis даст нам статус билда для каждого пул реквеста. Давайте посмотрим, как это сделать.

Отправьте пул реквест с успешным билдом, и Travis сделает свою магию, чтобы вы знали, что слияние будет успешным еще даже до самого слияния
Если билд с этим пул реквестом падает, Travis также предупредит вас.
Если мы нажмем на кнопку красного предупреждения, она также будет ссылаться на страницу travis, чтобы показать нам детали сборки.

Travis CI с Github чрезвычайно полезен для команд из-за автоматических сборок и немедленного уведомления. Это, безусловно, делает цикл исправления ошибок намного короче. Если вы используете Jenkins, еще один популярный инструмент CI, то вы тоже можете настроить сервисные хуки Github.

Одиночный разработчик, единственная ветвь

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

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

Это означает, что вы должны совершить, т.е. сделать снимок ваших изменений, когда у вас есть рабочая версия (ну, есть исключения, см. ниже). Чтобы не потерять много работы, вы должны совершать довольно часто, лучше всего (см. Ниже), когда вы завершаете одиночную функцию, отдельную проблему или отдельную часть функции или проблемы.

Вы также хотели бы знать, что вы сделали, и то, над чем вы работали в последнее время. Это означает, что вы должны описывать каждый набор изменений (каждый фиксатор).
Аннотировать файл/просмотр истории. Если у вас нет идеальной памяти, иногда вам нужно знать, почему (и когда, и в случае, когда есть несколько разработчиков, и кто), вы написали заданный набор строк. Комментарии не всегда достаточно. Для этого вы можете использовать (если ваша система управления версиями предоставляет) линейные аннотации истории файлов ( или ) или другие аналогичные инструменты, такие как так называемый поиск “pickaxe” в Git, где вы выполняете поиск/просмотреть историю для коммитов, которые ввели или удалили заданную строку.

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

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

Команда git rm -f

В предыдущем разделе я рассмотрел вариант, когда созданный и проиндексированный файл удаляется из области индексирования “Staging Area”, но остается в области “Working Directory”. Выполняется это с помощью команды .

Логическим продолжением этой команды является та же самая команда , но с ключом — . Такая команда удаляет проиндексированный (но еще не зафиксированный) файл как из области “Staging Area”, так и из области “Working Directory”.

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

Файл удален как из области “Staging Area”, так и из области “Working Directory”. В итоге можно сказать, что между командой и командой практически нет никакой разницы.