Imagine being able to roll back every project change, see exactly who made what edit, and test new ideas without risking the whole system. That’s the power of Git. As a distributed version control system, Git brings accountability, smooth collaboration, and long-term stability to projects of all sizes.

We’ll break down what Git is, why it matters, and how teams like us at Archetype SC use it every day to keep projects secure, flexible, and on track.

What is Source Control & Why It Matters

Think of source control like the “track changes” feature in a document, but for an entire project. Every version is saved, so nothing is lost and no update is ever final until the team decides it is. With source control, teams can try new ideas, edit side by side, and still know they have a clean, stable version to return to if something doesn’t work out.

Instead of juggling endless file names like Final_v2 or Project_Updated_REAL, everything lives in one system with a clear history of who did what and when. Unlike cloud storage tools such as OneDrive or Google Drive, which offer limited version history and aren’t designed for branching, merging, or full-project rollbacks, Git tracks the complete project history across branches and makes restores predictable. That means if something breaks, rolling back to a working version is quick and reliable, turning potential setbacks into small course corrections.

What is Git & How It Works

Git takes source control a step further by making it distributed. Instead of one central file that everyone checks in and out, Git gives every team member a complete copy of the project on their own computer. It’s like giving every person in a study group the entire textbook instead of just one shared copy, everyone can work independently, make notes, and test ideas without slowing anyone else down. When changes are ready, they’re synced back into the main project so the whole team stays aligned.

Originally developed in 2005 to support Linux, Git has since become the industry standard for version control. Today, platforms like GitHub, GitLab, and Azure DevOps make it easy for teams around the world to collaborate on even the most complex projects. We build most of our projects in Azure DevOps, since it integrates seamlessly with our Microsoft accounts and helps us collaborate effectively while keeping changes organized and secure. This ensures consistency, accountability, and a secure foundation for development. Many of our clients are fully integrated into the workflow where changes can be pushed to Git and then built and sent to their productive environments.  The team constantly works on new features, bug fixes, and pipelines. Git makes it possible to manage all those updates in parallel without breaking the main project

Best Practices & Business Benefits

Beyond storing versions, Git creates a framework for working smarter and protecting your projects. Following best practices makes all the difference:

• Commit changes often so work isn’t lost
• Avoid putting sensitive credentials into repositories
• Keep the main branch clean by testing features separately
• Use tools like .gitignore to filter out files that don’t belong in the code base

These habits keep projects organized and reduce the risk of costly mistakes.

For businesses, the benefits go beyond the technical side:

• Smoother collaboration across teams
• Faster time to market
• Stronger safeguards for intellectual property
• A structure to scale as projects grow while maintaining security and accountability

For companies without the in-house resources to manage these tools, a trusted partner can help. Our Managed IT Services and Cybersecurity Services support clients with the right systems, monitoring, and governance to keep projects running securely.

Conclusion

Git brings order to complexity by ensuring version control, accountability, and collaboration, three essentials for any modern digital project. Whether you’re a developer writing code or a business owner overseeing growth, understanding Git means recognizing the invisible framework that keeps projects secure, stable, and moving forward.

At Archetype SC, we rely on Git and Azure DevOps to deliver reliable, scalable solutions every day. If you’re ready to strengthen your workflows and protect your business from costly setbacks, connect with us to see how version control can support your goals.

If you are wondering what Bimodal is, it’s a term used recently by Gartner to describe two different and complimentary facets of IT organizations.  Mode 1 is traditional IT, where systems must be reliable, predictable and safe. Mode 2 is non-sequential, emphasizing innovation, agility and speed.

IT organizations need to have both modes of operation if they have any hope of responding to the pressures coming from the business. Social media, cloud computing, mobile, analytics and big data, and the internet of things are top of mind for business leaders.  They know they need to be leveraging these technologies in the business, and need to do it now.  Mode 2 IT is required to address these priorities in a fast and agile way.

In a Gartner survey, 45 percent of CIOs state they currently have a second fast mode of operation and, by 2017 they predict that 75 percent of IT organizations will have a bimodal capability.

So is your IT organization Bimodal?  If not, Gartner warns that the business will not wait for you to put mode 2 into operation.  Shadow IT occurs when an area of the business develops and deploys an IT solution outside of the IT organization.  Shadow IT projects have been occurring for some time, however the frequency is increasing with the business pressures described earlier, and when the IT organization has no capability to address business needs with agility and speed.  Shadow IT, done independently from the IT organization, can lead to security and integration issues that IT will inherit when issues arise.

