GitHub Reviews

I use GitHub to keep and maintain my code and have version control. I connect with GitHub through an application called GitHub Desktop.

GitHub's version control is valuable. A recent example was when I connected a website with GitHub, which I developed in my local environment on my computer. I kept updating the plugins directly from my computer, and then I deployed the code through GitHub, which reflected directly into the live website. GitHub sped up the development process, and I felt safe because if something went wrong, I could always go back to my previous code, so I wasn't worried I would break the whole website. It is good for developers because they have version control over their code.

Moreover, with GitHub, finding other people's code is easy. There are a lot of users who host their code on GitHub and open it to the public. Sometimes, you can learn from their code or just use their solution, so it's very good for the developer community.

GitHub is good for controlling and managing the code without destroying it.

It would be good if there were training materials for junior developers.

I've worked with GitHub for about three years.

GitHub is stable.

GitHub is scalable. It's just me using GitHub for my code. But if you had a bigger project with a team, you could always invite anyone to work with the code. GitHub is good for teams because everybody can start with one main code and then open their branch to code freely without destroying any other code. However, there should be one administrator who performs tests to combine each code.

I use the free version of GitHub.

Many big companies use GitHub, such as WooCommerce for example. There are a few ways to use GitHub, like through Terminal. I personally like to use GitHub Desktop because it makes it easier for the user. I rate GitHub a ten out of ten because it is very useful. I remember a time before GitHub when it was quite painful to be a developer. If I'd write code and then want to make an update, I would have to save everything in version one, then version two, and continue doing so for newer and newer versions. Then I'd end up wondering which one was the latest because it was so confusing. GitHub made it much easier to check my code and review it.

You can write the code with AI. But when it comes to implementation, you must upgrade the bits of code that will support this and generate solutions based on that architecture. Then, you need comparable code bits. Therefore, AI can propose how much a specific function can be better optimized. So, AI can help stakeholders reach tasks quicker.

I decided not to use GitHub but developed my tool because I found it more efficient. I'm familiar with my tools, making them easier to use. I like being able to customize them to fit my workflow and the way I think.. Software development is like a personal workshop, and I tailor my version control to match my approach. 

You have to do the crazy things to make real changes. Everything stays the same without them. Having a good backup system is crucial. If something goes wrong, you can roll back to a stable state. This mindset drives me to create tools that align with my thinking. These methods aren't easily accommodated on platforms like GitHub, so I prefer to use my tools. 

The solution is the priority, not the specific tools or methods used. For example, imagine you need a simple solution, like a pizza kiosk locator. You're driving and want to find a pizza place quickly. The solution should focus on delivering this functionality, perhaps using Google Maps integration. The key is prioritizing the solution over the technical components.

The solution should allow you to press a button, see the distance to the nearest pizza place, navigate there easily, and even contact them if needed. Companies have resources and processes. The key lies in leveraging these resources to enhance business processes and stay competitive. The primary focus should always be improving efficiency and competitiveness through better combinations and evolution of these processes.

Despite its age, GitHub still holds value, especially in its older functions. However, to maintain relevance and satisfy existing and new users, GitHub should develop newer functions while preserving its traditional ones. This balance would ensure the community's satisfaction and integrate newer features. It seems they're already aware of this need and are working on it, so it's reasonable to expect gradual improvements over time.

The tool is scalable. 

GitHub has become a standard in software development, with millions of users, solutions, and a vast array of software packages and commits. It's reliable, proven, and fosters a strong social community. However, it's important to recognize that not all development processes fit within the GitHub model. In some cases, like ours, we have a unique setup where certain components, like front end and JavaScript libraries, can be hosted on GitHub, while others, like the database, are better managed internally with our tools.

Many solutions are inherently vendor-specific because they reflect the unique way each company conducts its business. These processes often give companies a competitive edge, and they're closely guarded as proprietary secrets. Exposing these processes to a wider audience could diminish that competitive advantage.

Lufthansa, for instance, relies on around ten thousand applications developed in-house and with partners to run their core business operations. 

Similarly, as a competitor in Formula One racing, Ferrari undoubtedly has closely guarded secrets contributing to its success.

SAP encountered issues with its approach to creating minimal solutions for small and medium-sized businesses (SMBs). While they intended to cater to smaller companies, cutting functions led to a loss of value, making it no longer truly SAP. Similarly, many large companies adopting out-of-the-box SAP solutions found their processes becoming standardized, causing dissatisfaction. Companies wanted their unique processes preserved, not homogenized like competitors'.

I rate the overall product an eight out of ten. 

