| Ko

Pull Request Review Best Practices

PR (Pull Request) review is a core collaborative activity that improves team code quality, shares knowledge among developers, and catches potential bugs early. Since GitHub introduced the Pull Request feature in 2008, it has become the standard way to integrate code in both open source projects and enterprise development environments. PR reviews go beyond simply finding errors in code. They are an essential quality management practice in software development that helps team members understand each other’s code, maintain a consistent codebase, and make better design decisions through collective intelligence. ...

July 31, 2024 · 9 min · 1911 words · In-Jun

Temporarily Saving Changes with Git Stash

Concept and History of Git Stash Git stash is a feature first introduced in Git version 1.5.3 in 2007. It provides a mechanism to save changes in the Working Directory (modified tracked files and staged changes) to a stack-based temporary storage without committing, allowing restoration later. This feature is useful when you need to urgently switch to another branch while working, or when you need to fetch changes from a remote repository but your current work is not ready for a commit. ...

July 26, 2024 · 5 min · 934 words · In-Jun

Git Branch Naming Conventions

History and Importance of Branch Naming Git branch naming conventions became more structured after Vincent Driessen introduced Git Flow in his 2010 blog post “A successful Git branching model.” Since then, branching strategies such as GitHub Flow (2011) and GitLab Flow (2014) have helped establish prefix-based names like feature/, bugfix/, hotfix/, and release/ as industry standards. Consistent branch naming improves project readability, supports CI/CD pipeline automation, and makes code reviews and task tracking more efficient. ...

July 23, 2024 · 4 min · 728 words · In-Jun

Managing Pull Requests with GitHub CLI

GitHub CLI (gh) is GitHub’s official command-line interface, released in September 2020. It lets you use core GitHub features directly from the terminal, including pull requests, issues, and repositories. Because developers often write code and manage versions in the terminal, GitHub CLI helps maintain a more consistent workflow while reducing context switching and automating repetitive tasks. Introduction to GitHub CLI What is GitHub CLI? GitHub’s official command-line tool for using core GitHub features such as pull requests, issues, repositories, and GitHub Actions from the terminal. It wraps the REST and GraphQL APIs to provide an intuitive command interface. ...

July 19, 2024 · 13 min · 2643 words · In-Jun

Git Commit Management and Clean History

History and Importance of Commit Management Thoughtful commit management has been part of Git’s design since Linus Torvalds created it in 2005. Rebase existed from the early days, and interactive rebase, introduced in Git 1.5 in 2007, turned it into a powerful tool for fine-grained history editing. Commit history management matters because the Git log serves as documentation for a project’s evolution. A well-organized history makes it easier to understand how the project changed over time. It also makes each commit’s intent clearer when tracking bugs with git bisect and helps new team members get up to speed faster. ...

July 13, 2024 · 6 min · 1171 words · In-Jun

Effective Commit Message Writing Rules

History and Importance of Commit Messages Systematic guidelines for writing commit messages became widely known in 2008 when Tim Pope proposed the 50/72 rule (50-character subject, 72-character body line wrap) in his blog post “A Note About Git Commit Messages.” In 2014, the commit message convention developed by the Angular team for the AngularJS project gained industry attention. In 2017, Conventional Commits 1.0.0 was released based on this foundation, and it has since become the most widely used standard in open source projects. ...

July 12, 2024 · 7 min · 1280 words · In-Jun

How to Delete Merged Git Branches

In Git, a branch is a core concept that provides an isolated workspace, allowing developers to add new features or fix bugs without affecting the main codebase. This branch-based workflow has been central to Git since Linus Torvalds created it in 2005, which is why branches are much lighter and faster than in systems like SVN or CVS. Deleting branches after merging is just as important as creating them. This article covers why branch deletion matters, how to do it safely, how to automate it, and how to recover deleted branches. ...

July 11, 2024 · 18 min · 3764 words · In-Jun

Git Branching Strategies, Git Flow, GitHub Flow, and GitLab Flow

History and Background of Branching Strategies The systematization of Git branching strategies began on January 5, 2010, when Dutch developer Vincent Driessen published his blog post “A successful Git branching model.” The Git Flow introduced in this article resonated strongly in software development environments that required systematic release management at the time. In 2011, GitHub’s Scott Chacon proposed a simpler model called GitHub Flow. Then in 2014, GitLab announced GitLab Flow, combining the advantages of both strategies. All three strategies continue to be widely used today depending on project characteristics. ...

July 10, 2024 · 7 min · 1336 words · In-Jun

Git From Basics to Advanced Features

History and Origins of Git Git is a Distributed Version Control System (DVCS) developed by Linus Torvalds, the creator of the Linux kernel, in 2005. The development was triggered when the free license for BitKeeper, the commercial DVCS used for Linux kernel development at the time, was revoked. Torvalds needed an alternative and developed a new system in just two weeks that overcame the shortcomings of existing version control systems (slow speed, inefficient branching) while supporting fast operation even on large-scale projects and fully distributed environments. The first version was released on April 7, 2005. ...

July 8, 2024 · 7 min · 1390 words · In-Jun

Adjusting Git Commit Timestamps

Structure of Git Timestamps Git’s timestamp system was designed to record two separate times from when Linus Torvalds designed Git in 2005. This was because in Linux kernel development, the time a patch was written and the time it was actually committed could differ. AuthorDate and CommitDate Git commits have two timestamps. AuthorDate represents when the code was first written, meaning when the original author made the change. It is set via the git commit --date option or the GIT_AUTHOR_DATE environment variable. ...

May 25, 2024 · 5 min · 949 words · In-Jun
[email protected]