Archetype SC brings speed, agility, and innovation to our customers.  Let us assist you with your move to Mode 2 IT delivery.

 

If you have children or grandchildren like me, you’ve probably heard these questions on multiple children’s TV shows where the characters set off to solve some incredible mystery. They ask these questions to figure it out.   One of the shows, I think The Electric Company, has a very cute song that repeats these questions over and over as the characters work to figure out the mystery. I chose to not research this and verify which show it actually is.  I never want to hear that song again, since this is one of those songs that when it gets in your head, you can’t get it out.  If you listen closely, you can hear it playing in my head right now. 

In fact, it is so embedded in my brain, that when I was reading a series of white papers on how to gather and manage system requirements, it immediately popped into my head.

Here’s what triggered it. 

“Good requirements need to be concise and specific, and should answer the question, ‘what do we need?’ Rather than, ‘how do we fulfill a need?’”*

This requirements gathering advice is not new, been around almost as long as I have.  Even kid’s know about it, except they really need to leave off the “how”.  The who, what, when, where, and why are right on target though.

This approach is so fundamental, that all the good requirements documenting practices and tools don’t matter, if the requirement is constrained by how that requirement is to be fulfilled.

If you are looking for someone who is a proficient in asking what and why, and will steer you away from the pre-conceived how, contact Archetype SC.   We’ll design and build your new system focused on what you need to accomplish your business objectives, not how you do things today.

 * Requirements Management 101, White Paper published by Jama Software

I recently spent time thinking about a software development project I’m managing that had me a bit puzzled.  This is first time in my long experience in project management where there is absolutely no pushback from anyone in the business regarding the project.  No one is questioning the reasons to do it, the scope, or the approach.  The organization is clearly aligned and committed to getting the project done.

I’ve managed software projects for multiple fortune 500 companies, with 8 figure budgets and project teams of 100 plus members.  There has invariably in every project been an individual or group that was either passively or actively opposed to the project.   That is not the case in this project, so what is different?

I reviewed the “Top ten reasons why projects fail” lists to see if there were any clues to why this project is so different.  I’d not looked at any of these lists for some time, and found it interesting how many different variations there are.  The top two on my personal list are having a clear and well defined business case, and the importance of executive sponsorship for the project.  My most difficult projects have been those where the business case was ill-defined and when executive sponsorship was missing.  Most troublesome has been projects where the executive sponsor has changed, or when C-level executives, who are major stakeholders change.  In these situations the business case is often questioned by the new leadership and executive support can disappear. When executive support wavers, passive resistance can turn active quickly.

Below is just one of the top ten lists I came across in my review, and number 1 and number 9 in this list match my personal top two.

The current project that breaks the mold with no one opposing the project has a business case and executive support, much like the majority of the other projects I’ve managed.   Even with these in place, all the other projects still had a level of resistance.

So why is everyone across this business on board and actively supportive?

The conclusion I’ve reached is that it must be the “pain factor” that has everyone aligned.  The system that is currently in place is very old and lacking in functionality.  Business processes are very manual, error prone, and labor intensive.  The pain in using the current system is widespread across the organization and constant.  The entire organization is supporting the project that will ultimately make the pain go away.

My personal list of things that impact the likelihood of project success or failure now has a third major consideration, the pain factor.  The higher the pain factor and the broader it is across the organization, the more likely the organization is to rally behind the project that will make it all better.  Conversely, a project that is not going to impact the organization by relieving a painful situation, may not have as high a likelihood of success, even if there is a strong business case.  When the pain factor is low, all the factors on the top 10 lists become more important.

Successful projects don’t just happen. They require attention to all the factors that can cause projects to fail or not deliver a quality solution to the business. Archetype SC can work with you to identify your top ten risks and the strengths of you organization that will mitigate these risks and insure success in your project delivery.

WHY PROJECTS FAIL – TOP 10 REASONS

Excellent Project Management post by Tom Tsongas.  January 13, 2014.

1. Lack of a Project Charter

• The Project Charter is essentially the ‘what’ portion of the criteria of the project. It dictates exactly what is being built, created or enacted and explains in high level terms the various justification and initial scope for the project.

2. Lack of User Involvement
3. Poorly Defined Requirements (Poor Scope Definition)
4. Scope Creep
5. Inadequate (or non-existent) Testing
6. Lack of Resources
7. Use of New or Unfamiliar Tools
8. Political Infighting

• It exists in companies as well as governments. Functional managers and executives with their own vested interest in specific aspects of the business can often come to blows over new or existing projects.

10. Poor Project Management