The solution is used to store code. It is a repository manager for our code. We can also configure it to run our deployment.

It is a good product. The tool doesn’t incur a lot of cost. It is highly stable. We can easily integrate our deployment to achieve continuous integration and continuous delivery.

The product must document the CI/CD process more. It must also expose the APIs for CI/CD.

I have been using the solution since 2016.

I rate the tool’s stability a ten out of ten. It is highly available. I have not encountered any issues.

I rate the tool’s scalability a ten out of ten. I have not encountered any issues with the scalability. I am using the tool for my personal projects. If I needed someone to collaborate, a maximum of five people would have access to the tool. I do not have plans to increase the usage for now.

The solution is cloud-based. I do not have to deploy it.

Our code is secure. We can easily roll back the changes. We can take features to the market a bit faster.

It’s an open-source solution. We do not have to pay for it.

I will recommend the product to others. Overall, I rate the tool a ten out of ten.

Our primary use is for open-source code management and distributed version control. We use the solution to coordinate the work of developers, assisting them in developing and maintaining our source code. We also use the tool for code review purposes using the GitHub repository, where I can comment on or review lines of code for developers to edit and improve performance. They then receive a notification alerting them of the desired update, which the project developer and project lead can approve.

The best feature is the ability to track the history of all code changes, and it's easy to use. Additionally, as it's open source, anyone can use that feature resulting in distributed development. This opens the door to collaboration with different code and developer, feature, and master branches of development.

The solution also features robust security, high speed, and good integrity.

Excellent code management means that, even when developers accidentally delete sections of code, it's easily retrievable. GitHub reduces developer workload and saves them time.

The GUI design is poor, so I exclusively use the CLI, which is much easier to use and understand. It would be great to see the GUI updated to be more user-friendly. 

It isn't possible to run different branches simultaneously, and it would be good to see support for that.

We have been using GitHub for over seven years. 

GitHub is very stable; we can use it throughout the development process.

The solution is highly scalable. We have between 100 and 150 end-users, both developers and testers.

We haven't encountered an issue we couldn't fix ourselves or by using Stack Overflow or Google, so good community support is available.

The initial setup is very straightforward; creating a repository and the paths required for local and other branches is easy.

The deployment time depends on the project size. We follow an agile sprint cycle so we can carry out new deployments every one to two weeks, and they don't take much time at all.

GitHub is an open-source application. It's free to use.

I would rate the solution an eight out of ten. 

We use GitHub because it's open source and makes code management straightforward; it's simple to track different code versions and change history. It's an easy-to-use, efficient application.

For someone looking to use the solution for the first time, I would say it's straightforward and possible to learn the significant features in a day. Learning to clone projects, push and pull code, and use comments is simple.

We are using GitHub as a repository for a couple of customers to be able to do Infra as Code in Microsoft Azure for them.

The most valuable features of GitHub are the ease of integration into Microsoft Azure DevOps. The process that you need to deploy into Microsoft Azure becomes fairly simple and the templates are already available, a lot of the engineers find it easier to use.

GitHub could have better integration or capability with other solutions.

I have been using GitHub for approximately four years.

GitHub is highly stable. Our team has not had any trouble with it.

The scalability of GitHub is good. I have not come across any limit.

We have six people using this solution in my organization. We have plans to increase usage.

I have not used the support from GitHub.

The initial setup of GitHub is simple. The full implementation took approximately a few hours. There was some user configuration that took some time.

We did the implementation in-house for GitHub.

 The licensing model from GitHub is very clear.

I recommend this solution to others. There may be some customers that are very picky about not having code on the cloud, and then my recommendation would normally be to use Microsoft Azure Repos, which is essentially a clone of GitHub but it stays within your subscription and within your tenancy on Microsoft Azure.

I rate GitHub a nine out of ten.

GitHub's workflow is smooth, and it integrates seamlessly with outside projects and libraries. It simplifies our entire development flow.

GitHub's source code management is top-notch. It's easy to inspect changes and visualize code and differences. Their action system is comprehensive in terms of making changes and automation.

GitHub's issue management could be improved a little from an organization standpoint. It would be helpful to have the ability to organize a work board or a backlog more comprehensively. For organizations migrating to GitHub from arbitrary systems, it's a little bit of a headache to move on to that system.

I have been using GitHub since 2009.

We've never had any performance issues with GitHub. I don't think we've had an outage yet and we've been on it for a number of years now. 

GitHub is extremely scalable. We only have about half a dozen repositories in there, but I know some organizations with hundreds working without issue. We're using it extensively. Everybody in the organization is using it, but it's fewer than 50 because our organization's pretty small. We'll increase usage naturally with time, but we're almost close to 100 percent, so it's hard to really increase usage at this point.

I read the documentation, but we haven't had any need for tech support.

We were using Azure DevOps previously, and we switched to GitHub primarily due to cost. The automated build platform is costly on the Azure DevOps side but significantly less expensive on the Azure side.

Setting up GitHub is extremely simple. You create an account in five minutes and have your first repository set up in another two after that. You're up and going in under 10 minutes.

It's a lightweight solution. The only maintenance is usually related to active stuff that we're doing on the platform. I wouldn't classify that as maintenance. That's product improvement.

We are a step above the base package. It's not the enterprise package. We're using the teams or the organization package. It has a few different names.

I rate GitHub nine out of 10 for overall ease of use and completeness in functionality.

Currently, the solution is our source control system. We manage the DevOps pipeline for the company and it's the version control backbone.

I'm curious as to what DevOps Tools can be integrated into GitHub to get it to be on part with the capabilities that come out of the box in GitLab, or whether we should just switch to GitLab to get all of those capabilities.

The stability is quite good.

The scalability is excellent.

We've found the technical support to be very helpful.

Overall, it's a very good product.

If it had all of the end-to-end integration, then we probably wouldn't have any doubts about what we have installed. However, at this point, we're still trying to figure out how to use it end-to-end. 

The new version is supposed to make GitHub actions available to us within the on-prem instance. We're waiting for that, just to see how that plays out with the rest of the source control features and to see if that gives us some semblance of similar capability to what GitLab supposedly provides.

I don't know if there are any plans to do a better integration with the front-end type of tooling. I would like to see it evolve to a full-blown DevOps stacks hopefully similar to GitLab at some point.

We've found the way licensing is set up to be very challenging.  Also, the LDAP sync capability falls over frequently due to the complexity of our LDAP domains.  This requires us to perform manual LDAP syncs almost on a daily basis

I'm new to the company. That said, I would guess that the company has probably been using the product for about three to four years at this point. It's been a while. I've used it within the last year and I'm continuing to use it regularly.

As far as stability goes, it's been good. We haven't really had a lot of major issues yet. There are no bugs or glitches. It doesn't crash or freeze.

It's obviously very scalable. We have thousands of users on it and there are no concerns.

We have a monthly call with the technical sales folks. They look after our every need and they're very technically knowledgeable as well. If we go through support, usually issues are resolved fairly quickly. There are no complaints there. We're very satisfied with the level of support on offer.

I just manage the team. I've not involved in the more technical details. I wasn't present for the implementation process. I can't speak to how easy it was, or how difficult, via any first-hand knowledge. 

The licensing model that they have is annoying. One of the things that we struggle all the time with is people that have left the team or the group. We have lots of application teams that are using GitHub. People are moving constantly between organizations, they're moving to different teams, they're moving out of development. 

There's really not an easy way to track who's still using licenses. If they've vacated the position unless somebody goes back into the active directory and actually removes them from the group, they're still holding onto a seat and we're still trying to figure out, how to manage this so that their seat automatically gets reclaimed when people are moving around and it's not a very straightforward process. It takes a lot of effort on our part to try and keep the inventory seats available and managed properly.

We aren't partners. We are simply customers and end-users.

We are still on the previous version. We are still waiting for more stability from the latest version before we update everything.

It's a great product. That said, it needs some work still to be able to do everything that GitLab can do, for example. I'm not sure what the future plans are for GitHub. I know they're working on adding a lot of capabilities now that they're part of Microsoft. They're probably going to make it a much more robust solution - not just a version control system. My perspective is as an enterprise on-prem user. I don't know from an open-source community standpoint, how they feel about the changes. I'm sure most of the users are pretty happy with it as a hosting platform. However, my need is specific to my organizational uses.

I'd rate the solution at a seven out of ten.

We use GitHub to track what kind of libraries you are using.

The most valuable feature of the solution is the version control field. GitHub has a good integration and coding engine.

It would be beneficial if GitHub provided some security scanning for new libraries to ensure that there are no viruses in it. The solution’s stability could be a bit better.

I have been using GitHub for two months.

I rate the solution a seven out of ten for stability.

Around 30 users use the solution regularly in our organization, and we plan to increase the usage.

I have previously used Bitbucket.

The solution's implementation takes a long time.

We pay a licensing fee for GitHub, which could be cheaper.

The solution is deployed on the cloud in our organization. I would recommend the solution to other users. GitHub is a version control, and you can always switch and text because every version is saved.

Overall, I rate the solution a seven out of ten.