Объяснение полезных Git команд с помощью визуализации
Это перевод замечательной статьи Лидии Холли, где она объясняет основные гит команды в очень понятном виде с помощью визуализаций. Начнем Хотя Git является очень мощным инструментом, я думаю, что большинство людей согласятся, когда я скажу, работа с ним может быть так же полной неразберихой �� Мне всегда было очень полезно визуализировать в своей голове, что происходит при работе с Git: как ветки, взаимодействующие, когда я выполняю определенную команду, и как это повлияет на историю? Почему мой коллега заплакал, когда я сделала hard reset на master , сделав force push к origin и rimraf нула .git папку? Я подумала, что это будет идеальный вариант для создания наглядных примеров наиболее распространенных и полезных команд! Многие из описываемых мной команд имеют необязательные аргументы, которые вы можете использовать для изменения их поведения. В моих примерах я расскажу о поведении команд по умолчанию, не добавляя (слишком много) параметров конфигурации! ��
Merge
Наличие нескольких веток чрезвычайно удобно для того, чтобы новые изменения были отделены друг от друга, а также чтобы вы случайно не запушили несанкционированные или поврежденные изменения в продакшин. Как только изменения будут одобрены, мы хотим получить эти изменения в нашей прод ветке! Один из способов получить изменения из одной ветки в другую — выполнить git merge ! Есть два типа менж команд, которые может выполнять Git: fast-forward или no-fast-forward ��
Fast-forward ( —ff )
Fast-forward merge когда текущая ветка не имеет дополнительных коммитов по сравнению с веткой, которую мы мержим. Git у нас ленив и сначала попытается выполнить самый простой вариант: Fast-forward! Этот тип менжа не создает новый коммит, а скорее объединяет коммит(ы) в ветку, которую мы объединяем прямо в текущей ветке Отлично! Теперь у нас есть все изменения, которые были сделаны в ветке dev , в ветке master . Итак, что же такое no-fast-forward?
No-fast-foward ( —no-ff )
Хорошо, если ваша текущая ветка не имеет каких-либо дополнительных коммитов по сравнению с веткой, которую вы хотите смержить, но, к сожалению, это случается редко! Если мы зафиксировали изменения в текущей ветке, которых нет в ветке, которую мы хотим объединить, git выполнит объединение без fast-forward merge. При слиянии без fast-forward Git создает новый коммит мержа в активную ветку. Родительский коммит указывает на активную ветку и ветку, которую мы хотим объединить!
Merge конфликты
Хотя Git хорошо решает, как объединять ветки и добавлять изменения в файлы, он не всегда может принять это решение сам по себе. Это может произойти, когда две ветки, которые мы пытаемся смержить, имеют изменения в одной строке в одном и том же файле, или если одна ветка удалила файл, который изменила другая ветка, и так далее. В этом случае Git попросит вас помочь решить, какой из двух вариантов мы хотим сохранить. Допустим, что в обеих ветках мы отредактировали первую строку в файле README.md. Если мы хотим смержить dev в master , это приведет к конфликту: хотите, чтобы заголовок был Hello! или hey!? При попытке объединить ветки, Git покажет вам, где происходит конфликт. Мы можем вручную удалить изменения, которые не хотим сохранять, сохранить изменения, снова добавить файл и закоммитить изменения.
Rebase
Мы только что увидели, как можно применить изменения из одной ветки в другую, выполнив git merge . Другой способ добавить изменения из одной ветки в другую — выполнить git rebase . Git rebase копирует коммиты из текущей ветки и помещает эти скопированные коммиты поверх указанной ветки. Отлично, теперь у нас есть все изменения, которые были сделаны в master ветке и в dev ветке. �� Большая разница по сравнению с мержем заключается в том, что Git не будет пытаться выяснить, какие файлы сохранить и не сохранить. В ветке, которую мы обновляем, всегда есть последние изменения, которые мы хотим сохранить! Таким образом, вы не столкнетесь ни с какими мерж конфликтами и у вас будет хорошая линейная история. Этот пример показывает rebase в master ветке. Однако в больших проектах вы обычно не захотите этого делать. Git rebase изменяет историю проекта, поскольку для скопированных коммитов создаются новые хэши. Rebase отлично подходит, когда вы работаете над feature branch, а master ветка была обновлена. Вы можете получить все обновления в своей ветке, которые предотвратят будущие merge конфликты ��
Interactive Rebase
- reword : Изменить коммит меседж
- edit : Изменить коммит
- squash : Объеденить коммит в предыдущий коммит
- fixup : Объединить коммит с предыдущим коммитом, не сохраняя commit’s log message
- exec : Запустить команду для каждого коммита, который мы хотим rebase
- drop : Удалить коммит
Таким образом, мы можем иметь полный контроль над нашими коммитами. Если мы хотим удалить коммит, мы можем просто drop’нуть его.
Или, если мы хотим объединить несколько коммитов вместе, чтобы получить более чистую историю, нет проблем!
Interactive rebasing дает вам большой контроль над коммитами, которые вы пытаетесь rebase’нуть, даже в текущей активной ветке.
Reset
Может случиться так, что мы допустили изменения, которые мы не хотели заливать. Может быть, это коммит еще в работе или коммит, в котором есть ошибки! �� В этом случае мы можем выполнить git reset .
git reset избавляет от всех текущих промежуточных файлов и дает нам контроль над тем, куда должен указывать HEAD.
Soft reset
Soft reset перемещает HEAD к указанному коммиту (или индексу коммита по сравнению с HEAD), не избавляясь от изменений, которые были внесены в коммиты позже.
Допустим, мы не хотим сохранять коммит 9e78i , в который был добавлен файл style.css , и мы также не хотим сохранять коммит 035cc , в который был добавлен файл index.js . Однако мы хотим сохранить недавно добавленные файлы style.css и index.js. Идеальный кейс для sort reset.
Набрав git status, вы увидите, что у нас все еще есть доступ ко всем изменениям, которые были сделаны во время предыдущих коммитов. Это здорово, так как это означает, что мы можем исправить содержимое этих файлов и закоммитить их позже.
Hard reset
Иногда мы не хотим сохранять изменения, внесенные некоторыми коммитами. В отличие от soft reset, нам не нужно больше иметь к ним доступ. Git должен просто сбросить свое состояние обратно туда, где он был в указанном коммите: это даже включает изменения в вашей working directory и stage файлах! ��
Git отменил изменения, которые были внесены в 9e78i и 035cc, и сбросил свое состояние до того, где он был при коммите ec5be.
Revert
Другой способ отменить изменения — выполнить git revert . Отменяя определенный коммит, мы создаем новый коммит, который содержит отмененные изменения.
Допустим, ec5be добавил файл index.js . Позже мы на самом деле понимаем, что больше не хотим, чтобы это изменения были в ветке! Давайте ревертнем коммит ec5be .
Cherry-pick
Когда определенная ветка содержит коммит, который внес изменения, которые нам нужны в нашей активной ветке, мы можем черипинуть коммит в нашу ветку. Cherry-pick создает новый коммит в нашей активной ветке, который содержит изменения, которые были в чери-пикнутом коммите.
Предположим, что коммит 76d12 в ветке dev добавил изменение в файл index.js , которое мы хотим добавить в master:
Fetch
Если у нас есть remote Git ветка, например ветка на Github, может случиться так, что remote ветка имеет коммиты, которых нет у текущей ветки! Возможно, другая ветка была объединена, или ваш коллега добавил hot fix и так далее.
Мы можем получить эти изменения локально, выполнив git fetch на remote ветке. Это никак не влияет на вашу локальную ветку: fetch просто загружает новые данные.
Pull
Хотя git fetch очень полезен для получения remote информации о ветке, мы также можем выполнить git pull . Git pull — это две команды в одной: git fetch и git merge . Когда мы извлекаем изменения из origin, мы сначала fetch’им все данные, как мы делали с помощью git fetch, после чего последние изменения автоматически мержатся в локальную ветку.
Reflog
Все делают ошибки, и это совершенно нормально! Иногда может показаться, что вы испортили свой репозиторий Git настолько сильно, что просто хотите полностью его удалить.
git reflog — очень полезная команда для отображения журнала всех выполненных действий! Это включает в себя слияния, перезагрузки, возвраты: в основном, любые изменения в вашей ветке.
Если вы допустили ошибку, вы можете легко отменить ее, сбросив HEAD на основе информации, которую нам предоставляет reflog.
Скажем, мы на самом деле не хотели мержить origin ветку. Когда мы выполняем команду git reflog , мы видим, что состояние репозитория до мержа- HEAD@ . Давайте выполним git reset , чтобы указать HEAD туда, где он был.
Как мы видим, последнее действие было перенесено в рефлог.
Режим fast-forward в Git
Оригинал данного вольного перевода размещен здесь — Fast-Forward Git Merge. Статья довольно свежая — от 20.09.2013. Почему перевод статьи? Потому что на русском ничего не нашел (окромя книги официальной).
merge
speedup
master
$ git checkout -b speedupcommit
speedup
push
master
speedup
git fetch
git merge
master
speedup
master
speedup
master
-no-ff
git merge
master
speedup
master
speedup
В ситуациях подобного рода система Git всегда старается применить режим fast-forward, если это возможно. Однако, такое поведение Git можно легко изменить на режим no fast-forward и сделать его поведением системы по умолчанию.
merge
merge
-no-ff
pull request
merge
Если в нескольких словвах подвести общий итог вышесказанного, то он окажется следующим.
Режим no fast-forward хранит всю информацию о слияниях веток. Такой подход может оказаться запутанным и сложным, если необходимо прочитать историю коммитов.
С другой стороны, режим fast-forward хранит не всю информацию о слияниях веток. Такой подход более простой для чтения, но в этом случае становится неочевидным история веток проекта.
Jest — использование skip
В Karma\Jasmine есть варианы для игнорирования выборочных тестов — xit, xdescribe. В этом посте — разберусь, какие есть варианты для этог. … Continue reading
What Is a Git Merge Fast Forward?
A Git fast forward is an extremely useful and efficient mechanism for harmonizing your project’s main branch with changes introduced in a given feature branch. Git makes ample use of fast-forwarding merges behind the scenes, speeding up your development workflow in the process.
Fast-forward merges can help keep your commit history clean and readable without erasing important information. In fact, many developers intentionally maintain their projects’ repositories with this in mind, favoring fast-forward merges for their convenience and readability. However, it helps to know when a Git merge fast forward can and should be used to make the most of it.
What happens when you merge
Git does a number of things to ensure your project’s history is maintained whenever commits from separate branches are merged back in. In the event that there are conflicts of any kind between the new code being merged in and the existing code in the main branch, Git will request that someone intervene to resolve them. Assuming there are no conflicts in need of human intervention, Git will find the most efficient way to put your code together on its own. However, depending on your project’s organizational needs, it may make sense to take control of this process on a deeper level. To make a more informed decision, it helps to know how Git’s two different types of merges work and when they’re best used.
How Git handles three-way merges
A three-way merge with Git makes it possible for project branches to be rejoined with the main history even when both of these have been altered. This is achieved by pulling three separate versions of your code together—the current main branch, your commits to be merged, and a common ancestor of the two. With all three of these in memory, Git then determines whether their differences can safely coexist or need to be resolved by a member of your team first.
Three-way merges are a great way for you to keep track of important feature additions and development milestones in your project as they leave a visible merge commit in place when they’re used. However, they are not always so useful, especially if your project has a vast assortment of small commits happening at any given time that you’re not interested in recording.
For instance, bug fixes and other minor alterations to your project’s code can quickly clutter up its history with an ever-expanding list of merge commits. Most of these commits don’t need to be tracked in this way and can instead be merged using Git’s fast-forward merge algorithm.
How a Git merge fast forward happens
When Git detects that your commit is about to be merged into your project’s main branch without the main branch having been modified since your feature branch was first made, it chooses to use a fast-forward merge instead of a three-way merge. Fast-forward merges literally move your main branch’s tip forward to the end of your feature branch. This keeps all commits created in your feature branch sequential while integrating it neatly back into your main branch.
How to fast-forward merge with Git
You can fast-forward merge Git without explicitly telling it to do so by ensuring no new changes have been performed on your main branch since your feature branch was first generated. Of course, this is not always a possibility with fast-moving projects being worked on by large, distributed teams. Instead, you can take advantage of rebasing operations to ensure your next commit can be completed with a clean fast forward.
If you really don’t want anything else than a fast-forward merge, you can pass the —ff-only option to git merge . Git will abort the merge if a fast-foward is impossible.
Rebasing to perform a fast-forward merge on Git
Rebasing can be used to create a merge fast forward on Git thanks to its ability to make both the master branch and your feature branch’s history (besides the new feature branch changes) identical. By rebasing, you are effectively copying all of the changes that have taken place on th3e main branch while you were busy working on your feature branch. Once these are the same and you’re sure your code still works, you can merge with the master branch without triggering a three-way merge operation. Git will move the tip of the master branch up to the tip of your feature branch with a Git fast forward instead of searching for a common ancestor.
If you’re using GitHub and want to rebase your pull request without doing anything, you can leverage Mergify rebase command:
You can use Mergify to implement any type of Git history. It can be used to rebase before merging and assure you always do fast-forward merge.
Make merging simpler with Mergify
Mergify can help your team tackle the complexities of merging so they can spend more time coding.
From queueing up merge operations to assigning reviewers, labeling, and more, Mergify helps make sense of your team’s workflow by automating the redundant bits.
Automation with Mergify reduces the potential for errors to eat away at your team’s productivity and profitability. Learn more about Mergify and how we can help with a quick demo today.