100

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 ...


69

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 ...


38

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 ...


35

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 ...


28

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.


27

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 ...


26

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 ...


25

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 ...


23

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.


22

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.


21

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. Just ...


20

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). ...


16

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 ...


14

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). Example: Your database has tables for ...


14

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: 1. Organization: For more information on GitHub Organization features, be ...


13

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 ...


13

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 ...


13

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 ...


12

If you're adding methods to a repository like GetById GetByName GetWithIncludesABC GetWithIncludes123 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 ...


11

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 ...


11

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. A ...


11

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/...


10

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 ...


10

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.


10

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 ...


9

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 { ...


9

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 ...


9

When you use void updateTitle(String str) { this.title = str this.store.update(this); this.notifier.notifyAboutChange(this); } you are grouping two operations into one -- updating the model in memory and making the updated model persistent. This is a policy decision you have to make for your application. Only you and your team are in a position ...


8

I think you should think who has an interest to change that respective class. For example if you have an User class with an CalculatePay method and a save method. The accountant would want to change the CalculatePay and the DB administrator the save method. These are two different responsibilities. The SRP means grouping together things that change for the ...


8

No, domain objects should not have any idea of the existence of a repository, or even a repository interface. If you feel the need to do this, that means there is an underlying issue with your design (see below). The root of your problem is that you have not modeled all of your entities properly. A course does not have students it has registrations. Not ...


Only top voted, non community-wiki answers of a minimum length are eligible