Fetch head что это

Fetch head что это

git commit — совершаем commit, сохранение в текущей ветки

git commit

Мы только что внесли изменения в репозиторий и сохранили их как коммит. У коммита, который мы только что сделали, есть родитель, С1, который указывает на предыдущий коммит.

git commit —amend — Изменение последнего коммита

git branch [name] — создание ветки по имени newImage, до этого была ветка master

git branch newImage

Ветка newImage теперь указывает на коммит C1

git commit

git checkout [name] — переключение на ветку newImage и commit ее

git checkout newImage
git commit

git merge [name] — Вот у нас две ветки, каждая содержит по одному уникальному коммиту. Это означает, что ни одна из веток не содержит полный набор «работ», выполненных в этом репозитории. Можно исправить эту ситуацию, выполнив слияние.

Мы сделаем merge ветки bugFix в ветку master

git merge bugFix

Что мы видим? Во-первых, ветка master теперь указывает на коммит, у которого два родителя. Если проследовать по стрелкам от этого коммита, вы пройдёте через каждый коммит в дереве прямиком к началу. Это означает, что теперь в ветке master содержатся все изменения репозитория.

Во-вторых, обрати внимание, как изменились цвета коммитов. Мы ввели цветовую дифференциацию, чтобы помочь пониманию. У каждой ветки — свой цвет. Каждый коммит становится того цвета, какого его ветка. Если в нём изменения сразу двух веток — он становится цветом, смешанным из цветов родительских веток.

И вот мы видим, что цвет ветки master подмешан к каждому коммиту, а ветки bugFix — нет. Это можно поправить.

Смерджим ветку master в ветку bugFix

Git Fetch

One of the reasons Git has become so popular is because it enables teams of any size to collaborate on code. When working with Git, users can Git push changes to a shared copy of their local repository, called a Git remote. New collaborators can pull down these collective changes– the sum of all related Git commits–when they perform a Git clone, but what if someone only wanted to pull down selected changes?

If someone has already cloned a remote but wants to get new changes that others have committed and incorporate those changes into their local repos, they can perform a Git fetch. In this article, we will review the Git fetch command in detail and go over how to perform the action in the command line and GitKraken Client

• What is Git Fetch
• Git Fetch Remote Branch
• Solution to Common Error Message
• Git Fetch in the Command Line
• Git Fetch with GitKraken Client

“@GitKraken makes my life so much easier! Switching between branches, squashing commits, good overview of changes in code and much more. ��” – @@mjovanc

Remote Tracking Branch

Git tracks how far out of sync a local Git branch is from any remote repository through remote tracking branches. Git counts the number of commits ahead or behind that a local repo is from the remote repo based on the contents of the remote tracking branch. Being ahead means there are changes in your local branch that do not exist on the remote. On the other hand, being behind means there are changes on the remote that do not yet exist on the corresponding local branch.

You can see all the remote tracking branches for a repository by performing the following command:
git branch -a

Git is built to work asynchronously, meaning everyone works on a complete copy of the repo on their local machine. Unlike SVN or other version control systems, with Git, there is no central true repository to connect with. Git doesn’t stay connected over the Internet to remote repos and assumes you will manually download the commits from remote servers. At the same time, Git needs to allow a way for you to review those changes in case you don’t want to apply them locally. This is the very nature of Git fetch.

When you perform a Git fetch, all the commits on the remote branch are downloaded to the remote tracking branch first, allowing you to view the contents of the commits before applying the changes to your local branch. You can do this in a couple of different ways.

The first way to view an example of the changes downloaded locally is to Git checkout the remote tracking branch. This will put you in a detached HEAD state, meaning HEAD is not pointed at the end of a local branch. You can see all changes, copy code, or create a new Git branch, all without affecting the local branch.

Another option that will quickly show you what has been changed is running a Git diff, which compares the local branch with the remote tracking branch after you perform a Git fetch. We will show examples of this later in this article with both the command line and with GitKraken Client.

Git FETCH_HEAD

