Git branching is a fundamental aspect of version control workflows, enabling teams to work on multiple features concurrently while maintaining code integrity. However, understanding and effectively managing branches, especially in complex scenarios like resolving conflicts and merging changes, can be challenging. In this article, we'll delve into a common use-case scenario and explore how to navigate it using Git commands, with a particular focus on the git log command.

Scenario Overview

Imagine a scenario where developers, let's call them X and Y, are working on a project within a DataOps environment. They encounter unexpected behaviour while committing and resolving conflicts during their workflow. Let's dissect the scenario for a clearer understanding:

• Changes A and B exist in the development (Dev) and quality assurance (QA) branches, respectively, which are not yet ready for production.
• X creates a feature branch (FB) from the Master branch, making changes to files.
• Upon promoting the changes to Dev, X encounters merge conflicts, which X resolves.
• Subsequently, X promotes the changes to Dev and QA for testing but decides against merging from QA to Master due to unready changes.
• However, X notices that when planning to merge from FB to Master, changes from Dev are backfilled into the FB, which is not the desired outcome.

Understanding Git Behaviour

 To comprehend the observed behaviour, it's essential to delve into Git's underlying mechanisms and branching strategies within the DataOps environment. Git's branching model follows a hierarchical structure, with each branch representing a distinct stage of development.

• Branching out from Master for quick fixes implies the necessity to merge back into Master promptly.
• Branching out from Dev should ideally entail merging back into Dev to maintain continuity.
• Failure to adhere to this branching strategy may result in unexpected merge behaviours, as observed in the scenario.

Exploring Git Logs

 One powerful tool for visualising Git's commit history and branching structure is the git log command. By leveraging this command with specific parameters, developers can gain insights into the commit lineage and branch relationships.

git log --all --decorate --oneline --graph

This command generates a graphical representation of the commit history, depicting branches, merges, and their respective commits. Visualising the Git graph facilitates understanding the flow of changes across branches and aids in identifying potential anomalies or conflicts.

git log --graph --abbrev-commit --decorate --all

This command is similar to the original one but uses --abbrev-commit instead of --oneline. It still provides a concise output but displays the full commit hash instead of truncating it.

git log --graph --pretty=format:'%C(auto)%h %C(auto)%d %s %C(black bold)(%cr) %C(dim white)e%an]' --all

This command customises the output format of git log to include more information, such as relative commit time (%cr) and author name (%an). It uses color coding (%C(...)) for enhanced readability.

git log --graph --all --simplify-by-decoration --decorate

This command simplifies the graph by focusing on branches and tags, ignoring individual commits. It can be useful for understanding the high-level structure of the repository.

Conclusion

 In conclusion, the scenario presented highlights the importance of understanding Git's behaviour within the DataOps ecosystem. By adhering to established branching strategies and leveraging tools like git log, developers can mitigate unexpected behaviours and streamline their workflow effectively. Continuous collaboration and knowledge sharing within the DataOps community further enhance the collective understanding and mastery of version control systems like Git.