Hot answers tagged

221

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


18

As a pro, If your company's office burns down, the code is still on the server. If your company's office doesn't burn down, but the server on which your git repository is located DOES, then you still have a local copy. If you host your repository on your server in your company's office building (like you would with a Network shared drive...?), then if the ...


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.


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


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


9

Obviously its a question of trust in the provider and how much you value your source code. However, I thinks its clear that, at least in the past, people over valued their source code. For 'business process automation' products; where an in house team creates websites and other software specifically for the needs of the business. The value of that ...


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


5

Use git add --patch right after you make the change. Make many small commits whenever you have a meaningful step. Later you can rebase and squash related commits together. It's far easier to use rebase to merge multiple commits into one than it is to split one diff to multiple commits.


3

Your current approach is correct. As you hinted at, you want to avoid fragmentation. By keeping the version numbers consistent across all your repositories, it is simple to roll everything back to a previous version for any reason. Once you start carrying different version numbers, you've introduced one more thing to track. Another way to look at it, is to ...


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

A part of this decision process could be a little testing, trial and error. Take a small project and have a few members try out some of the different sites. This should cover the usability by the team, but there are other considerations. Current Infrastructure - Some companies already have servers, internet connections, VPN, and people on staff with the ...


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


2

I assume that you have a base product, with some customization. A rollout for a specific customer would then be: pull base product from git pull and apply customization from git for the specified customer test in your test environment. The above should all be automated, so once the test passes, push the install out to a server which your technical services ...


2

Most version control systems (VCS) are designed for text. They usually have very powerful and convenient features for comparing (diff) and merging source code, and some tools can even automatically merge changes (and do a decent job of guessing how changes should be merged and at what point the developer should be solicited to do a manual merge). It would ...


1

Here is what I do: Remain disciplined, only make the changes which are applicable to the current working branch. Create a branch off of master called MyDevBranch. Create a branch off of MyDevBranch that addresses a specific functionality/feature (MyFeatureBranch). Make lots and lots of commits... Each time I finish part of a feature that addresses some ...


1

To make installers available to the customer services team: A simple web page providing all the installers for them to download and pass on to customers. To prevent customers installer another customer's application: You could use a simple customer based key either to enter in the installer or in the start screen of the app. The key doesn't have to be ...


1

Here is how I think of it, when it comes to software deployments. Application executables Structural Configuration and default settings Site Configuration User specific data To my mind, only the application executables and and the structural configuration should be managed within the installer - which is then able to be deployed to all sites. Sadly, ...



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