Any time you run a Git init, a ./git folder is created, holding the keys to helping Git do what it’s supposed to do. In each of these folders is a special file called FETCH_HEAD. The FETCH_HEAD file keeps track of all the branches that have been fetched recently, along with the commit SHA for the latest commit that exists on that particular branch on the remote.

This file serves a special function, as it can be used in a Git merge. In this case, Git will resolve the merge request for all branches that are available to be merged in FETCH_HEAD. This happens automatically when a Git pull is performed instead of just a Git fetch.

Git Fetch from Multiple Remotes with FETCH_HEAD

You can reference multiple versions of a branch from multiple remote repos within FETCH_HEAD. By default, running a Git fetch will overwrite the whole FETCH_HEAD file with each run.

However, by using the —append option, or just -a , with Git fetch, Git will instead add those additional fetched branches to the FETCH_HEAD file. Running a git merge FETCH_HEAD will merge all of those commits from the various remotes, all in one step! ��

Keeping track of all the remotes for a repo doesn’t need to be complicated. Download GitKraken Client for free to visualize and better understand your repositories today!

Git Fetch Remote Branch

As you have read, Git fetch is designed to download changes to a remote tracking branch on your local computer. But how does Git fetch know what branch and what remote you intend to download the changes from, especially when more than one remote is available? The best practice is to specify both the remote and the branch we want when you run Git fetch.

If you run git fetch with no other options or subcommands, Git will assume you want to fetch from the default upstream and whichever branch is currently checked out. The default upstream for a branch is normally the first one created, typically the upstream where the code was originally cloned. If you examine the .git/config file, you can quickly see what upstream is associated with each branch.

By declaring specifically which remote and branch you want to target with a Git fetch, you can be certain that you’re getting updated code from the correct source.

If you have a lot of branches and a lot of remotes, you can save a good deal of time by relying on git fetch –all . The —all option tells Git to try and fetch any branch that has changes not present locally from all possible remotes.

error: cannot open .git/FETCH_HEAD permission denied

Sometimes, when you perform a Git fetch or a Git merge against FETCH_HEAD, your CLI shell will return an error that says: error: cannot open .git/FETCH_HEAD permission denied.

There are a number of reasons why this can happen, but most often, it’s because you don’t have the right user permissions to update or access the FETCH_HEAD file.

To solve this error, make sure you’re logged in as a user who has read-write privileges to the Git repository with which you are working. Alternatively, you can modify file permissions to either allow more users access with chmod , or change file ownership to yourself with chown .

How to Git Fetch in the Command Line

Before you perform a Git fetch, it’s a good idea to see which Git remotes are available for repo. To see all available remotes, use the command:

In the above example, there are three available remotes to download changes from: origin , where the repository was originally cloned to the local machine, gitkraken , which is the upstream updated by the owner of the GitLens product, and gitlab , which is a copy of the repo over on GitLab.com.

Using Git Fetch in the CLI

To perform a Git fetch against the branch currently checked out, downloading changes from the default upstream repository, use the command:

In the above example, Git downloaded a change from the remote origin for the branch fetch-example . If there were no changes to download, the Git fetch command would not have produced any output, as there would be nothing to show.

Using Git Fetch Remote Branch in the CLI

To target a specific branch on a specific remote, use the following command:

Make sure you replace with the name of the remote you want and with the desired branch name.

In the above example, the remote is gitlab , and the branch is fetch-example . This command will update the remote tracking branch: gitlab/fetch-example , and update FETCH_HEAD.

Now, you can merge all the changes locally with the following command:

git merge FETCH_HEAD

How to Git Fetch with GitKraken Client

One of the best parts of using GitKraken Client for this action is that the tool automatically performs fetches for you!

Unlike the Git CLI, GitKraken Client can maintain a connection with the various remotes and perform a Git fetch for you in the background as frequently as once per minute. You can see the downloaded changes for the remote tracking branches as entries in the Git commit graph in GitKraken Client, shown below.

