Originally published on my blog
Meetup notes
Last Thursday (06.04.2017) we had our 8th MeCoDe meetup, and this time it was all about ...
For further actions, you may consider blocking this person and/or reporting abuse
Nice article but you should use git-flow-avh instead of git-flow. git-flow have not had a commit since 2012 and there are many issues. Either it is abandoned or it's perfect but I think more about abandoned ;-)
Thank you Peter. You're right and I do use it, see how I used the git-flow command in the post. Anyways, I've updated the post to link to the -avh version. Thanks!
One thing regarding code reviews. I've experienced a desire from developers who want me to be present while they review the code. This practice eliminates the utility of code reviews because it ends up taking far too much time to pair
programreview.Am curious to learn if you continued the practice or steered away from it?
IMHO I can see this git-flow from vince becoming more applicable to bigger companies, specially for small dev cells with jr devs.
loved the memes
I prefer to trust people to introduce these things as they think it's valuable. If they're not sure it should go in, then they can send a PR. If they think there is risk to their code, they can request a code review. I don't see value in mandating these things, it implies distrust and adds frequently pointless overhead, I'd expect the natural reaction to be taking less time during a code review, undermining their effectiveness.
Our team's policy is that no code is commited to master before it passes a code review.
A code review is not there to convey distrust but it's there to strengthen the codebase and keep the reviewer up to date with the changes. Sometimes you don't notice what someone else will, by looking at your code.
After we got used to this, everybody across multiple teams agrees this was (for us) a great thing to do.
What benefits do you see from git-flow vs. github-flow style feature branching? I've always thought git flow was overcomplicated but I want to hear from those who use it and get benefits from it.
Hey Alex, thanks for your question. I have to say that our backend teams prefer github-flow as they don't have the notion of versioned API so it kind of makes no sense for them to follow the 'flow' of develop/add new features -> when done with feature go into the 'release' mode, increase the version, merge into master, tag, and deploy. The mobile app teams, however, do go through this process every time they submit a new build to Apple/Google so it comes second nature to them to use such a flow and it makes them 'not forget' few of the things they need to do when in the 'release' branch.
I have found that I like the bash/zsh auto-completion plugin for git-flow and the fact that it basically 'does few commands' for me so that I don't have to type that much to, for example, 'finish' a branch - it also deletes it automatically for me, merges it into develop branch and checks out the develop branch.
Could one mimic the whole git-flow model without using the git-flow tool? Sure, for example, for hotfix branches you could just create a 'new' branch and make sure you stay consistent with your naming (prefixing it with, for example, 'hotfix/'). The same applies for feature branches.
Even if you don't end up using 'all' of the branches from the git-flow model, I think that trying out the tool may be useful as it's a good companion that makes you type less.
Thank you for the awesome response! Very helpful.
Nice article very informative.
Thank you Sascha, I'm glad it was useful to you!
Lovely article. Helped a lot. Thanks
Thank you, I'm glad it was useful to you!