Cherry pick android studio

Using git from Android Studio. A quick guide.

We all know how important version control is. One can save a lot of time in case conflicts occur or things go really bad. But we can still argue which tool is the best for using Git. That’s because Git in general is abstract, and visualizing it is somehow hard, as this also needs to go along with everyone’s head. I would not blame anyone if they fantasize git differently in their heads, and then argue about the tool. In my opinion, everyone has the right to argue on toolings just because of that.

What are some of the preferences though?

Here I am listing only the tools that I have experience with.

Terminal

Sometimes I try to keep it very conservative. I just use the terminal. It’s over there, right below my IDE and I am the laziest person ever lived. The commands are usually muscle memory, even though I have to write something like this:

And it is still easier than using any tool. The reason for just using the terminal is actually very logical for me: Different companies, use different tools. If one doesn’t know how to use git in the terminal, switching tools would be the hardest thing ever. Also, the terminal takes changes with the branch once you checkout in a new one, and that would be a huge red flag. Git visualization tools forbid such things.

Sourcetree.

Another option for me has been Sourcetree. During merges or rebases, I do not feel comfortable with the terminal, especially when it brings me a file to edit after doing git merge
. Therefore Sourcetree has been my number one solution for merging, rebasing branches as well as cherry-pick-ing and tagging commits. The UI is very friendly. However Sourcetree has problems sometimes positioning the view in the right commit after switching a branch, and it looks very laggy.

Android Studio

Being an Android Developer, I do not feel well about the fact that I have always ignored this section in the IDE:

Therefore, I thought I should give it a try. I closed Sourcetree and then I started working with Android Studio. I can definitely say that the one and only issue I faced was the word Update which in this case stands for Pull (from remote). And that actually got me thinking: Isn’t that even more accurate? Since this debate between Pull and Merge as terms would never be resolved, why not actually separate them as concepts completely? Update would be the new pull and merge would continue to be merge. Even with introducing this word though, the debate still stands. However, the most important part would be to know what you are doing.

Let’s start with Commits

Usually Android Studio tends to git add files by default. Just be careful when creating new files, or deleting and reverting them. So let’s commit one file from Android Studio. The project is in Flutter, but it is sufficient for the example.

Cherry-pick/Patches and commits

In case you need changes from only one commit, the Android Studio visualization is not different from most of the other Git clients over there. Just right-click to any of the commits you would like to work with and all the options you need would be there:

Applying patches is one of the coolest things from Android Studio. You can immediately apply a patch from the clipboard.

In case what is copied on the clipboard is not a git patch, you won’t be able to paste.

Reverting small/big changes

Sometimes you get lost with just one method. And you just want to revert it and start from the beginning. This is very user-friendly from Android Studio. Just click the highlighted bar on the left, close to the numbers that count the lines of code and that would be it:

But sometimes you just do not want to revert, but at the moment you want to see how it is in the base branch and compare it with your work.

It is pretty helpful.

Pulling/Updating or just merging remote into yours

The whole git section can be found by default in the down toolbar of the IDE, however, you can easily move it to whichever place you prefer just by drag&drop. This is the section to view everything in your local and remote configurations. To update from any branch, just hit Update as shown in the image below:

Checkout

As you can see, I am currently in some_branch_name . If I would want to checkout to a (new) branch, it’s just one click away:

Fetching

In case you just want to see if there is something new on remote, but you do not care about updating, fetch can be found right here:

Tagging

Tagging is also simple in Android Studio, as seen in the Cherry-pick/Patches and commits section (see image). However, there is another way. From the upper toolbar of the IDE, you can have a dialog for tagging any commit you like, but you would need to copy the commit hash before doing that:

Anyhow, in comparison with SourceTree, it lacks just one small thing. You cannot immediately push the tag from this dialog:

Then you would have to be careful not to forget pushing the tag when pushing changes to remote:

Let’s have some fun now. Conflicts.

After resolving conflicts with the Android Studio Conflict resolver, I can say that I am not going to drop using git from AS anymore. In case one needs to know a little bit more about merging or rebasing, they can find it here, in this article that I wrote some time ago.

Just click the Merge button to open the conflict resolver. Now another window will pop up:

In this case, you know 100% what you are doing, what the others have been doing, and what you need to do after.

Ok, I still need the terminal for three things:

These just seem easier from the terminal, and I will continue to do so, but that’s just me, being lazy to find where the buttons are.

Closing notes

