Статьи

7 простых хитростей, чтобы стать мастером Git

Сентябрь 11, 2017

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

Это резюме моего выступления на Tech Days Sweden 2015. Объяснения здесь очень кратки, если вы хотите, чтобы я объяснил что-то из этого более подробно в отдельном посте, пожалуйста, оставьте комментарий.

Несколько пультов

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

  • происхождение  ваша собственная вилка.
  • апстрим  — это оригинальное репо, которое вы разветвили

Когда я клонировал AuthServices, я клонирую разветвление, а затем добавляю оригинал в качестве удаленного. Наконец, я настроил свою локальную  master ветку, чтобы отслеживать  upstream/master не обновляющиеся  master в моем форке.

git clone https://github.com/AndersAbel/AuthServices</li>
cd AuthServices
git remote add upstream https://github.com/KentorIT/AuthServices</li>
git branch -u upstream/master

Интеграция Azure с GitHub потрясающая. Просто внесите изменения в GitHub, и он появится в Azure через несколько секунд. Это здорово — пока не пойдет не так, и все это черная магия, которую невозможно отладить. Однако есть простое решение, вместо того, чтобы вносить изменения в GitHub — перенести его непосредственно в Azure. Это покажет фактический результат сборки в консоли git.

$ git remote add azure https://tdswe15.scm.azurewebsites.net/TDSwe15.git
$ git push azure master
Counting objects: 1, done.
Writing objects: 100% (1/1), 173 bytes | 0 bytes/s, done.
Total 1 (delta 0), reused 0 (delta 0)
remote: Updating branch 'master'.
remote: Updating submodules.
remote: Preparing deployment for commit id 'cb26b193bd'.
remote: Generating deployment script.
remote: Running deployment command...
remote: Handling .NET Web Application deployment.
remote: All packages listed in packages.config are already installed.
remote:   TDSwe15 -> D:\home\site\repository\TDSwe15\bin\TDSwe15.dll
remote:   Transformed Web.config using D:\home\site\repository\TDSwe15\Web.Release.config into obj\Release\TransformWebConfig\transformed\Web.config.
remote:   Copying all files to temporary location below for package/publish:
remote:   D:\local\Temp\8d2d9734c47b075.
remote: ..
remote: KuduSync.NET from: 'D:\local\Temp\8d2d9734c47b075' to: 'D:\home\site\wwwroot'
remote: Finished successfully.
remote: Deployment successful.
To https://tdswe15.scm.azurewebsites.net/TdSwe15.git
   5a9f3ca..cb26b19  master -> master

Только совершить некоторые изменения

Я объяснил большую часть этого ранее в  Частичном комитете с  постом Git .

Что еще добавлено, так это то, что в сеансе, который я также показал, можно  git add -p размещать только части изменений одного файла.

Перебазировать, чтобы скрыть ошибки

Если есть ошибка 3 коммитов назад, ее можно скрыть с помощью rebase.

  1. Сделайте новый коммит, исправив ошибку. Сообщение фиксации не имеет значения, так как оно будет потеряно позже.
  2. Используйте,  git rebase -i HEAD~4 чтобы вызвать редактор с коммитами.
  3. Переместите фиксацию исправления (созданную на шаге 1) сразу под коммитом, который привел к ошибке, и измените префикс с  pick на  fixup.
  4. Сохраните файл и выйдите.

Cherry-pick, чтобы разбить коммит на отдельную ветку

Если в ветви была сделана несвязанная фиксация, ее можно переместить в отдельную ветку.

  1. Проверьте  master или любую другую ветку, с которой вы хотите начать новую.
  2. Используйте  git checkout -b MyNewBranch для создания новой ветви.
  3. Получите коммит,  git cherry-pick XYZ где XYZ — это хеш коммита, который вы хотите получить в новой ветке.
  4. Повторите, если у вас есть еще коммиты для добавления в новую ветку.

Теперь новая ветка создана. Чтобы завершить, оскорбительный коммит должен быть опущен в исходной ветке. Это делается с помощью перебазирования, как показано выше, но вместо перемещения коммита — просто удалите (или закомментируйте) строку с коммитом.

Простой запрос на выгрузку

В  .git/config файле в репозитории найдите раздел для пульта, который содержит запросы извлечения (вероятно, с именем upstream, если вы следовали моему совету выше). Добавьте строку для получения запросов на получение. Теперь раздел должен выглядеть так:

[remote "upstream"]
  url = https://github.com/KentorIT/authservices
  fetch = +refs/heads/*:refs/remotes/upstream/*
  fetch = +refs/pull/*/head:refs/remotes/upstream/pr/*

Теперь  git fetch будет сбрасывать все запросы тянуть. Их можно проверить с помощью  git checkout pr/42.

Слияние,  --no-ff чтобы сохранить структуру ветвления при слиянии

При объединении ветки используйте  --no-ff опцию, чтобы git не выполнял ускоренную перемотку вперед. При ускоренной перемотке вперед невозможно увидеть, что происходит, когда идет работа над веткой функций. Если есть такие коммиты, может быть полезно сохранить их, но сохранить их как отдельный трек в графе ревизий. Это делается путем добавления  --no-ff переключателя в команду слияния.

Используйте Git Reflog, чтобы вернуться

Легко заблудиться и ошибиться. Плохо, когда по ошибке  git reset --hard получается ветка с потерянным ценным кодом. Использование  git reflog покажет, как  HEAD были перемещены в различные коммиты. В списке можно найти хеш важной (и теперь потерянной) ветви.

Компактная, но подробная версия графика

Чтобы получить компактный, но подробный график версий в консоли, я использую псевдоним  git lg.
ГИТ-Л.Г.

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

$ git config --add --global alias.lg "log --all --graph --pretty='%h %C(cyan)%cd %C(auto)%d %C(bold yellow)%an%n%C(reset)%<(139,trunc)%s%n'"

38
Share: