83
Instead of having two code version with a common base you should design your application in a way to make those premium features plug-able and driven by configuration rather than different code bases.
If you are afraid to ship those premium features (disabled by configuration) with the basic version you can still remove that code in a final build/packaging ...
39
I strongly recommend not using branches for this purpose. In general, you should consider branches for things that will be (or might be) merged back together again later (or for release branches, where you eventually stop development of one of the branches). In your case, you will never merge your "basic" and "premium" versions together, and they will both ...
32
From the Git SCM Book:
Often, when you’ve been working on part of your project, things are in a messy state and you want to switch branches for a bit to work on something else. The problem is, you don’t want to do a commit of half-done work just so you can get back to this point later. The answer to this issue is the git stash command.
Stashing takes ...
30
He's mostly referring to the feature branches side of the model. Feature branches were declared an anti-pattern a long time ago when the branches lasted for months and version control systems couldn't merge to save their life. Feature branches that last a week or two have much fewer issues, especially if you're continually merging from develop into the ...
23
You should certainly consider splitting the product into modules with interface team(s) bringing those constituent modules together into a product. This in turn would mean splitting the repositories to match the module partitioning and hierarchy. If it appears that you can't do this then the project will probably grind to a merge-induced halt considering ...
23
Should I commit the test before writing the class even though the test doesn't even compile? Or should I stub out the minimum amount of code that is needed to get the test to compile before committing?
Of course not. You should finish both the test and the class. Committing something1 that doesn't even compile makes no sense, and will certainly make people ...
22
This is a wonderful idea, with one caveat. Don't replace developer written tests with reviewer written tests. Have your reviewers look for corner cases and inputs that will break the code. In other words, have them try to write new tests that the original developer didn't think to write.
Writing characterization tests is an absolutely wonderful way to gain ...
21
Merging is a funny thing - the less frequently it's done the harder it will be, the harder it is, the more people will be afraid of it, the less frequently they will do it.
Solution is either do not allow branches to deviate too much, or not to use branches.
If people understand this, you will probably have not much problems with merge, if not - may be ...
18
I don't think the idea is entirely without merit - however, the main benefit of the TDD et al is that problems are found early. The developer is also best placed to spot which corner cases may require specific attention. If this is left until the code review, then there is a risk this knowledge could be lost.
Writing tests during the code review would ...
15
Correct: a pull-request is linked to a branch in your repository. If you modify the branch, you are then also modifying what you're submitting as a pull-request.
So yes, you do have to create a branch (and pull-request) per bug fix. It might be wise to start with one and see how the maintainer reacts to that one before going on to do the rest. Open source is ...
15
Pull requests are created so someone can review the work, make comments, suggestions, make or request edits and then merge the code to master.
In your case the someone is you.
As the sole developer you still should review your own work, refactor it and merge it to master when ready.
One approach I use a lot is to try to 'put on another hat', 'try other ...
14
I'd personally go for many small libraries.
Discourages developers from creating dependencies between otherwise unrelated packages.
Smaller more manageable libraries that are much more focused.
Easier to break up and have separate teams manage each library.
Once you have a new requirement that's sufficiently complex, its better to add a new module
rather ...
14
Let the developer who went for a couple of months without merging fix it. Maybe they can get one big chunk of code to merge, maybe they can get a bunch of little chunks to merge one at a time. In any case, they should be doing the legwork to fix the problem, since they caused it.
What is the best way to deal with such a situation where one branch is ...
13
Since it's all new code, I would tend to go with #1 because the commit history of the old project is really irrelevant. But it would be nice to add something to the README along the lines of, "Based on an idea from ....".
I'm a big fan of acknowledging where we (or our algorithms) came from. If you look back into the mists of history, you'll see that we are ...
12
Why don't you use git locally to share your code with your three development machines/environments, and then just use SVN to do the commits that go to the rest of your development team.
This way, you can use git without locally without making the rest of your team use it.
12
The issue might also lie in a too rigid separation of task between back-end and front-end development.
If a front-end developer need a new API, isn't it possible to allow him or her to create a dummy API on the back end (returning always the same value for example) to validate the layout ? Then commit that partial implementation with a stub, and in a ...
11
I see my job as providing the best quality software that is possible within the time constraints allowed for the project. If I am concerned that the level of quality will be low, then I will engage the project owner. I describe my concerns and discuss the potential risks of deploying the software in that state. One of 3 things will happen at this point:
...
10
There's no way to accurately do this. For example, who contributes more: someone who commits 1000 lines of code in a month, or someone who spent most of his time thinking really hard, and then committing 100 lines of code that replace the 1000 lines of code? Or how about somebody that goofed off most of the month, then found those same 100 lines of code in a ...
9
You can design your control flow the other way around to avoid multiple timers.
When you send an email, store any context you need for a response. E.g. write this context to a database or file.
Regularly check for responses. E.g. you might have a single thread that checks incoming emails. This may involve a timer, or may simply await push-notifications (e.g....
9
but I want to separate out the library part into a separate repo, in preparation for eventually releasing it.
Separating the library has a few implications. One of them is that others will use your library as well. At that point, you cannot just roll back changes in your library, as it may have unexpected effects on other projects that use this library. In ...
8
Should I commit the test before writing the class even though the test doesn't even compile?
No.
Should I commit the failing test
No.
You are talking about two paradigms here:
test driven development - which says nothing about committing code. Indeed, it tells you about how to write code and when you are done. So I'd consider every 'done' as a ...
8
We are using 2 separate projects, the Basic one and the Premium one that depends on Basic project. Do not use braches, they are usually used for features.
8
In TDD, writing tests and code is interwoven, the cycles are typically very short, sometimes minutes, sometimes less. And TDD is a whitebox technique - when writing the next test, you know exactly what is missing in the current state of the implementation and you design the test exactly for this case.
So if you really want to try this with two developers, ...
8
This is very similar to a successful git branching model that we've employed in my workplace - it works wonders for us (though we differ slightly from your branching a little, and put the git tag on production server so that devs don't patch live and update git via production server (and possibly fubar the branches)).
When developing
Your proposed method ...
8
Cloning the repo to the developer's local machine is already a kind of forking. If each developer forks the repo on GitHub, this only serves to publish their current state of work.
This can be appropriate when there is a central master repo, and many contributors that are not trusted with direct access to that repo. This works great for open-source projects ...
8
I feel that this is overkill for a single person working on a single web application.
I would use tags to give version numbers to versions you release to the production server. The staging server can just use the latest commit on master, whereas production uses a tag.
Have a "release" script that updates files with the new release number, commits them, ...
8
What you are asking for has not much to do with the particular problem of AST processing. The question you are asking is
I have to design an API for a component, the API needs to provide different functions to calculate different values, but the value calculation internally is complex and has similar steps, shall I design the API so it returns different ...
8
Theres no magic fix. Your only choice is to limit your exposure to these types of problem.
This is obviously a general rule, but I think its especially true with solo projects. Where you really don't have time to fix problems with your tool set, libraries or odd edge cases.
Only use mainstream, mature libraries and frameworks
Don't use a thrid party ...
7
There is only one real benefit, yet its huge:
Separation of Concerns.
So, instead of process orchestration logic being embedded in our system, it becomes and external configuration. A map, basicly. You can change it (much more) independently, you can have multiple processes, multiple versions of processes, multiple versions of multiple processes running at ...
Only top voted, non community-wiki answers of a minimum length are eligible
