GitHub Reviews

For GitHub, we host our app there, and the code is secured up there in GitHub. We have multiple projects built there. The code is in the GitHub cloud, and we use it as a storage bucket for our codebase that stores our multiple projects and repositories. We use GitHub Actions to automate workflows; whenever we add a new feature to the project or app, GitHub Actions automates testing, deployment, and checks best code practices.

GitHub makes the process really fast for delivering projects, especially when multiple teams are contributing to a single project. It reduces the hassle by having all contributions in a single repository.

GitHub is easy, secure, and widely documented. We use GitHub Actions and Workflows for performing tests and deploying services quickly. It's a well-documented platform with functionalities that other repo systems lack.

GitHub could automate the setup process more, such as creating YAML files for GitHub Actions. The mobile application could be more useful, providing updates on iPhones or Android phones. There could be enhancements to automate branch deployments and other setups.

Currently, I'm working with GitHub. It's been about six years.

GitHub is super convenient and stable, which contributes to its popularity.

GitHub is scalable; I have worked on solutions with tons of features and thousands of branches in a single repository without any glitches.

I have worked with Bitbucket. Bitbucket is useful for creating private repositories, but GitHub is more convenient and vastly documented. It is more widely used and established as a standard.

The initial setup of GitHub is very straightforward and well documented. Even if someone is new to it, they can easily find guidance from online resources.

I have used Bitbucket as well.

While creating repositories, it's important to read all the documentation, especially when setting permissions or creating tokens. Missteps can create problems.

I'd rate the solution ten out of ten.

The tool helps in collaboration with our team on version control, and we're very happy with it. 

I find the most valuable collaboration between our peers to be a seamless collaboration between our peers. We can connect and change our code, allowing us to be agile in our projects. Since we're talking about DevOps, we're using Jenkins in our pipeline. It helps speed up the process by automating the DevOps workflow.

Since most of our work is done remotely, I think GitHub provides a very good collaboration environment.

We want to incorporate management comments within GitHub, making it more like a product management tool. We haven't done that yet. Another change we're considering is migrating from GitHub to Azure DevOps, especially now that Microsoft has introduced it.

Since we are gradually moving to the cloud, everything should be integrated within this environment. GitHub is mostly for on-premises work, whereas Azure DevOps primarily focuses on cloud development.

The tool needs to improve its stability. 

I have been using the product for five years. 

I rate the tool's stability a nine out of ten. 

The solution is scalable because it is a cloud solution and always gives you room for everything you want to add. It is quite scalable and doesn't impose any constraints.

My development team has about five people. However, other teams are also using this tool. As far as I know, there are about 20 teams of five to six people each.

I haven't contacted support yet since we can find documentation online. 

We switched to GitHub because it is by Microsoft and has good integration with Azure.

The setup has a smooth learning curve. After some initial familiarity, our team is working smoothly with it, and we don't have any problems. We have a tool for monitoring the training needs of the companies we work with and providing training solutions. Another aspect is recording what our staff does, functioning as a staff management tool. Additionally, we manage records of our trainees and track their development.

The best ROI is that we are well organized and don't waste time on disputes and similar issues. Everything gets managed. 

The tool offers a free program. As you go, you can upgrade from the community version to the professional one. I believe it costs about ten dollars per person, per month.

I encourage others to use the solution because it is a viable tool. It will improve communication within the team, make all processes more agile, and provide a single central source of truth. A central reference point is crucial to avoid confusion, especially if you have multiple web services.

I rate the overall solution a nine out of ten. Our use of AI involves integrating a copilot within our IDEs, which helps us generate code. Additionally, we use AI strategies to assist in writing reports. We are exploring more AI solutions, and it's still a work in progress, as the technology is quite new. We are finding our path in this area, which is quite challenging.

We use GitHub for developers' deployments and issue management. We follow a Scrum setup, utilizing boards, story-testing tasks, and epics for effective visualization.

GitHub has been very beneficial in visualizing our planning boards, handling big planning items such as epics, and helping us manage tasks and issues effectively.

The ease of the planning board feature in GitHub is very valuable. It allows us to work with different boards easily and effectively visualize big planning items, such as epics.

The query function in GitHub is a bit stiff. They should introduce a query function similar to Jira's JQL for writing complex, nested queries. It’s difficult to write complex queries in GitHub, introducing or, and, and if functionalities.

I have been working with GitHub for two years.

The overall stability of GitHub is high. I rate it an eight out of ten.

The scalability of GitHub is comparatively low. I would rate it a four out of ten.

We have not reached out for technical support, so I cannot rate the customer service.

We used Jira before moving to GitHub. Our trial license for Jira expired, and they did not support us with a free offer, but GitHub does offer free support.

The initial setup was a bit complex and confusing, especially since I was self-learning. It was challenging to understand where to do all the configurations.

We had skilled people familiar with GitHub who drove the implementation. We had a working environment up and running within three weeks and have been improving it continuously.

We moved to GitHub as it supports us for free. We are a tech-for-good organization.

We evaluated Jira before switching to GitHub.

GitHub's simplicity is valuable, but there are some limitations in fields and configurations that could be improved.

