I actually tried to simply have my team commit to the main branch, and it worked out quite well - we never had problems with code divergence. I guess it doesn't work so well for larger teams not working on MVPs, though (we were 5 developers).
The thing is, I want my developers to code, not talk all the time about what/where they would like to code and that the others have to wait until they're finished or suck up the merge conflicts if there's no time. Some communication is always necessary - but this solution with feature branches requires constant communication and still, the developers would rather wait that try to synchronize this way.
The more you comment, the more it’s clear you work with a bunch of coders who want to “go dark”, and there are a ton of problems with that.
Don’t go dark.
Well it wasn't trivial at that stage of our development. It became much more trivial once we and the market were happy with our product-market fit and at that point we indeed started with feature branches again.
Now I'm working at a consultancy and since there's much more time for everything, we are doing feature branches during our MVP development too. But there's a stark difference in velocity this current team and the team I told you about achieved.
This just isn’t a real problem. Try working more incrementally, or try working with colleagues who don’t rewrite large swaths of code without coordinating with their team.
You have a people problem, not a tool problem.
Your team is suffering badly from a lack of even a baseline understanding of how to develop software as a group, and learning even the most basic usage of git would substantially alleviate that issue.
When your business changes wildly every 2-3 months for a year (and sometimes few times a month too), it's hard to not change the code base a lot. Our place was not to change this situation - our place was to learn to deal with it, which we did satisfyingly.
Also I guarantee I’ve used git branches in more dynamic situations than what you’ve described here and it caused absolutely zero issues.
I'm glad that your preferred branching strategy works out well for you.
Seems like by your definition there's no way to not do feature branches. A little weird take, IMHO - I know it as a very specific strategy that you have to consciously perform e.g. by naming your branches correctly in sync with your issue tracking system, by not merging until you're done with that ticket, etc - not something that happens automatically just by cloning.
https://sillevl.gitbooks.io/git/content/collaboration/workfl...
There is nothing whatsoever that requires a feature branch be long lived or named anything in particular. This is what I mean when I say you don't understand the technology you're using.
What you have linked is a "flow" that uses branching, and isn't relevant to this discussion.
So yeah sure, we were doing 2 hours-long 1%-of-a-feature branches.
https://www.atlassian.com/git/tutorials/comparing-workflows/...
https://www.decodingdevops.com/how-to-create-feature-branch-...
https://docs.gitlab.com/ee/topics/git/feature_branching.html
Could you please post at least one article which describes what you're talking about and what the differences from "just commit/push to main" are?
BTW this whole thing isn't about keeping a branch up to date with the main branch - sure that's easy. This is about integrating changes in a small code base where collisions happen often due to small but rapidly changing featureset on which 5 hyperactive developers work on. The only solution to that is to integrate the code very often on a common branch - in our case, around every 1-2 hours, regardless of features being done or not.
> Some people refer to Git’s branching model as its “killer feature,” and it certainly sets Git apart in the VCS community. Why is it so special? The way Git branches is incredibly lightweight, making branching operations nearly instantaneous, and switching back and forth between branches generally just as fast. Unlike many other VCSs, Git encourages workflows that branch and merge often, even multiple times in a day. Understanding and mastering this feature gives you a powerful and unique tool and can entirely change the way that you develop.
It's really not hard, a "local copy" is a branch.
If you can't manage what you just described trivially, you need to learn git better, because I, and everyone else who knows how to use git, can manage those things trivially, and have successfully for many years now.
Your solution was the wrong one, homegrown to avoid dealing with the reality that you and your team didn't know how git works.
All of this would be fine, by the way, had you not proposed others listen to you. Exactly zero people should do as you have described.
[0] https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-N...
> It's really not hard, a "local copy" is a branch.
For sure. Not necessarily a "feature branch" though. That's a more specific thing described in the articles I linked, building on top of the basic Git feature you linked.
Please understand that "feature branch" is a technical term describing a very specific branching strategy - and you're not going to find its definition in the Git docs; I think it was originally defined by Atlassian (but not quite sure). A local copy of the main branch with a few additional commits that you're going to push to the origin way before the feature is complete is not a "feature branch" as commonly defined.
You originally replied talking about how hard branches are to merge, but then revealed you also use branches to develop features, thus revealing a fundamental lack of understanding about how git works.
In our case we stopped using the `git branch` and `git checkout` commands whereas previously it was an integral part of our workflow, hence "not branching out" - again, sorry for not saying explicitly in that one comment that of course we worked with the local copy of the main branch which is a branch too, since that's how Git works I thought that's a given, this is a professional forum and I didn't think I need to call out everything so explicitly as if I was talking to a junior dev.
I never said that branches are hard to use nor that we didn't use them - it's only your strawman where you (since I explained what I meant so many times, it must be) intentionally misinterpret what I said about feature branches. You even sent a link to Git docs when I asked you about workflow strategy and in reply to articles talking about workflow... :-D
Feature branches are a very common workflow at many companies big and small, one could reasonably say it's the standard, practically every single team where I worked has done it this way and any change to this workflow was much discussed and temporary - and I've seen that happen only 2 times ever in my 12 years of SWE consulting career. I'm really surprised you are acting as if this was the first time you heard the term.
And - we got it already, you're a Git ninja. You can stop trying to show us your superiority now. The discussion would be much more pleasant - and I'm not saying this because you know more about Git than me, I'd be happy to learn. ;-)