Skip to content

Git and Patterns for Managing Source Code Branches. Merge BOTs

  1. Git Distributed Version-Control System
  2. Git Releases
  3. Git stash
  4. Git Squash
  5. Git Branches
  6. Git Merge
  7. Git Aliases
  8. Git Rebase
  9. Git and GitHub Backup
  10. Cherry-picking
  11. Git Submodules
  12. Shields
  13. Design By Contract
  14. Git Cheat Sheets
  15. Monorepo VS Polyrepo
  16. Patterns for Managing Source Code Branches (Branching Models/Workflows)
    1. Git Workflows
    2. Trunk Based Development
    3. Feature Branch Development (aka GitFlow)
      1. Git Flow
      2. Git Flow is a bad idea
    4. Trunk-based Development vs. Git Flow
    5. Alternative Branching Models
      1. Feature Flags (Feature Toggles)
        1. Keystone Interface and Keystone Flags
  17. Git Commands
  18. BitBucket
  19. GitLab
    1. GitLab Collective
  20. GitHub
  21. Fake it til you make it
    1. GitHub Lab
    2. GitHub Code Scanner
    3. GitHub Actions
      1. GitHub Actions Marketplace
    4. GitHub Actions and OpenShift
    5. GitHub Copilot
      1. GitHub CoPilot VS GPT-3
      2. GitHub Copilot X
      3. Alternatives
        1. CodiumAI
  22. Gitea
  23. Sapling
  24. Git Tools
    1. Git Credential Manager
    2. Semantic-release. CI/CD semantic release workflow (semantic Versioning, commit format and releases)
  25. Azure DevOps (formerly known as VSTS)
  26. Pre Commit Hooks
  27. Merge BOTs
    1. Tips
    2. Jenkins for git merges
    3. Bitbucket for git merges
    4. GitLab for git merges
      1. Marge GitLab bot
    5. Jenkins-X bots
    6. Plastic SCM bot
    7. Mergify bot
    8. GitHub bots
      1. Bors GitHub bot
  28. Videos
  29. Slides
  30. Tweets

Git Distributed Version-Control System

Git Releases

Git stash

Git Squash

Git Branches

Git Merge

Git Aliases

Git Rebase

Git and GitHub Backup


Git Submodules


Design By Contract

Wikipedia: Design by contract (DbC), also known as contract programming, programming by contract and design-by-contract programming, is an approach for designing software.

It prescribes that software designers should define formal, precise and verifiable interface specifications for software components, which extend the ordinary definition of abstract data types with preconditions, postconditions and invariants. These specifications are referred to as “contracts”, in accordance with a conceptual metaphor with the conditions and obligations of business contracts.

Git Cheat Sheets

Monorepo VS Polyrepo

Patterns for Managing Source Code Branches (Branching Models/Workflows)

Slide: 10 git anti patterns. Click to expand!

Git Workflows

Trunk Based Development

Feature Branch Development (aka GitFlow)

Git Flow

Git Flow is a bad idea

  • Feature Branching considered Evil
    • youtube: Feature Branching is Evil (Thierry de Pauw, Belgium)
    • Feature branching is again gaining in popularity due to the rise of distributed version control systems. Although branch creation has become very easy, it comes with a certain cost. Long living branches break the flow of the software delivery process, impacting throughput and stability.
    • This session explores why teams are using feature branches, what problems are introduced by using them and what techniques exist to avoid them altogether. It explores exactly what’s evil about feature branches, which is not necessarily the problems they introduce - but rather, the real reasons why teams are using them.
  • youtube: Git Flow Is A Bad Idea - Dave Farley What is GitFlow and why is it a bad idea if you want to practice Continuous Delivery or Continuous Integration? GitFlow is a feature branching strategy that adds several extra layers of complexity. Git Flow is bad when we need fast feedback and a clear picture of the quality and ‘releasability’ of our work, so how do we adapt to get that faster feedback and a clearer picture?

Trunk-based Development vs. Git Flow

Alternative Branching Models

Feature Flags (Feature Toggles)

Keystone Interface and Keystone Flags

Git Commands

  • Show commit logs:
git log --oneline --all --graph --decorate
git reset --hard HEAD^
git push origin -f
  • Undoing commits. In case you pushed a wrong change and you want to remove it totally the following commands explain how to do it in soft, mixed and hard mode:
git reset --soft HEAD^ # Removes the last commit, keeps changed staged
git reset --mixed HEAD^ # Unstages the changes as well
git reset --hard HEAD^ # Discards local changes
  • Reverting commits:
git revert 72856ea # Reverts the given commit
git revert HEAD~3.. # Reverts the last three commits
git revert --no-commit HEAD~3..
  • Recovering lost commits. We can list all last changes and recover back any commit we would like to get again:
git reflog # Shows the history of HEAD
git reflog show bugfix # Shows the history of bugfix pointer
  • Amending the last commit. Let’s suppose that you commit a wrong log message and you would like to fix it without changing the commit. — amend flag will allow us to do it:
git commit --amend
  • Interactive rebasing. Interactive rebasing can be used for changing commits in many ways such as editing, deleting, and squashing:
git rebase -i HEAD~5



GitLab Collective


Fake it til you make it

  • Have you come across to someone that thinks you don’t deserve a job because you don’t have GitHub contributions? Never worked for a company who hired based on GitHub contributions alone. If anyone is bugging you because you are not an open source developer or your company doesn’t use GitHub, use fake-it-til-you-make-it to generate two years of contributions.

GitHub Lab

  • 🌟 With GitHub Learning Lab, grow your skills by completing fun, realistic projects. Get advice and helpful feedback from our friendly Learning Lab bot.

GitHub Code Scanner

GitHub Actions

GitHub Actions Marketplace

  • flat-data Flat Data is a GitHub action which makes it easy to fetch data and commit it to your repository as flatfiles. The action is intended to be run on a schedule, retrieving data from any supported target and creating a commit if there is any change to the fetched data.

GitHub Actions and OpenShift

GitHub Copilot

GitHub CoPilot VS GPT-3

GitHub Copilot X





Git Tools

Git Credential Manager

  • Git Credential Manager Secure, cross-platform Git credential storage with authentication to GitHub, Azure Repos, and other popular Git hosting services.
  • Git Credential Manager (GCM) is a secure Git credential helper built on .NET that runs on Windows, macOS, and Linux.
  • Git Credential Manager: authentication for everyone Ensuring secure access to your source code is more important than ever. Git Credential Manager helps make that easy.

Semantic-release. CI/CD semantic release workflow (semantic Versioning, commit format and releases)

Azure DevOps (formerly known as VSTS)

Pre Commit Hooks

Merge BOTs


  • Use bots to accomplish tasks like merging PR’s that have been approved and automatically updating dependencies. Usage of one of these bots might allow us to trigger certain builds based off of specific GitHub tags, it would allow us to only selectively run certain test suites and increase the throughput of the build by only testing changes made in a branch / PR.
  • Investigate options that are available and see if we can integrate them with CI.
  • We should be able to configure this bot to automatically apply labels to PR’s based off of what is changed in a PR. For instance, if a PR contains any documentation changes, the area/Documentation label can be applied.

Jenkins for git merges

Bitbucket for git merges

GitLab for git merges

  • Auto-merge between release branches
  • Provide merge bot functionality
  • Gitlab Merge Bot
  • Mergecrush A email & slack reminder bot for Gitlab merge requests.
  • How can we programmatically approve merge requests in GitLab?
    • Our group has a bot that creates merge requests for certain mechanical changes to our code base. We’d like these MRs to get merged in automatically if/when the CI pipeline succeeds, but our projects require an approval from a member of our group. This means that right now a human has to manually click on “approve” and “merge” for each bot-created MR. Apparently GitLab doesn’t have a way to set different approval rules for some users, so I haven’t found a way to make the bot’s user immune to this requirement.
    • My current idea is to have a separate process that approves each of the merge requests created by the bot. Is there an easy way to do this programmatically? That is, is there an API (or better yet, a command line tool) that, when given the name of the branch for a merge request, approves the merge request associated with that branch?
    • I’m also open to other ways of getting these changes in with minimal human intervention. I do want them to pass the CI pipeline, though (which is currently accomplished by having them use MRs) and the MRs also help in the rare cases where the pipeline fails, so we can debug what went wrong.

Marge GitLab bot

Jenkins-X bots

  • Jenkins-X UpdateBOT A simple bot for updating dependencies in source code and automatically generating Pull Requests in downstream projects.

Plastic SCM bot

Mergify bot

GitHub bots

Bors GitHub bot


Click to expand!


Click to expand!


Click to expand!