To apply the changes to your local repo, simply double-click the remote tracking branch entry on the commit graph you want to apply changes from. GitKraken Client will ask you to confirm that you want to “Reset Local to Here.” Click the Reset Local to Here button, and GitKraken Client will perform the merge.

To adjust the frequency in which GitKraken Client performs automatic fetches, navigate to Preferences → General .
The first option shown is Auto-Fetch Interval . You can adjust this to be as often as every minute, up to every 60 minutes. You can disable the Auto-Fetch feature by setting the frequency to 0 .

GitKraken Client makes it easy to see what is going on in your repository and keep on top of changes from multiple remotes! And features like Auto-Fetch add more convenience and peace of mind than working in the terminal alone.

GitKraken Client…that’s so Fetch

GitKraken Client makes it easy to work with remote repositories, no matter how many other collaborators are updating code. This legendary Git tool makes it much simpler to stay up-to-date with changes with Auto-Fetch capabilities, and seeing code changes is as simple as clicking on a file name on the right panel.

This is just one of the many ways GitKraken Client can make your life better as a developer when collaborating with others. Download and start using GitKraken Client, the legendary cross-platform Git client, today!

3.5 Ветвление в Git — Удалённые ветки

Удалённые ссылки — это ссылки (указатели) в ваших удалённых репозиториях, включая ветки, теги и так далее. Полный список удалённых ссылок можно получить с помощью команды git ls-remote или команды git remote show для получения удалённых веток и дополнительной информации. Тем не менее, более распространённым способом является использование веток слежения.

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

Имена веток слежения имеют вид / . Например, если вы хотите посмотреть, как выглядела ветка master на сервере origin во время последнего соединения с ним, используйте ветку origin/master . Если вы с коллегой работали над одной задачей и он отправил на сервер ветку iss53 , при том что у вас может быть своя локальная ветка iss53 , удалённая ветка будет представлена веткой слежения с именем origin/iss53 .

Возможно, всё это сбивает с толку, поэтому давайте рассмотрим на примере. Скажем, у вас в сети есть свой Git-сервер с адресом git.ourcompany.com . Если вы с него что-то клонируете, команда clone автоматически назовёт его origin , заберёт оттуда все данные, создаст указатель на то, на что там указывает ветка master , и назовёт его локально origin/master . Git также создаст вам локальную ветку master , которая будет начинаться там же, где и ветка master в origin , так что вам будет с чего начать.

Примечание
«origin» — это не специальное название

Подобно названию ветки «master», «origin» не имеет какого-либо специального значения в Git. В то время как «master» — это название по умолчанию для ветки при выполнении git init только потому, что часто используется, «origin» — это название по умолчанию для удалённого сервера, когда вы запускаете git clone . Если вы выполните git clone -o booyah , то по умолчанию ветка слежения будет иметь вид booyah/master .

Рисунок 30. Серверный и локальный репозитории после клонирования

Если вы сделаете что-то в своей локальной ветке master , а тем временем кто-то отправит изменения на сервер git.ourcompany.com и обновит там ветку master , то ваши истории продолжатся по-разному. Пока вы не свяжетесь с сервером origin ваш указатель origin/master останется на месте.

Рисунок 31. Локальная и удалённая работа может расходиться

Для синхронизации ваших изменений с удалённым сервером выполните команду git fetch (в нашем случае git fetch origin ). Эта команда определяет какому серверу соответствует «origin» (в нашем случае это git.ourcompany.com ), извлекает оттуда данные, которых у вас ещё нет, и обновляет локальную базу данных, сдвигая указатель origin/master на новую позицию.

Рисунок 32. git fetch обновляет ветки слежения

Чтобы продемонстрировать, как будут выглядеть удалённые ветки в ситуации с несколькими удалёнными серверами, предположим, что у вас есть ещё один внутренний Git-сервер, который используется для разработки только одной из ваших команд разработчиков. Этот сервер находится на git.team1.ourcompany.com . Вы можете добавить его в качестве новой удалённой ссылки для текущего проекта с помощью команды git remote add , как было описано в главе Основы Git. Назовите этот удалённый сервер teamone — это имя будет сокращением вместо полного URL.

