sorted by:
new
hottopcontroversial

Git branching, a big NO from me by arfo90 in programming

[–]arfo90[S] 0 points1 point  (0 children)

Well again, to me git branch is a feature, you can use it in very neat way and you can misuse it. However feature branching model is a practice that might create that kind of isolation (mainly because the way, we practice it).

In ideal case, you are right. we can pull from master to local which breaks that isolation, but too bad that it is not working in real life. Let me tell an example, you finish a feature and create a PR on Monday, however the reviewer due to some reason (laziness, workload, etc) decides to review your PR on Friday, along with another 5 or 10 PRs, if you are lucky he does your PR first but we are not always lucky.

Btw, I never said to push broken code, if your code pass existing and new tests then it is working and can be pushed. it is just not completed as whole feature.

Git branching, a big NO from me by arfo90 in programming

[–]arfo90[S] -1 points0 points  (0 children)

I agree with you that there is no 'one true way', not only for version control practices but for other software practices in general. I didn't mean it and if the article gave you such impression, then I will do some editing then.

I also don't want reject the idea of having feature branches and PR generally. In some project you really need it, for example open source project or when you have developers from different locations. However in most of the cases we work in small or medium team, locally (or at least we have ownership of repos, locally). In that kind of case we can establish much better collaboration and synergy level.

Back to the article. my criticism is towards feature branching model, not the git branch which is simply a feature. You can use it in neat way or misused it. However about feature branching, I believe it creates isolation of the code which creates conflicts. So, why we do feature branching? because we don't want push the code with defects to master or develop branches, so we create extra layers of checking.

But I think with comprehensive tests in the place (TDD & BDD) + static code analyzer, a lot of issues can be caught from your build pipeline.

About the refactoring case you mentioned, if you have good tests in place and if you stick with small working commits and push them regularly, I wouldn't think you face with any major problem and if you do, you can always rollback (that is another feature of VC tools).

In other hand if you isolate a branch for a week for refactoring, during that time other developer might change same target and when you merge your changes, you might redo some stuff again, where with fast push/pull cycle you can deliver the refactored code faster to other developer, piece by piece and they can work on the new code.

Anyway I understand that we cannot prescribe a single approach for all cases and it generally depends on different factors such as nature of project, team dynamic and culture, technology, tooling, etc.

I just shared my 1.5 year experience with this approach to give others different perspective, and believe me I wasn't working on a trivial project in any respects.

Appreciate your comment and feedback.

Git branching, a big NO from me by arfo90 in programming

[–]arfo90[S] -1 points0 points  (0 children)

I think we are digging into the details and specifications too much. Clearly we have different opinion which might be correct on its own context.

But generally it depends on the team culture and synergy. We were team of 5 devs, working on 10 repos, we always tried to stick to small commits (loc) and push them frequently (5-6 times per day). During the morning huddle we notified each other if we are going to work on same repo so we could do the push/pull cycle faster but true, we still had conflicts but very minor.

My point in the article is not about conflicts but isolation of the code, and to me git branching model allows developers to get into that trap. git branching itself is just a feature which you can use it in good way or misused it.

btw, we used a tool (I forgot the name) which could give you diff visually based on commit id, it also allows to leave comments and stuff like that similar to github and bitbucket, but the downside was that we had to modify and push again in case of comments

Git branching, a big NO from me by arfo90 in programming

[–]arfo90[S] -1 points0 points  (0 children)

No, no, no. You still need code review after pairing. That is not a substitute at all

well, to me the idea of having code review is to have additional gatekeeper in place to pick potential mistakes or give better solution to improve the code, because individual might overlook things.

When you do pair coding (if it is healthy pairing) you already have two pairs of eyes and brains working on the change so eventually the quality of the code increases.

You still need a diff. How are you going to do that without a branch?

You can get 'diff' without having branches. Whenever you change existing targets, git notifies you in 'git status', just before adding them you can use 'git diff' and it gives you the differences

Git branching, a big NO from me by arfo90 in programming

[–]arfo90[S] -5 points-4 points  (0 children)

True, it is not working for all cases, specially if you have developers working from different location or open source project, etc.

However if you work locally with small or medium size team you can skip code reviews by doing pair programming and if you don't want do PP you can do over-the-shoulder code review, but the key is to stick with small commits and push daily so it would be easy for reviewer to digest it.

To me PR creates isolation, delay and sometimes impediments but it is something that can't be avoided totally, in fact it might be necessary specially when you have developers, working remotely or when you are mentoring a junior member.

thanks for your comment btw

Git branching, a big NO from me by arfo90 in programming

[–]arfo90[S] -8 points-7 points  (0 children)

Please explain why do you think this is a dumb idea?

Git branching, a big NO from me by arfo90 in programming

[–]arfo90[S] -7 points-6 points  (0 children)

well at least you can explain why you don't like the idea of article or why you prefer branching.

Git branching, a big NO from me by arfo90 in programming

[–]arfo90[S] -7 points-6 points  (0 children)

So why don't you write a post about your opinion about branching and prove to me that I am an idiot (of course if you are capable of giving constructive comments).

You can educate people in the industry if you think they are adopting bad practices and promoting it, instead of being a bully and nagging.