Knowledge Transfer
Ethickfox kb page with all notes
Project maintained by ethickfox Hosted on GitHub Pages — Theme by mattgraham
Системы контроля версий
Подходы
Git Flow
Легко управлять каждой фазой разработки, лучше использовать, когда есть концепция выпуска ПО(нет непрерывного развертывания)
GitFlow у вас есть дополнительная ветвь develop куда сливаются все разрабатываемые в текущий момент ветви. develop необходимо "стабилизировать" перед релизом, что часто приводит либо к переносу релиза, либо "релизу с замечаниями".
Основные ветки:
- master
- develop
- features
- hotfix
- release
Github Flow
Удобнее для среды постоянного развертывания, где нет понятия выпуск. Каждый раз при реализации новой функции они выпускают ее в продакшн. Для работы используются следующие концепции:
Все что в мастере - уже рабочее
После мерджа изменений в мастер, оно должно быть задеплоено
Forking Workflow
Fork the official repository to create a copy of it on the server. This new copy serves as their personal public repository—no other developers are allowed to push to it, but they can pull changes from it (we’ll see why this is important in a moment). When they're ready to publish a local commit, they push the commit to their own public repository—not the official one. Then, they file a pull request with the main repository, which lets the project maintainer know that an update is ready to be integrated. The pull request also serves as a convenient discussion thread if there are issues with the contributed code. The following is a step-by-step example of this workflow.
- A developer 'forks' an 'official' server-side repository. This creates their own server-side copy.
- The new server-side copy is cloned to their local system.
- A Git remote path for the 'official' repository is added to the local clone.
- A new local feature branch is created.
- The developer makes changes on the new branch.
- New commits are created for the changes.
- The branch gets pushed to the developer's own server-side copy.
- The developer opens a pull request from the new branch to the 'official' repository.
- The pull request gets approved for merge and is merged into the original server-side repository
https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow
GIT
Коммит
Элемент односвязного списка, состоящий из объектов с измененными файлами и ссылки на предыдущий коммит. При создании коммита, указатель ветки автоматически сдвигается на него.
Ветка
Перемещаемый указатель на один из коммитов
HEAD
Указатель на текущую ветку
Index(Staging area)
Промежуточная область, в которой хранятся изменения файлов на пути от рабочей директории до репозитория. При выполнении коммита, в него попадают только те изменения, которые были в индексе. git add - добавляет в индекс.
Хранение изменений
При каждом коммите все измененные файлы сохраняются целиком в виде blob объектов(заархивированных), которые адресуются с помощью 40 значного SHA1 хэша
Все эти объекты разбиваются на директории с помощью объектов
tree
Содержимое: 100644 blob 3f4e21ab1d7b52e033f1d1c562e5dd51c629cf35 test.cmd
Далее на все это указывает commit
Содержимое:tree dc786d4599af5a03af1acceebf32bfc206983f49
parent 15e9273774286e8acf47337ab732bdb915fe3596
author ethickfox ethickfox@gmail.com 1635023230 +0300
committer ethickfox ethickfox@gmail.com 1635023230 +0300
New br commit
Коммиты содержат
- Ссылку на дерево с изменениями
- Предыдущий коммит
- Автор коммита
- Комментарий
Чтобы все это не занимало очень много места, старые коммиты собираются в один большой архив
git fetch
Связывается с удаленным репозиторием и получает данные, которые отсутствуют в локальном(Не обновляет, просто подтягивает изменения)
git pull
Загружает изменения с сервера и автоматически делает слияние с кодом текущей ветки
git checkout
Извлекает содержимое из репозитория и помещает его в рабочее дерево. Можно перемещаться по коммитам, не вносит изменений в историю.
Объединение коммитов
С помощью перебазировании в интерактивном режиме. git rebase -i HEAD~5. Далее перед выбранными коммитами ставим squash
git rebase
Все изменения из целевой ветки применяются поверх изменений из внедряемой. Номера коммитов целевой ветки изменятся
/o-----o---o--o-----o--------- branch
- -o-o--A--o---o---o---o----o--o-o-o--- master
git checkout branch
git rebase master
/o-----o---o--o-----o------ branch
- -o-o--A--o---o---o---o----o--o-o-o master
Также существует интерактивная версия. Она позволяет выполнить следующие действия с перебазируемыми коммитами:
- p, pick - использовать коммит
- r, reword - использовать + изменить сообщение
- e, edit - использовать + остановить ребейз и исправить коммит
- s, squash - объединить с предыдущим коммитом
- f, fixup - squash, только с обнулением сообщения
- x, exec - выполнить shell команду
- b, break - остановка ребейза
- d, drop - убрать коммит
- l, label
- t, reset
- m, merge
git merge
Создается новый коммит в целевой ветке, который содержит изменения из внедряемой. A commit, that combines all changes of a different branch into the current.
Также существует fast-forward merge, который не создает новых коммитов, а просто объединяет коммиты в одну ветку, передвигая указатель. Re-comitting all commits of the current branch onto a different base commit.
git merge vs rebase
- merge создаёт коммит слияния (создаёт/загрязняет историю). и можно продолжить работать в двух ветках - и старой и новой. Сохраняет полную историю и хронологический порядок;
- А rebase меняет свою историю.Упрощает сложную историю, можно очистить промежуточные коммиты и сделать их одним.
- rebase более функциональный, но им проще все сломать
- Rebase не изменяет целевую ветку, он «переигрывает» изменения из текущей ветки на вершине целевой ветки, оставаясь в текущей ветке. Для интеграции изменений вам все равно придется сделать merge. Однако поскольку в целевой ветке более не будет изменений, сделанных после точки отбранчевания, мердж будет проведен как fast forward, что означает перенесение маркера вершины целевой ветки на конец текущей ветки без merge-комита.
- merge executes only one new commit. rebase typically executes multiple (number of commits in current branch).
- merge produces a new generated commit (the so called merge-commit). rebase only moves existing commits.
- Use merge whenever you want to add changes of a branched out branch back into the base branch. Typically, you do this by clicking the "Merge" button on Pull/Merge Requests, e.g. on GitHub.
- Use rebase whenever you want to add changes of a base branch back to a branched out branch.Typically, you do this in feature branches whenever there's a change in the main branch.
- If the rebased branch has multiple commits that change the same line and that line was also changed in the base branch, you might need to solve merge conflicts for that same line multiple times, which you never need to do when merging. So, on average, there's more merge conflicts to solve.
| Merge | Rebase |
| Git merge is a command that allows you to merge branches from Git. | Git rebase is a command that allows developers to integrate changes from one branch to another. |
| In Git Merge logs will be showing the complete history of the merging of commits. | Logs are linear in Git rebase as the commits are rebased |
| All the commits on the feature branch will be combined as a single commit in the master branch. | All the commits will be rebased and the same number of commits will be added to the master branch. |
| Git Merge is used when the target branch is shared branch | Git Rebase should be used when the target branch is private branch |
Why not use merge to merge changes from the base branch into a feature branch?
- The git history will include many unnecessary merge commits. If multiple merges were needed in a feature branch, then the feature branch might even hold more merge commits than actual commits!
- This creates a loop which destroys the mental model that Git was designed by which causes troubles in any visualization of the Git history.Imagine there's a river (e.g. the "Nile"). Water is flowing in one direction (direction of time in Git history). Now and then, imagine there's a branch to that river and suppose most of those branches merge back into the river. That's what the flow of a river might look like naturally. It makes sense.But then imagine there's a small branch of that river. Then, for some reason, the river merges into the branch and the branch continues from there. The river has now technically disappeared, it's now in the branch. But then, somehow magically, that branch is merged back into the river. Which river you ask? I don't know. The river should actually be in the branch now, but somehow it still continues to exist and I can merge the branch back into the river. So, the river is in the river. Kind of doesn't make sense.This is exactly what happens when you merge the base branch into a feature branch and then when the feature branch is done, you merge that back into the base branch again. The mental model is broken. And because of that, you end up with a branch visualization that's not very helpful.
git cherry-pick
Взять отдельный коммит из другой ветки и перенести его на Head текущей
git reset
Перемещает выбранный коммит на вершину, стирая изменения
- soft - все изменения остаются подготовленными к коммиту
- mixed -текущие изменения сохранены, но не находятся в индексе, в контроле версий последним отображается выбранный коммит.
- hard - удаляет все, что было сделано после выбранного коммита
git revert
Создает новый коммит с отменой изменений.
Мердж конфликты
Возникают при наличии изменений в одном месте у обоих сливаемых веток. При таком конфликте гит помечает, откуда какая часть кода была получена. Необходимо вручную внести изменения в файл и сделать коммит решения конфликта