Git Reviews

Our primary use case is source control and code checking. We used it as version control for collaboration projects. The most important use case is being able to look into the code. Somebody can publish the code publicly in a standard format, which organizes the standard format of code. Then, the team follows the structure of the README file and the code structure.

I also used this solution to make my resume stand out.

What I find the most valuable about Git is that it is CLI and GUI-supported. People who do not like using the CLI mode can use the GUI mode. The solution also now comes with the VS (Visual Studio) code. The ID comes with the Git adapter. This is handy, that is why there is wide adoption of Git.

We have had a mixed reaction to the newly-introduced code pilot. It improved the coding but was also gave too much to the AI and people are concerned that Git Copilot could result in a lot of job losses.

I have been using Git for four years.

I would rate the stability of this solution a 10, on a scale from one to 10, with one being the worst and 10 being the best.

I would rate the scalability of this solution a 10, on a scale from one to 10, with one being the worst and 10 being the best.

Prior to Git, I used TortoiseSVN.

I would rate the initial setup process a four, on a scale from one to 10, with one being the most difficult and 10 being the easiest. The reason for this rating is that once there are conflicts, it takes a lot of effort to resolve them.

For the people looking to use this solution, I would say, go through some of the basic videos and learn the basic commands to get started and then explore more of the features. Get some hands-on experience and collaborate with others to find out more about the solution. 

Overall, I would rate Git a nine, on a scale from one to 10, with one being the worst and 10 being the best.

I use Git for version control. It helps us to distribute development and manage source code. 

The tool's most valuable feature is branch workflows. 

I believe there is room for improvement in preventing work loss due to conflicts or overwriting. Another area for improvement could be implementing features for automated code verification within Git. 

I rate the solution's scalability a seven out of ten. My company has eight developers using it. 

I haven't contacted the tool's technical support. 

I would rate my experience with the initial setup of Git as a seven or six out of ten. It has clear documentation and takes one or two hours to deploy. The deployment process involved installing Git, creating a project in Git, and configuring it with administrative privileges. Then, the steps included preparation, conversion, synchronization, and migration. This set up the repository, allowed for safe changes, and enabled inspection of the repository.

I rate the tool's pricing a five out of ten. 

I can provide support and control over the development teams, such as developing scripts for managing code or administering Git repositories for all members. However, we may need an extra week or two for additional training.

According to my opinion, every programmer should use Git. 

As a student, I used Git to store my source code and versioning. Whenever I do modifications, I can roll back the session if needed. It's the same at work, but we use Git to store documents. 

I like that it's easy to use and because it's accessible from a terminal or a graphical user interface if needed. I also like that we can pass comments from Linux if required.

Synchronization could be better. Sometimes when you create a branch and merge it into another branch, I think it's a bit complex for no reason. The initial setup is also tricky when you do it for the first time.

I have been using Git for almost ten years.

Git is a stable solution. I have never had a problem with this solution.

On a scale from one to ten, I would give Git a nine.

I think Git is scalable. We were always a team of five to ten members, but I think it can handle more. We are an engineering company, and half the company uses Git.

The initial setup is a bit complex if you're doing it for the first time. It also depends on what you're trying to do. If it's just to push code, it's straightforward. But when you have to manage a big project, it can get complicated. For example, you must get information from other branches after setting up your branch. When you merge data, you must ensure you do not touch all this information. Deployment time depends on the project and its scalability.

The deployment steps include creating an account, changing your key, synchronization with the project, creating your branch, and creating your own files and modifying them.

Other members of my team and I implemented this solution.

As a student, I didn't have to pay for the license.

I would tell potential users to read the tutorials and guidebook to understand Git and start doing things inside. You can quickly merge and create branches and versions. You have to be trained to use Git; then, it's easy.

On a scale from one to ten, I would give Git an eight.

We primarily use the solution for version control. We use it to control the development version. We use it for scripts or whatever we are deploying. 

The solution allows for very good version control while coding. We can ignore certain versions and create branches out of exactly what we need. 

The repository is great. We can look into it first before creating versions. 

It works with Unix. 

Once we change things, we can test it locally very easily. 

The initial setup is very easy.

It is stable and reliable.

We have found the solution to be stable.

The pricing is reasonable. 

The solution works perfectly fine so far. For the last year, it hasn't given me issues. 

I've been using the solution for one year. 

It's been stable and reliable. There are no bugs or glitches. I'd rate it eight out of ten. It doesn't crash or freeze. 

The solution can scale well. I'd rate the ability to expand eight out of ten. You can expand it easily. 

Most people are using it in my organization. 

We primarily use GitHub. Now we are using Git for version control. 

The initial setup is very straightforward. It's not complex at all. 

You can pay for a subscription. It is an affordable product. 

I'm an end-user. 

I'd recommend the solution to other users. Both Git and GitHub are very useful for development. 

