Часто у разработчиков возникает выбор между Merge (слияние) и Rebase (перемещение). В Гугле вы увидите разное мнение, многие советуют не использовать Rebase, так как это может вызвать серьезные проблемы. В статье я объясню, что такое слияние и перемещение, почему вы должны (или не должны) использовать их и как это сделать.



Git Merge и Git Rebase преследуют одну и ту же цель. Они предназначены для интеграции изменений из одной ветки в другую. Хотя конечная цель одинаковая, принципы работы разные.

Некоторые считают, что вы всегда должны использовать Rebase, другие предпочитают Merge. В этом есть свои плюсы и минусы.

Git Merge

Слияние — обычная практика для разработчиков, использующих системы контроля версий. Независимо от того, созданы ли ветки для тестирования, исправления ошибок или по другим причинам, слияние фиксирует изменения в другом месте. Слияние принимает содержимое ветки источника и объединяет их с целевой веткой. В этом процессе изменяется только целевая ветка. История исходных веток остается неизменной.

Если вы не изучали JavaScript с самого начала, то осваивать его современную версию сложно. Экосистема быстро растёт и меняется, так что трудно разобраться с проблемами, для решения которых придуманы разные инструменты. Я начал программировать в 1998-м, но начал понимать JavaScript только в 2014-м. Помню, как просматривал Browserify и смотрел на его слоган:

Browserify позволяет делать require («модули») в браузере, объединяя все ваши зависимости

Я не понял ни слова из предложения и стал разбираться, как это может помочь мне как разработчику.

Цель статьи — рассказать о контексте, в котором инструменты в JavaScript развивались вплоть до 2017-го. Начнём с самого начала и будем делать сайт, как это делали бы динозавры — безо всяких инструментов, на чистом HTML и JavaScript. Постепенно станем вводить разные инструменты, поочерёдно рассматривая решаемые ими проблемы. Благодаря историческому контексту вы сможете адаптироваться к постоянно меняющемуся ландшафту JavaScript и понять его.

Доброго времени суток, хабровчане. В этом цикле статей, я бы хотел рассказать о реактивном программировании, а именно о фреймворке
RxSwift. На Хабре и в сети были статьи по RxSwift, но, на мой взгляд, они слишком трудны для начинающих. Поэтому, если вы начинаете постигать реактивное программирование в iOS, то прошу под кат.

В этой серии статей вы познакомитесь с основными принципами функционального программирования и поймёте, что значит «мыслить функционально» и как этот подход отличается от объектно-ориентированного или императивного программирования.

Alyson La, Data science в GitHub: В октябре этого года я отпраздновала свой пятилетний юбилей работы в GitHub. 5 лет назад я была бухгалтером, который ничего не знал о программировании, не говоря уже об использовании Git и GitHub.

Теперь я энтузиаст Data Scientist, который знает некоторые вещи о написании кода с помощью Git & GitHub. Частично благодаря изучению этих технологий я сделала этот карьерный переход.

Но даже работая в GitHub, изучать Git и GitHub было сложно! Поэтому я хочу поделиться 5-ью советами по использованию GitHub с другими людьми, новичками программирования.

Совет № 1: Измените редактор по умолчанию

Для многих людей текстовый редактор при использовании Git через терминал — VIM. VIM может быть ужасным, страшным для нового или казуального хакера. Или даже для ветеранов-хакеров как @haacked.


Если вы когда-нибудь столкнетесь с конфликтами слияния (а вы их встретите, см. совет №4), вы попадете в VIM, чтобы исправить конфликт, и вам нужно будет знать конкретные команды VIM для редактирования документа иначе вам захочется плакать. Больше года у меня была заметка на мониторе для напоминания основных команд VIM, таких как i (для редактирования) и: wq (для сохранения и выхода). Чтобы избежать боли, вы можете просто выбрать другой текстовый редактор.