Git Reviews

We use Git for version control for programs. 

To have programming projects and keeping track of the copays is always it's always nice to have to be able to reverse changes if they don't work.

I am doing my CV and I am also tracking it with GIt.

I believe it is beneficial to maintain a detailed log or history of who did what to a project and which user committed to the change.

The program is run from your shell and I am comfortable with that.

You have Git Lab as a platform, which is just Git with a web interface. I believe that is already well integrated.

More security is always welcome in my opinion.

I have been working with Git for two years. I use it occasionally.

I am working with the most recent version.

I would rate the stability of Git a ten out of ten.

In my opinion, Git is a scalable solution.

It is used for Linux, which I believe is the largest open-source project we have running right now.

I don't believe they offer technical support.

I have used Confluence and Jira from Atlassian.

The initial setup is straightforward. You initialize the repo in your code base, and you start committing changes.

It doesn't take very long to deploy it, a few seconds. It's a single connection.

It can be deployed by anyone who is using it.

Git is completely free.

I would definitely recommend using Git.

My advice to others is that it is a good idea to read the manual.

I would rate Git 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 Git for our code. 

It is a pretty standard product with features like git clone and development branches. 

Git is mostly command based and needs to have a helpful user interface. 

I have been working the solution for the last three years. 

Git is highly stable and I would rate it a ten out of ten. 

The solution is highly scalable and I would rate it a ten out of ten. My company has 500 users for it. We use it on a daily basis. 

We don't connect with the support team since all the information is available on the internet. 

We switched to Git because it supports multiple vendors. 

Git's setup is easy and I would rate it a nine out of ten. There are documents available with plenty of information. Hence, if there are any issues, you can sort them out. The tool's deployment is fast. 

We did the product's deployment in-house. Users can do it by themselves.

Git is free and you don't have to pay for it. 

I would rate Git a nine out of ten. 

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'm doing little projects to teach myself things and storing them in a Git repository. We have about 20 users at my company. We're open to using it more.

Git is a product everyone uses, so it's almost inescapable. I like the fact that there is a large ecosystem around it. You can bolt various graphical user interfaces onto it or sign up for various repositories like GitHub and AWS CodeCommit. Git has a large community, so there are lots of resources and knowledge bases you can use. 

I have used Git for about three years.

I rate Git seven out of 10 for scalability. The scalability could be better. I think it requires some discipline to have large teams working on the same project without facing problems merging code. I'm using Git for personal projects, but I know companies face merge conflicts when more than one person is working on code simultaneously. 

Git is easy to set up. I've done it multiple times on various systems, and it only takes a few minutes. 

I rate Git eight out of 10. 

Version control and repository management are the main use cases for Git.

The repository management and check-in/check-out commands are the most valuable features for ensuring secure code. It's a client-side tool that we install in our local company and connect to the cloud product for use cases.

It should be more user-friendly. Git provides important commands for projects. It's not very user-friendly, but it's okay.

I have been using this solution for one year. We're using the test version. It's integrated with TSS.

There are 50-60 users in my company. We use it based on the use case.

It's straightforward. It takes around ten to fifteen minutes to set up.

The deployment can be done in-house. The deployment process is good but there may be a learning curve for some users. However, it could benefit from additional hands-on experience, particularly for enterprise-level usage.

Overall, I would rate it a seven out of ten. I prefer using other tools that are more user-friendly.

I use Git to store our code and maintain different versions, and for some projects, we use CI/CD as part of GitHub.

We centralize all our code in Git, which makes it very useful. Having the code centralized means we can easily access it and control its version efficiently.

The best feature is that we can access it from anywhere if we have GitHub credentials. There is also a private option where our code is accessible only to our organization. Additionally, if there are issues with a local machine, the code can be pulled from GitHub anytime, anywhere, which is another great option.

There is nothing that could be improved at this time.

I have been using Git for almost three years now.

Git is very stable. It never breaks down.

I never had to contact the Git support team for any reason.

The initial setup is easy to use. Anyone who needs version control systems can use it.

I would recommend Git to other people. I'd rate it nine out of ten.

The most used case for it is managing code versions when working on a project with many developers. After we merge it, the dash is merged in the master dash. Next, when we merge its branch to replace it with the master and resolve conflicts, we collaborate to finish the project.

Code versioning, for example, we work in the branch and want to come back to this branch another time.Git is a very useful tool, helpful to collaborate with other members in the group to finish more rapidly our work.

About the configuration it is a little bit difficult, it can be improved.

I have been using the solution for the last two years.

It is a stable solution. Never faced any bugs or glitches. I rate the stability of the solution an eight out of ten.

It is not a very scalable solution. It is not a good experience to manage large scalable products. I have moderate experience in managing large projects on Git. One thousand users are using the solution regularly. I rate the scalability of the solution a seven out of ten.

The initial setup of Git can be difficult but once you master the solution it is a useful tool and works on many difficulties by rapidly completing the task.

I advice everyone to learn about Git as it is a very useful solution and help in working on projects more rapidly which otherwise would have taken time. I rate the overall solution an eight out of ten.