As you mentioned in your question, people fork repositories when they want to make a change the code, because you
don't have write access to the original repository (unless you've been added as a collaborator by the owner of the repository).
In the forked repository they have write access and can push changes. They may even contribute
back to the original ...
In our line of work we tend to look for technical reasons, but in my opinion the primary reason isn't technical. If you look at GitHub Help or other GitHub tutorials, forking a repo is one of the major steps for how you "do" GitHub.
When people are learning and evaluating GitHub, just about every tutorial out there is going to tell them to fork a repo as ...
There doesn't seem to be an argument in favor of the big repo in this thread, so here's one:
The advantage of a big repo with all your code in it, is that you have a reliable source of truth. All the state in your overarching project is represented in that repo's history. You don't have to worry about questions like "What version of libA do I need to build ...
No, think of it this way: a repository is a service (also).
If the entities you retrieve through the repository handle most of the business logic there is no need for other services. Just having the repository is enough.
Even if you have some services that you must pass through to manipulate your entities. Grab the entity from the repository first and then ...
Git tends to experience performance problems when used with large repositories.
To quote Linus:
And git obviously doesn't have that kind of model at all. Git
fundamnetally never really looks at less than the whole repo. Even if
you limit things a bit (ie check out just a portion, or have the
history go back just a bit), git ends up still always ...
One possible reason: they have running code that depends on those projects and their build process involves pulling the dependencies from github. Having the fork protects them against breaking changes. For projects that don't tag versions, this is the easiest way to achieve that.
The entire point of Github is "social coding".
Personally, I fork repositories when:
I want to make a change.
I think the project is interesting and may want to use it in the future, but have no easier way of saving it for later on the device I'm currently using.
I want to use some or all of the code in that repository as a starting point for my own ...
You've got a lot of moving parts in your question, touching on a lot of concepts, but here's my basic advice when it comes to how to think about a mid-to-large scale MVC application:
Presentation <---> Business Logic <---> Data Access
Firstly, it's best to not think of the the app as "an MVC application". It's an application that uses the MVC pattern ...
You assume the fix does not introduce any new issues and fixes the old ones complete. But lots of fixes are worth a review on their own - and that is probably much easier when the incremental changes can be reviewed separately.
They want [something that can] show their changes across all projects instead of trying to remember what project they made a change [to].
Sourcetree (a free-as-in-beer GUI Git frontend) allows you to register multiple repositories, organise them into logical groups, and then view status across all of them at once:
I am not affiliated with them in any way.
You should put the unit tests in the same repository because otherwise someone has to answer to the question "Where are the tests?" every time the project is handed over from one person to another. References to other repositories tend to get invalid over time when repositories are relocated and people change from one version control system to another.
You're dealing with multiple teams and multiple projects. Likely decades of work went into the codebase.
The short answer is that your teams and projects have varying needs and varying dependencies.
The monolithic repository approach reduces commits to "Everything is stable in this configuration!!!" (i.e. unrealistic, huge commits sourced from many teams). ...
Why you shouldn't do it from a team perspective
The most important rules of project management regarding teams are:
The project can be a success only through intense teamwork.
Empowered teams that trust each other are the most effective.
One for all and all for one
What you are trying to do, is very different. It was called "Divide et impera" by ...
There are projects that have many hundreds of contributors . The Linux Kernel is one that springs to mind, so no having 40 sets of eyes improving code and fixing bugs is not a bad thing.
However, what does matter are the change management processes, and the controls in place to ensure that a few bad commits by one developer do not bring the entire ...
TL;DR; the equivalent of a git repository is a CVS module, not a CVS repository.
CVS is designed with a notion of modules being a subdivision of a repository, and it is common to use CVS repositories with several modules having a quite independent life. As an example, it is easy to have branches specific to one module and not present in another.
git has ...
Repository returns domain objects and is built on top of mapping layers. For a very simple domain domain objects and database tables can be very much the same.
If your repository is always returning exact representation of your data structure then it might actually be Table Data Gateway aka Data Access Object(DAO).
Your database has tables for ...
Short answer ...
Start out with the repositories in your personal account. From there, if/when things grow and/or get popular with the community, move them to an organization account.
GitHub Blog: Repository redirects are here!
Long answer ...
Let's look at some of your options:
For more information on GitHub Organization features, be ...
You should create a new repo for each independent project. Why?
Someone working on project D does not have to download all the history for E and F.
Git repos are cheap to initialize, so you can use as many as you like.
It is painful to work with multiple projects at once when they are represented as branches in a repo: When switching from A to B to quickly ...
The idea in Udi's post, as I gather, is that no kind of item appears out of thin air. There is (almost) always something, or more specifically, some domain operation, which caused the item to be created. Just like Udi's example of a user actually being born out of a visitor registering to the site. At that point and at that bounded context Visitor is the ...
Well, you can see a good example in the Spring Data Framework which is based on the concept of repositories.
There you will see repositories only deal with the data store, and rarely contain any business logic (this is reserved for the service layer). So, for instance, you take a look a their design you will see they have a CRUDRepository interface which ...
If you're adding methods to a repository like
Then you're better off moving to a Service Layer, and letting the Service Layer use EF directly. EF already has functionality similar to the above methods that you're just endlessly duplicating.
A Service Layer exposes Business Domain methods, and ...
What is the purpose of domain/business logic in classes when having repositories?
This is kind of like asking:
What is the purpose of cars when we have garages?
The reason is that Business Classes and Repositories solve different problems, and therefore are different Concerns in the application. As such, they need to be in separate classes.
What a repository does is translate from your domain onto your DAL framework, such as NHibernate or Doctrine, or your SQL-executing classes. This means that your repository will call methods on said framework to perform its duties: your repository constructs the queries needed to fetch the data. If you're not using an ORM-framework (I hope your are...), the ...
I briefly worked at a company where they decided to not add database integrity constraints on any of the tables because they were planning on relying on the ORM and correct programming to ensure the integrity of the database.
To put it mildly it was a massive failure. Code mistakes had caused the database to lose integrity, and at the time I joined about 1/...
No code reuse is usually understood as a selling point for microservices!
the microservices can be developed and deployed independently
different microservices can use different technologies, in particular different programming languages
If this does not seem like an advantage – in particular if all microservices are developed by one team, using one ...
I'm a relative newbie to version control; I've used mostly SVN, a little Mercurial, and even less Git, for only a few years now. That said, I think the following is probably good advice:
Make small commits often.
When you commit changes, commit only related items together to keep things coherent. This helps later on when you're looking back through commit ...
A facade is more general than a repository.
A facade can apply to anything that is not persistence based, whereas a repository is supposed to encapsulate access to an underlying source and make it look like an in memory data source.
Facades are for creating a simple interface for some other, complicated interface.
Whenever you have a class with more than 1 method, you can question if the SRP is fulfilled, since each of the methods will (typically) solve a different task or problem and so has a "different responsibility". But that's actually not the way I understand the SRP - SRP means IMHO "single responsibility at the correct level of abstraction". And the level of ...
Don't test trivial or obvious repository methods.
If the methods are trivial CRUD operations, all you're really testing is whether parameters are mapped correctly. If you have integration tests, such errors will become immediately apparent anyway.
This is the same principle that applies to trivial properties, like this one:
public property SomeProperty
The purpose of a Repository is to provide an abstraction layer for data access. That abstraction layer should shield the user of the repository from the details of accessing the data. Things like connection strings, data sources, switching to a different data source... Your user shouldn't have to worry about those things.
In other words, the user of a ...