Рисунок 33. Добавление ещё одного сервера в качестве удалённой ветки

Теперь вы можете выполнить команду git fetch teamone для получения всех изменений с сервера teamone , которых у вас нет локально. Так как в данный момент на этом сервере есть только те данные, что содержит сервер origin , Git ничего не получит, но создаст ветку слежения с именем teamone/master , которая будет указывать на тот же коммит, что и ветка master на сервере teamone .

Рисунок 34. Ветка слежения teamone/master

Отправка изменений

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

Если у вас есть ветка serverfix , над которой вы хотите работать с кем-то ещё, вы можете отправить её точно так же, как вы отправляли вашу первую ветку. Выполните команду git push :

$ git push origin serverfix Counting objects: 24, done. Delta compression using up to 8 threads. Compressing objects: 100% (15/15), done. Writing objects: 100% (24/24), 1.91 KiB | 0 bytes/s, done. Total 24 (delta 2), reused 0 (delta 0) To https://github.com/schacon/simplegit * [new branch] serverfix -> serverfix

Это в некотором роде сокращение. Git автоматически разворачивает имя ветки serverfix до refs/heads/serverfix:refs/heads/serverfix , что означает «возьми мою локальную ветку serverfix и обнови ей удалённую ветку serverfix ». Мы подробно рассмотрим часть с refs/heads/ в главе Git изнутри, но обычно её можно пропустить. Вы также можете выполнить git push origin serverfix:serverfix — произойдёт то же самое — здесь говорится «возьми мою ветку serverfix и сделай её удалённой веткой serverfix ». Можно использовать этот формат для отправки локальной ветки в удалённую ветку с другим именем. Если вы не хотите, чтобы на удалённом сервере ветка называлась serverfix , то вместо предыдущей команды выполните git push origin serverfix:awesomebranch , которая отправит локальную ветку serverfix в ветку awesomebranch удалённого репозитория.

Примечание
Не вводите каждый раз свой пароль

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

Если вы не хотите вводить свои данные каждый раз при отправке изменений, вы можете настроить «credential cache». Проще всего держать их в памяти несколько минут, это легко настроить с помощью команды git config —global credential.helper cache .

Для получения более подробной информации о различных вариантах кэша учётных данных обратитесь к разделу Хранилище учётных данных.

В следующий раз, когда один из ваших соавторов будет получать обновления с сервера, он получит ссылку на то, на что указывает serverfix на сервере, как удалённую ветку origin/serverfix :

$ git fetch origin remote: Counting objects: 7, done. remote: Compressing objects: 100% (2/2), done. remote: Total 3 (delta 0), reused 3 (delta 0) Unpacking objects: 100% (3/3), done. From https://github.com/schacon/simplegit * [new branch] serverfix -> origin/serverfix

Необходимо отметить, что при получении данных создаются ветки слежения, вы не получаете автоматически для них локальных редактируемых копий. Другими словами, в нашем случае вы не получите новую ветку serverfix — только указатель origin/serverfix , который вы не можете изменять.

Чтобы слить эти наработки в свою текущую рабочую ветку, выполните git merge origin/serverfix . Если вам нужна локальная ветка serverfix , в которой вы сможете работать, то вы можете создать её на основе ветки слежения:

$ git checkout -b serverfix origin/serverfix Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix'

Это даст вам локальную ветку, в которой можно работать и которая будет начинаться там же, где и origin/serverfix .

Отслеживание веток

Получение локальной ветки из удалённой ветки автоматически создаёт то, что называется «веткой слежения» (а ветка, за которой следит локальная называется «upstream branch»). Ветки слежения — это локальные ветки, которые напрямую связаны с удалённой веткой. Если, находясь на ветке слежения, выполнить git pull , то Git уже будет знать с какого сервера получать данные и какую ветку использовать для слияния.

