In a recent client project, we needed to mirror a specific subdirectory from our GitLab monorepo to a GitHub repository–complete with version history. This article explains why we chose Git Subtree over simpler approaches, the challenges we encountered, and how we implemented a mirroring solution in our CI pipeline.
Lately we’ve been discussing project versions and tagging for both releases and packaging. This has come up for tags on container images, and we also have developed a couple of Python libraries which we may want to publish to a public repository. While tags on container images have fairly relaxed restrictions, the Python Package Index for example follows a very prescriptive specification for versioning, and ideally we can find a solution that will work for both and is reasonably meaningful and intuitive.
If you’re like me and this is your first exprience coding in the real world, it may take a while to get familiar with Git and GitLab. This may initially slow you down when working on tasks, so I aim to speed up the learning curve by showing some useful features of Git and GitLab. If you’re already familiar, then read on for a good review!
One of the most commonly used version control systems is Git. One should follow a proper workflow to perform the tasks in a efficient and consistent manner. Git was originally created by Linus Torvalds in 2005. Git has a great support for branching, merging, and rewriting repository history. Git is considered to be a standard for software development.