Tag Info

New answers tagged

0

If you're building a one-off application, I'd recommend cloning the boilerplate, renaming, and building from there. If you're going to be doing that a lot, and especially if you find yourself starting from the same boilerplate each time but adding certain features repeatedly, then fork the boilerplate, add improvements to your fork, and start new app ...


3

You don't want to check in the IDE created files, as you don't want Thumbs.db or .DS_Store. By making every developer create their own version, you are adding more work and the risk of laziness at absolutely no gain. Having a few extra lines doesn't hurt, and helps you make sure you are not creating files that could interfere with other developers' workflow. ...


2

In an ideal world, you have a well-defined task, a bug tracker with a ticket to track your progress on this task In the ordinary world you have these things. There's no short-cut to achieving a disciplined working environment without any self-discipline. You can experiment as much as you like, and that;'s fine as long as you know that's what you're doing. ...


3

Commit until proven guilty. My preference is to keep everything that's needed in the repo unless there is a strong argument against having it there. Even if the version control aspect of the repository is not really needed for a given asset, having it come packaged with everything else when a developer clones the repo, or when the repo is deployed to a ...


0

Given the relative size of fonts, it's hard to imagine this making an appreciable difference on the performance of a repo. Compare that to having to remember to check the fonts repo for an updated version of the font (or new fonts that are needed), and it seems like it wouldn't be worth the hassle. However, YMMV.


2

While git is great, merging/rebasing an out-of-date feature branch is always going to be a painful experience. There is no magic bullet (of which I am aware) that will make this headache go away. In my experience, I prefer rebasing over merging in these situations for the reasons you mentioned: you can resolve the errors in each commit one at a time, and ...


1

For my work we use separate repos and maintain versions for each module. Pros Not all of the modules are required for each project so we are able to easily keep the size of each project down Commit history is specific to the module It is easy to use specific versions or branches of the module when needed. Cons We have to use a package manager to ...


1

TL;DR Canonical build or test files should always be included in the repository. Files that are expected to be customized by each developer should be included in a minimalist way within the repository, often in the form of example files. Reasons to Include a Baseline Guardfile Verbatim Files which are required to build or test your code base should be ...


0

I think that would be a great idea because it will keep things nice and neat for the humans that would have to read it. I usually use sub-directories with my code to make it more human readable. Not using human readable code gives me a headache and makes looking for things very hard. The best thing you can do is put the main executable file in the home ...


1

With git you can use git submodule. ProductA can have specific commit_ids (which can be a branch) of some submodules (for example ComponentA, ComponentB, SharedComponentC). To add a component to ProductA, from the ProductA directory on your development machine do: C:\projects\ProductA.git\> git submodule add --branch master --name ComponentA ...


5

You're making some incorrect assumptions. Here are a few: Having a granular version history (thousands of options, as you put it) is not clutter. For example, when you're looking to revert small changes made a long time ago, going over 1000 properly commented commits is a breeze. You can't do that with only 2 revisions in your history. Commit ...


4

I'd keep those feature branches (very much like what you describe now), but make sure they are feature branches, not individual developer branches... Developers work on these feature branches, develop and test their feature. Then on top of that, like you say, have an integration branch where all changes get merged, compiled and perhaps get some day-to-day ...



Top 50 recent answers are included