New answers tagged

0

What should we be considering in order to make this decision? You should be considering the downsides. I (along with others) successfully encouraged my current employer to stop hosting the company's crown intellectual property jewels on a private github repo. Don't take me wrong; github is fantastic for open source software. In the case of closed ...


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


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


16

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


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


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


0

The Android Open Source Project almost exactly mirrors the case I used in my example: the bulk of the source is under the Apache license, but they use a mechanism equivalent to Git submodules to deliver the GNU toolchain.


-1

Simple: Companies are centralized organizations, with centralized workflow. Every programmer has a boss and he has his boss, etc up to CTO. CTO is the ultimate source of technical truth. Whatever tool company uses, it must reflect this chain of command. A company is like an army - you can't let privates outvote a general. GIT offers features that are ...


0

Complexity: With a central repository, a typical work flow might be branch off from the central master branch change the code test possibly go back to changing the code commit merge any new changes from the central master branch test possibly go back to changing the code merge changes into the central master branch and push The complexity with respect ...


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


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.


0

My old answer on this question works. But since that time our process has improved significantly and we have incorporated automated deployments so now I would say.... We now have two week iterations but deploy new functionality as fast as we get changes made, reviewed, and tested instead of waiting for everything in the iteration. To facilitate this we ...


-3

Maybe it is because he payroll processing is centralized, so we have to keep a central person happy if we wish to get paid. Maybe it is because we are creating one product, so we need a master copy of the software for the customers. Maybe it is because it is a lot easier for a programmer to go to one place to get everyone’s changes, rather than having to ...


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


-1

Several of you have missed an absolutely key and critically important piece of information and it has tarnished the duration of your answer. - GitHub does not force you to be externally hosted - FREE version of GitHub is what puts this restriction in place. There is an Enterprise Version of GitHub available for for internal hosting. ...


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


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


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


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


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


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


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


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.


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


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


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


0

I suggest that you develop your in-house support libraries with the same rigor that you would apply if you were to release those libraries publicly. That is, develop each library as a self-contained project with its own repository, issue tracker, documentation, packaging, build system, testing, versioning and release schedule. If you're the only user of the ...


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


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


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


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



Top 50 recent answers are included