Technically git is even more cool. When the server is down you can just start gitweb and let your colleague pull and push directly from your local repo.This is the true intention of git. Only because we like to store our code in one central place for backup purposes (+ large corporations don't really get git) we use products like stash/bitbucket and use git like subversion.
Yes git is awesome! Oh damn, I didn't think of this case before, pulling directly from local machine. 😂 That's definitely useful if the server is down during important merge between features. Will play with gitweb.
Haha, backing up code is definitely one solid good reason! Given a scenario that a malicious hackers hack all the computers, at least the code is still safely stored remotely. Another extreme scenario is that a newcomer will have no access the to codebase if all the employees are away for holiday. Nonetheless, having a central repo in the server (like Github) promotes transparency to what everyone is doing because we can easily see the changes across branches.
The beauty of git is that we can use it in any way that suits us.
Thanks for that easy explanation of GitFlow! I have only seen and used the simple workflow until now, I'll take a look at it. The link of the "advanced version" from the author does not work! I think you need to remove the final dot and it would be fine ^
Thanks for reading! 👍 👍👍 Gitflow is a scalable branching model which is suitable for a growing team. I have a few comments on the final dot, I HAVE REMOVED IT! THANKS!
There are many good articles that explain why gitflow is redundant without any actual benefit. And still there are people that continue to advertise it. This is sad.
For those who really want to be effective I recommend to search for and read about "trunk based development in git".
Don't be sad. I've updated the post to give a slightly more balanced view. There are indeed good articles that explain why gitflow isn't beneficial for some teams and vice versa.
I found a good article at docs.microsoft.com/en-us/azure/dev... which explains how a trunk based development is being used at Microsoft with the goal to encourage small simple changes. I like how they tweak the workflow to meet their needs. However, for an ambitious startup that is continuously churning breaking features, trunk based workflow may not be suitable. There are just so many factors to consider before we can deem it effective or not.
In my team, I can proudly say that we love gitflow. ✌️
The is also a terrible lie in the article. It states that "A Simple Workflow" has a drawback like "Many merge conflicts". At the same time it says nothing about the amount of conflicts in case of "Gitflow Workflow". The truth is that the amount of conflicts has absolutely NOTHING to do with workflow and is totally the same in any workflow.
You're right on this one. The amount of conflicts does not depend purely on the type of workflow. I've not added any context to the merge conflict point which causes confusion and a terrible lie.
Given a scenario where 2 developers work on the same file and the same piece of code and commit frequently, it would result in frequent merge conflicts. Of course the two developers can sit together to resolve the issues together in the beginning to prevent more conflicts. However this may occur regularly and result in a waste of time. Personally, I just feel that it's more productive to resolve the conflicts once and for all when the features are done.
Your Gitflow explanation link has a period near the end that invalidates the URL.
I know! 😢 I've fixed it! Thanks!
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.