Hot answers tagged

222

Ahh, but in fact you are using git in a decentralized manner! Let us compare git's predecessor in mindshare, svn. Subversion had only one "repo", one source of truth. When you did a commit, it was to a single, central repo, to which every other developer was committing as well. This sort of worked, but it led to numerous problems, the biggest one being the ...


114

When your build server (you are using CI, right?) creates a build, where does it pull from? Sure, an integration build you could argue does not need "one true repo" but surely a distribution build (i.e. what you give to the customer) does. In other words: fragmentation. If you designate one repo as "the" repo and appoint guardians who vet pull requests, you ...


38

I don't know how you define "everyone", but my team has "a central repo on a server" and also from time to time we pull from other colleagues' repos without going via that central repo. When we do this we do still go via a server, because we choose not to email patches about the place, but not via the central repo. This generally happens when a group is ...


25

The interesting thing about the nature of DVCS, is if other people are using it in a distributed manner, you likely wouldn't know it unless they are interacting directly with you. The only thing you can say definitively is that you and your direct teammates don't use git this way. This doesn't require a company-wide policy. So I will ask you, why don't ...


17

I think you're question comes from an (understandable) always connected mindset. i.e. The central 'truth' ci server is always (or near always) available. While this is true in most environments, I have worked in at least one which was far from this. A Military Simulation project my team worked on several years ago. All the code (We're talking a >US$1b ...


17

Ultimately, you are building a product. This product represents your code at a single point in time. Given that, your code must coalesce somewhere. The natural point is a ci server or central server from which the product is built, and it makes sense that this central point is a git repository.


13

The distributed aspect of a DVCS shows up in open source development all the time, in the form of forking. For example, some of the projects I contribute to were abandoned by the original author and now have a bunch of forks where the maintainers sometimes pull specific features from one another. Even in general, OSS projects take outside contributions via ...


8

Why does everyone use git in a centralized manner? We've never met, how comes that you say everyone? ;) Secondly, there are more other features that you find in Git but not in CVS or SVN. Maybe it's just you assuming that this must be the only feature for everyone. Sure many people may use it centralized like CVS or SVN. But don't forget the other ...


7

I would keep each library in its own repository. Start keeping track of library versions, for example with git tag. A big problem with simply checking each library into each application's repository, is that you've essentially done copy and paste, and thus gain all the disadvantages that implies. Bugs fixed in the copy of the library in one application ...


5

Flexibility is a curse as well as a blessing. And as Git is extremely flexible, it's almost always far too flexible for the typical situation. Specifically, most Git projects aren't Linux. As a result, the smart choice is to remove some of that theoretical flexibility when implementing Git. In theory repositories can form any graph, in practice the usual ...


4

You should probably read through the PEP yourself. Either Larry Hastings is confused or something was lost in communication. The reasons for moving to git and github over mercurial are not technical, but social. A pull request workflow is perfectly well supported with mercurial, but github is the one with the much wider userbase over bitbucket and ...


3

There are two basic approaches that you can take. Keep versions on libraries. Track dependencies carefully. You will eventually experience dependency hell. Keep all libraries up to date all the time. You will need very good unit tests, and a deployment strategy that provides a locked target for production. I have worked at companies that use both ...


3

Your question should involve description of your delivery and development process, and then you could decide which branches you need to maintain. I assume a classical set-up. You have a main development branch - where everything is developed by default, and a release branch, which is what you are preparing to publish as a release to customers. For a ...


3

Business logic rewards a centralized server. For nearly all realistic business scenarios, a centralized server is a fundamental feature of the workflow. Just because you have the capacity to do DVCS doesn't mean your primary work flow has to be DVCS. When I use git at work, we use it in a centralized manner, except for those strange odd cases where the ...


2

For a coworker to pull from a git repo on my machine means I need to have a git daemon running at root level as a background task. I am very leery of daemons running on my own computer, or on my company-provided laptop. The easiest solution is "NO"! For a coworker to pull from a git repo on my machine also means my internet address needs to be fixed. I ...



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