При клонировании репозитория, как правило, автоматически создаётся ветка master , которая следит за origin/master . Однако, при желании вы можете настроить отслеживание и других веток — следить за ветками на других серверах или отключить слежение за веткой master . Вы только что видели простейший пример, что сделать это можно с помощью команды git checkout -b / . Это часто используемая команда, поэтому Git предоставляет сокращённую форму записи в виде флага —track :

$ git checkout --track origin/serverfix Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix'

В действительности, это настолько распространённая команда, что существует сокращение для этого сокращения. Если вы пытаетесь извлечь ветку, которая не существует, но существует только одна удалённая ветка с точно таким же именем, то Git автоматически создаст ветку слежения:

$ git checkout serverfix Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix'

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

$ git checkout -b sf origin/serverfix Branch sf set up to track remote branch serverfix from origin. Switched to a new branch 'sf'

Теперь ваша локальная ветка sf будет автоматически получать изменения из origin/serverfix .

Если у вас уже есть локальная ветка и вы хотите настроить её на слежение за удалённой веткой, которую вы только что получили, или хотите изменить используемую upstream-ветку, то воспользуйтесь параметрами -u или —set-upstream-to для команды git branch , чтобы явно установить новое значение.

$ git branch -u origin/serverfix Branch serverfix set up to track remote branch serverfix from origin.

Примечание
Сокращение Upstream

Если у вас настроена отслеживаемая ветка, вы можете ссылаться на неё с помощью сокращений @ или @ . Итак, если вы находитесь на ветке master и она следит за origin/master , при желании вы можете использовать git merge @ вместо git merge origin/master .

Если вы хотите посмотреть как у вас настроены ветки слежения, воспользуйтесь опцией -vv для команды git branch . Это выведет список локальных веток и дополнительную информацию о том, какая из веток отслеживается, отстаёт, опережает или всё сразу относительно отслеживаемой.

$ git branch -vv iss53 7e424c3 [origin/iss53: ahead 2] Add forgotten brackets master 1ae2a45 [origin/master] Deploy index fix * serverfix f8674d9 [teamone/server-fix-good: ahead 3, behind 1] This should do it testing 5ea463a Try something new

Итак, здесь мы видим, что наша ветка iss53 следит за origin/iss53 и «опережает» её на два изменения — это значит, что у нас есть два локальных коммита, которые не отправлены на сервер. Мы также видим, что наша ветка master отслеживает ветку origin/master и находится в актуальном состоянии. Далее мы можем видеть, что локальная ветка serverfix следит за веткой server-fix-good на сервере teamone , опережает её на три коммита и отстает на один — это значит, что на сервере есть один коммит, который мы ещё не слили, и три локальных коммита, которые ещё не отправлены на сервер. В конце мы видим, что наша ветка testing не отслеживает удалённую ветку.

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

$ git fetch --all; git branch -vv

Получение изменений

Команда git fetch получает с сервера все изменения, которых у вас ещё нет, но не будет изменять состояние вашей рабочей копии. Эта команда просто получает данные и позволяет вам самостоятельно сделать слияние. Тем не менее, существует команда git pull , которая в большинстве случаев является командой git fetch , за которой непосредственно следует команда git merge . Если у вас настроена ветка слежения как показано в предыдущем разделе, или она явно установлена, или она была создана автоматически командами clone или checkout , git pull определит сервер и ветку, за которыми следит ваша текущая ветка, получит данные с этого сервера и затем попытается слить удалённую ветку.

Обычно, лучше явно использовать команды fetch и merge , поскольку магия git pull может часто сбивать с толку.

Удаление веток на удалённом сервере

Скажем, вы и ваши соавторы закончили с нововведением и слили его в ветку master на удалённом сервере (или в какую-то другую ветку, где хранится стабильный код). Вы можете удалить ветку на удалённом сервере используя параметр —delete для команды git push . Для удаления ветки serverfix на сервере, выполните следующую команду:

$ git push origin --delete serverfix To https://github.com/schacon/simplegit - [deleted] serverfix

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

Объяснение полезных 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 туда, где он был.

Как мы видим, последнее действие было перенесено в рефлог.