Well, terms have meanings and it's nice to keep it, makes discussion easier.
So yeah sure, we were doing 2 hours-long 1%-of-a-feature branches.
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. ;-)