Hopefully, I have given a general idea on using Git from Android Studio. It is super easy to tackle, user-friendly, and smooth. What other git clients do you prefer?

Источник

ПШЕ AndroidStudio или как использовать VCS Tools по полной

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

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

Я постараюсь не обращать внимания на банальные вещи: init VCS; new/rename/push branch; rebase/merge onto branch; setup remotes e.t.c. Я постараюсь обратить внимание на те элементы, которые по боязни своего незнания, я долгое время избегал(и жалею).

Amend commit

В случае, когда Вы решили дополнить свои изменения к последнему коммиту, стоит воспользоваться следующей коммандой:

А можно ускорить процесс:

Edit commit message

Допустим, Вы создали большой PR с большим количеством коммитов, да перед пушем заметили, что одно из сообщений некорректно и было бы неплохо его отредактировать, пока жесткий ревьювер не четвертовал Вас за такую оплошность:

Interactive rebase

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

Пачка была быстро собрана, коммиты получились хаотичные, да еще и на ревью получил порцию исправлений… Окей, не проблема.

Проверяем отставание наших изменений от ветки, в которую мы хотим вливаться.

Либо через GUIню:

Дальше скачем в tools:

Указываем количество коммитов, которые хотим отредактировать:

Или сразу укажем таргeт ветку:

Дальше определяемся что нам нужно сделать:

Подробнее про команды:

Коммиты отредактированы, осталось только подлить все на ремут сервер. Но ведь история изменена? И хэши явно не совпадают с тем, что находится на удаленной ветке.

Force push перезатрет нашу историю и примет новые изменения как родные.

Multiple remotes

Скорее всего это лишнее, но, исходя из моей практики, далеко не все обращают внимание на эту фичу.

Что это? В случае работы в 2 и более ремут хранилищах(актуально, когда доступ в основное хранилище по прямому запросу закрыт), быстрое переключение между удаленным ветками для пушей/пулов тоже упрощен:

Git blame

Полезный трюк для просмотра автора внесенных изменений:

Теперь про более эффективную работу. Если Вы не поленились и внесли правила ведения коммитов в Вашем проекте, стоит включть IssueNavigationLink :

(Кроме всего этого, Вы можете настроить проверку формирования коммит мессаджа с помощью git-hooks — https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks)
Отредактируем файл project/.idea/vcs.xml :

Подбросим свою регулярку для анализа коммит месаджа:

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

Git cherry-pick

Не путать с командой cherry!

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

Заключение

В заключении хотелось бы сразу вспомнить вечный холивар на тему: терминал или GUI редактор для работы с VCS? Тут дело вкусовщины. Понятно дело, что CLI GIT-а более мощный инструмент и для спецефичных задач без него никуда. Но для ежедневных задач встроенный пакет утилит для работы с системами контроля версий в AS — просто must have и сократит время разработки в разы.
Надеюсь, что Вы нашли что-то новое в этой статье и помог облегчить Ваши трудовые будни.

Источник

A3.8 Приложение C: Команды Git — Внесение исправлений

Внесение исправлений

Некоторые команды в Git основываются на подходе к рассмотрению коммитов в терминах внесённых ими изменений, т. е. рассматривают историю коммитов как цепочку патчей. Ниже перечислены эти команды.

git cherry-pick

Команда git cherry-pick берёт изменения, вносимые одним коммитом, и пытается повторно применить их в виде нового коммита в текущей ветке. Эта возможность полезна в ситуации, когда нужно забрать парочку коммитов из другой ветки, а не сливать ветку целиком со всеми внесенными в нее изменениями.

Этот процесс описан и показан в разделе Схема с перебазированием и отбором главы 5.

git rebase

git rebase — это «автоматизированный» cherry-pick . Он выполняет ту же работу, но для цепочки коммитов, тем самым как бы перенося ветку на новое место.

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

Мы использовали эту команду на практике для разбиения истории на два репозитория в разделе Замена главы 7, наряду с использованием флага —onto .

В разделе Rerere главы 7 мы рассмотрели случай возникновения конфликта во время переноса коммитов.

Также мы познакомились с интерактивным вариантом git rebase , включающемся с помощью опции -i , в разделе Изменение сообщений нескольких коммитов главы 7.

git revert

Команда git revert — полная противоположность git cherry-pick . Она создаёт новый коммит, который вносит изменения, противоположные указанному коммиту, по существу отменяя его.

Мы использовали её в разделе Отмена коммита главы 7 чтобы отменить коммит слияния (merge commit).

Источник