4 ms·
The nature of git itself obviates your case. If Github gets tumultuous, your redundancy is on your local machine and on every machine of your org. Replication
by beager 8y ago
The nature of git itself obviates your case. If Github gets tumultuous, your redundancy is on your local machine and on every machine of your org.
Replication of issues, wiki, etc to other hosting providers just sounds like a PITA.
If the concern is about Microsoft buying Github and someone gets flighty, I think it’s a little dramatic.
Microsoft isn’t about to rock the boat here, neither is Github.
Expect marginal, fleeting downtime, marginal pricing changes, and generally higher confidence in GH surviving in the long run.
- Latty 8y ago> your redundancy is on your local machine and on every machine of your org *any machine that has pulled recently. There is definitely value in having a mirror that is always live and updating.
- jph 8y ago> The nature of git itself obviates your case. My typical case involves more areas. I value having a way for developers to push/pull changes to a well-known agreed-upon place, as well as to read/post/comment on pull requests, tag/branch/integrate for releases, and always-on always-updating availability. Orgs that are my clients do not have default employee machines that are automatically ready to push/pull to each other. This can be because of a range of technical areas e.g. employee machine firewalls, continuous integration server configurations, disk space storage size for large files, etc. This can be because of a range of process areas e.g. a dev team wants to do a git flow that uses pull requests and code review comments, or a legal team wants an audit trail, or a management group wants a dashboard to do updates, etc.