I'd rate the solution eight out of ten.

I use it for repositories. We use it for version control and for deployments. We use pipelines in GitHub to deploy projects in Salesforce.

GitHub is much better than similar tools like Bitbucket. It's cheaper, and resolving merge conflicts is much easier.

In complex cases, we have to use the terminal for conflict resolution. If those conflicts could be resolved visually in the editor, that would be much better.

I have been using it 

It is a stable product. I haven't encountered any bugs in the last few months.

It is a scalable product. Every developer in my company uses GitHub, so if my company has 100 developers, then 100 of them are using it.

The initial setup is very easy. 

It's cheaper than Bitbucket. Bitbucket is more expensive in terms of pipelines, which charge based on the time on the Python page in streaming.

I would recommend using it. It eliminates a lot of hassle. For example, suppose you're assigned multiple tasks. You could be working on one task and commit changes to a development branch. If something else becomes a priority, you can switch to that task and commit changes for it. This way, you have backups and can control the versions of your product.

It's beneficial for managing multiple tasks and controlling versions of your product. 

You can commit changes to branches for development, and if something is a priority, you can switch to another task and commit changes for that. 

GitHub provides a backup and allows you to control the versions of your product.

It is easy to learn. I would rate it a ten out of ten. 

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. 

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.

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.

Our customer has hundreds and thousands of applications, and 12 are part of my current project. Three of those applications are using GitHub as a code repository. The rest use Bitbucket. This customer is an Atlassian shop, so only I don't think more than 50 people use it.

Any code they develop will be version-controlled in this GitHub tool, and they use the branching and merging strategy to promote their code. We use it for version control and parallel development.  

The code in GitHub will be consumed by CI/CD pipeline for the build and deployment. We're using the latest version, which has a feature called GitHub Actions that enables CI/CD within GitHub, but this organization doesn't use GitHub Actions. They prefer Bamboo. 

The most valuable aspects of GitHub are version control and parallel development. I also appreciate the forking part, which allows us to release a specific set of features to the environment. 

Development teams can integrate this tool with their IDEs. GitHub provides command line instructions that should suffice. But customers wonder how to configure their IDE because you have to clone the repo, register the username with a password, and then switch. All those things need to be performed within the IDE. So I don't know whether those things are already available. That would enable the developer to integrate their IDEs with the GitHub repository.

The development team pushes the code into a repository, and the CI/CD pipeline will perform the build. We need open-source libraries to perform the builds. It would be helpful to have the ability to link to open-source libraries like npm libraries. I don't know if GitHub Actions provides this. I would like to see that in GitHub Actions if they don't. 

If you know the language for your build, it would be wonderful if GitHub automatically provided the link to those language-specific libraries so we don't need to search for the library. 

For example, if I'm using Node.js, I should be in a position to link it to the npm libraries associated with that version so my build using the CI pipeline will work well. Then the results in the library must go into an artifact repository. We'll have to depend on JFrog or Sonatype to provide binary repositories. Git has the repository technology, so why not offer a binary repository feature?

GitHub has a static code repository; now, GitHub Actions provides CI/CD. The resulting packages should stay somewhere. I don't know whether they have added this or not because I have not explored the GitHub Actions. They're all public libraries, and the result of the build or CI pipeline is a deployment-ready package. Where will we keep them? That's where we need a binary repository.

In addition to the binary repository, I think they could also include some vulnerability scans to ensure the code we deliver is clean. SonarQube is a static code analysis we use. There are tools coming from Fortify or Veracode that can ensure there is no security vulnerability in the code. It's a complete CA practice-related tenant. It would be wonderful if they could add this functionality.

We've used GitHub since 2013. 

GitHub performs well with the current load. I haven't had issues with the tool. 

We've never had an with the number of projects or developers using this tool. We've consistently had around a thousand developers over the years. The load will increase If a customer adds another 5,000 developers, then we may see some ups and downs in the scalability aspect of this tool, but we are all good with the scalability and stability so far.

I haven't interacted with the support team because things are working well and we've never had issues with the platform. 

We used open-source Git and later used GitLab, which is a flavor of Git. GitHub, GitLab, Bitbucket, and Azure Repos are all flavors of Git. The underlying version-control functionalities come from Git, but different vendors have their own flavors. I have experience in all four of these, which are Git.

I wasn't involved in the initial installation, but I installed the open-source flavor of Git, which was straightforward. Enabling the AD or LDAP is the most important thing in the enterprise setup. I have not looked into that because the customer enabled it. I never got a chance to integrate LDAP with the access management system within GitHub.

It's a GAT now. We are using the enterprise edition. I don't use open-source any longer. I have no clue because it's all owned by the customer. We are only consultants in the project, right? So we don't have access to those details.

I rate GitHub 10 out of 10. If you are using GitHub, your development team should define the branching strategy. One popular solution is Gitflow. There are different branching strategies available. You can use the main branch loan and a toggling feature development approach where one branch is sufficient. 

However, people with parallel releases need a parallel development strategy, where multiple branches will come into play. You should consider which branching strategies apply to your current industry and development strategy. Pick one of them, learn, and adopt it in your project.