I would rate the solution eight out of ten. 

Git is used for downloading stuff and tracking purposes. It is very simple. In short, I use Git for tracking changes in the computer, which is very simple.

It's a tool for collaboration, and that's what we use it for in our company.

The main problem for me is the frequent upgrades in the solution because every other upgrade is a minefield. When you do the upgrade, there is always something that doesn't work. We have to spend days to correct it. Then, we stop all updates, and we do the updates in six months or a year. There is always a problem, especially if you do an update, since after that, some libraries don't work. We then spend a lot of time trying to fix it. Therefore, the frequent updates are really, really terrible. The aforementioned area can be improved.

I have experience with Git. Also, I don't remember the version of the solution I am using.

It is a stable solution. Stability-wise, I rate the solution a ten out of ten. I may not probably be the right person to evaluate the tool.

Since I am a very simple user of the tool, its scalability is good for me.

In my company, two or three people use the solution.

It is not an extensively used tool in my company, so there are no plans to increase its usage.

I don't need any technical support because one of my colleagues provides the technical support. He had done the setup of Git, and we just used it. If there is some problem with the new version, he will do the setup, and that's enough for me.

I wasn't involved in the setup.

I just tried to use the solution for what I needed.

I would definitely recommend the solution to those planning to use it.

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

The features I am most impressed by is the automation, and when we do the pull requests, everything gets indicated on there in terms of the deployment steps and full-on automated deployment. We have found that the standard level for DevOps in terms of automated deployment is 30 minutes. So we actually hit that in 30 minutes, which was great.

I would like to see an improvement in the way the product owner can review changes and so forth. But I believe there are licensing costs related to that. It would be better to keep everything simple with one standard license fee.  

There wasn't any instability at all because when we did our first automation deployment, we hit 100% with zero bugs introduced. That was really, really good. I just think we must get the automated testing right. We don't have that many seasoned automated tests and therefore we did all the full-on regression testing that was needed, went into production and had zero defects.

We have about 40 to 50 users and 12 testers, and so far it has been very scalable. We plan to increase our usage in the future.

We have monitors in place for our usual business so if anything goes down, there is an immediate response to look at that from a proactive perspective to see what is affected. In terms of from a testing perspective, through change, it is a database issue or anything like that. In terms of support, we have two sections of support. One for terms of DevOps where we have a operations person responsible for this. And when we put the software into production, we have someone on standby to ensure that everything is in perfect working condition. 

There are other options in the greater part of our environments. But since we were working on Microsoft from the start, it just was easier to continue that way. It was a new department being established and we wanted to start off that way, rather than moving from an old state to a new state. It takes longer and the change management is greater.

Our technical team will be able to tell you exactly, but I believe they found some problems around the installation and so forth. I do know that it took them a while to actually get the automated deployment right before they could actually execute it. Perhaps the developers can make it easier in terms of getting readiness for automation deployment. It was quite complex and it took us about a day and a half. However, if you do a manual deployment, it doesn't take that long.

My advice to others would be to implement it correctly and do whatever your unit test brings back in terms of an approach. Fix that first and then start with your coding. That is how you ensure quality.

I would say that you should start afresh. Instead of trying the squad branching, do the release branching, and work from there. Don't be wary of actually starting on DevOps. Sometimes people are wary of the unknown but it adds a lot of value if you go with the CDCI approach. 

It is a great product and my rating is eight out of ten.

We use the tool to store codes. 

Our team members can work together and save the code in a single repository. 

The product needs to improve its UI. 

I am using the tool for four to five years. 

The product is stable. 

My company has more than 1000 users for the solution. 

The software's technical support is good. 

Positive

The product's initial setup is easy. 

The tool is an open-source product. 

I would rate the product a ten out of ten. 

We use Git for the desktop to maintain some versions of the codebase.

Git is easy to manage, which is one of the main features. Also, the codebase is a major feature. It is helpful for me and easy to manage the interface we are using from development to production. So we manage the versioning of codebases.

The price is an area that needs improvement.

The process of raising a pull request could benefit from some improvement. Currently, when a pull request is created in an organization, a branch is also created. However, each pull request must be individualized to a specific branch. If another person raises a pull request under the same ID assigned to the previous person, and both parties modify the tool, their changes will be grouped together in the same request until it is closed, which is an issue. Therefore, it would be beneficial if pull requests were individualized to each user so that any modifications made are attributed to the specific user's pull request.

I have been using Git for a year. Also, I don't remember the version of the solution I am using.

Stability-wise, I rate the solution a nine out of ten.

Scalability-wise, I rate the solution a ten out of ten.

The solution's initial setup process was easy. It is also easy to get the data. So, even though there are a large number of files, it's easy to clone and get the data details and codebase easily.

The organization looks into the pricing aspects of the solution.

I would recommend the solution to those planning to use it. I rate the overall tool a ten out of ten.