Bitbucket Server (formerly Stash) from Atlassian was a self-hosted source code management solution. The product is no longer available for sale, and support for existing licenses ended in 2024.
Bitbucket Server (formerly Stash) is suitable for departments or teams with the capacity to manage and support their own products and the availability to implement the tool on their own infrastructure. Bitbucket Server (formerly Stash) enables a good framework based on git to integrate the development cycle and to handle anything from a minor group of users and repositories to an extended usage with multiple users and roles collaborating in different projects.
Git is by far the best Source Control Management Tool I've used. I would recommend it to anyone, whether it's an individual working on their own project, a small start-up company, or a huge organization with thousands of developers. Maintaining code via source control is absolutely mandatory for all developers everywhere.
Projects & Permissions - Stash keeps you and your developers productive by providing a way to structure your repositories and manage permissions via a simple, yet powerful user interface. Stash is very easy to use, manage & administer.
Essentially Stash gives two versions of interfaces to work with.
Stash Repository hosted on a server.
Atlassian SourceTree.
Atlassian Sourcetree is a tool to work with a code in stash. The two 'web' and 'desktop' versions make working with code user friendly, intuitive and comprehensive.
Connectivity to JIRA - Stash keeps track of all issues associated with commits. Users can use Stash to quickly see all issues associated with a commit, or use the Source tab on JIRA issues for an aggregate view of all the code changes that are related to a specific JIRA issue. With this information available, your development team saves time when tracking particular bug fixes or improvements.
Git is designed to work in a distributed manner, allowing each developer to run a local node that has full control of the project. Through this, the developer is able to merge his work with others on a main 'branch' & work in sync without having to worry about stepping on your other developers toes.
Because Git has solved the software problem of dependency, users who commit code that needs to be deleted can just roll back to a restore point, saving precious development time & tons of headaches for Information Technology. This is also very helpful when cloning projects or creating new features on the current project.
Git has a beautiful command line interface that is intuitive, easy to learn & extensible. You can also observe all the changes you have made in your project throughout the development with just a few simple commands. This diverse set of command-line tools is easy for the end user & very powerful.
You can't allow users to create new repositories without them being full admins of a whole project
There's not a way to limit who can merge a pull request (e.g. allow only the author to merge) outside of branch permissions
Some settings like default reviewers can't be easily copied to different repositories (without setting default reviewers at the project level, which we don't want to do because a single project has multiple team's code under it)
Some of the commands are a little obtuse if you're not using a Git Client
Since Git is so widely used in the development space, it's easy to believe that growth and innovation might become stale in the area of version control. Competition is sparse these days and I'm curious if this "Standard" is going to keep moving forward somehow.
It's hard to fault a tool that is so ubiquitous and hardly gets in your way.
Git has met all standards for a source control tool and even exceeded those standards. Git is so integrated with our work that I can't imagine a day without it.
The usability of its interface is pretty straight forward when it comes to creating projects and repositories, but when you have to dive into finer grained portions of the UI things can get tricky. If you are used to using tools like GitHub or Gitlab -- Bitbucket is just different enough to be a bother.
Never really needed any support as the application is very easy to set up and maintain. Any questions we had were well documented in their online documentation, and community forum.
I am not sure what the official Git support channels are like as I have never needed to use any official support. Because Git is so popular among all developers now, it is pretty easy to find the answer to almost any Git question with a quick Google search. I've never had trouble finding what I'm looking for.
We migrated several of our applications to BitBucket from legacy Team Foundation Server, and the experience has been significantly better. It's easy to use and plenty flexible. Other solutions such as GitHub are also good, but we needed to keep everything on-prem due to constraints around our industry and company, though we are currently re-evaluating whether we can move to something cloud based in the future.
GIT being a widely used tool have better reliability than its peers and have stands out when we compare it on operational performance criteria. GIT with speedy and extensive branching capabilities have helped developers to use check in their code quickly and space efficient way. GIT have the facility to quickly fetch the complete repository on to your local system.
In positive form, having Stash over not having it at all has provided us with a superior repository system over trying to push to some local server instance and manage branches/merging from our local machines.
There are no real negatives to using Stash, its only problem is that there are competitors out there that can offer additional features.
Git has saved our organization countless hours having to manually trace code to a breaking change or manage conflicting changes. It has no equal when it comes to scalability or manageability.
Git has allowed our engineering team to build code reviews into its workflow by preventing a developer from approving or merging in their own code; instead, all proposed changes are reviewed by another engineer to assess the impact of the code and whether or not it should be merged in first. This greatly reduces the likelihood of breaking changes getting into production.
Git has at times created some confusion among developers about what to do if they accidentally commit a change they decide later they want to roll back. There are multiple ways to address this problem and the best available option may not be obvious in all cases.
