034 Avoid Multiple Cherry-Picks using Git Flow

Подписаться 7 тыс.

Просмотров 7 тыс.

50% 1

In this video we go through a simple release/dev/hotfix branching strategy based on git-cherry-pick and then show an alternative approach using a basic "Git Flow" branching strategy. This (technically) better approach reduces commit duplication for hotfixes making your repo history cleaner and more efficient on disk.
If you aren't familiar with 'git cherry-pick' or how git branches work, you may get confused. See these videos for getting up to speed on those topics:
Introduction to Git Cherry-Pick: • 016 Introduction to Gi...
Git branches aren't branches: • 018 Understanding Git ...
If you are looking for an effective concise introduction to Git, I highly recommend my "Fundamentals of Git" course on Udemy: www.udemy.com/...
If you or your company is interested in live virtual software and tools training, see www.continuous... for a list of training topics we offer.

Опубликовано:

12 сен 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 18

@MauricevanderPot 3 года назад

I like the visualization, but there is a better way to work with git flow. Instead of merging the blue fix on the v1.1.x branch to each of the other branches where you want it (as you show around 12:44), you should merge it to the v1.2.x branch and then merge the commit on v1.2.x to v1.3.x and so on. This gives you a nicer picture of the history (in the way you visualize it), but more importantly it will prevent you from having to resolve conflicts a later branch that you have already resolved while merging to an earlier branch.

@DanGitschooldude 3 года назад

Excellent point. Pinning this for others to see. Thanks!

@zor-el-one 4 года назад

I've been using Git Flow for years and this is one of the best elaborations on hotfixing! Nicely done! One hint: The Git Flow graph to the right could be drawn to look nicer and cleaner w/o crossing lines.

@kj07208 4 года назад

Your videos are some of the best and practical usage of Git. All the other videos are very simplified and don't cover different development scenarios.

@DanGitschooldude 4 года назад

Thanks!

@JorgeLopez-yl3um 5 лет назад

Best example I've seen. Great job!

@javakom 2 года назад

that is great explanation.

@aram5642 3 года назад

I don't like any approach any bit more than I like your dilligence in presenting them both! Nice, clean diagram wrapped in very practical explanation. Well, once again, it all shows clearly that DRY comes at a price. I think a 3D tree would help understand repo history much better some day.

@DanGitschooldude 3 года назад

If I had the time I've always wanted to try building a 3D tree visualizer for git. Tie it to a VR system with the ability to interactively rebase with your hands, would be super useful to help teach git as well. Cool that you've had the same idea!

@aram5642 3 года назад

@@DanGitschooldude The 2D variant is also challenging, tbh. I have seen some crazy history graphs - to be able to graph it is not a trivial task :)

@winmonaye 4 года назад

Really Nice. Is there any good approach for when you don't want to release all the features?

@aaronaaronaaron5922 4 года назад

Thanks for all this great videos :D

@DanGitschooldude 4 года назад

My pleasure!

@JRasmusBm 4 года назад

What would your opinion be to using rebases instead of merges and then force pushing the linear history? As I understand that you would the same benefits as in the got flow example but with a nice linear history. I guess a drawback would be the risk of making mistakes but the same risk exists in the got flow example you outlined. Thanks for instructive video series! 😃

@DanGitschooldude 4 года назад

It's up to you. There are more risks with rebasing and force pushing branches than a merge request workflow. For example if your workflow has people force pushing to master, one wrong command could seriously screw up your history. If your team is knowledgeable of git and understands what not to do, it works.

@games4us132 Год назад

why hotfixing 1.2.x if you have 1.3.x hotfixed and released ?

@erinboehmer6713 2 года назад

Thanks for sharing the strategy! When you merge the hotfix into dev, you say you don't need the original commit so "we can get rid of it" ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-j5MC4Nm5JQk.html Is that a manual commit removal via --hard reset HEAD or is git smart enough to recognize the the duplicated commit and update?

@DanGitschooldude 2 года назад

It depends on the details of how the commit was made which isn't shown in this video. If the original commit is reachable from a branch, it will stick around, so that branch should be removed after the fix is applied further back in history and merged forward. If that original commit was just created off a detached HEAD, it will automatically be cleaned up by a git garbage collect some time down the road. Any commit reachable from any tag or branch will never be discarded by git.