git_for_devops/06-git-branches.txt at main · path4cloud2024/git_for_devops · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
Branch:
    >>>> It's just a pointer to a specific commit.

    - Its certainly a duplicate version of your current versions of file but as a new branch under same directory.
    - Where we can safely play with files modification and will not impact a files under main/master branch.
    - Once we fully satisfied then we can merge these changed to parent branch whcih is main/master, so master is a default branch.
    - A repo can have a mulitple branches.
    - Pointers for all branches are located under .git/refs/heads, it auto moves to new pointer/commit after new commit.
    - your current branch tracks new commits.

    ** Few commands to play with branch:
        # git branch <new_branch> (create a new branch)
        # git switch <existing_branch> (change the branch)
            or
        # git checkout <existing_branch> (change the branch)

        # git checkout -b <new_branch> (do both above operation at a time)

        # git branch -d <branch_name> (delete merged branch)
        # git branch -D <branch_name> (delete unmerged branch, forcefully)

        # git branch -m <old_name> <new_name> (rename the existing branch)

HEAD:
    >>>> Pointer to a current snapshot in repository, It is unique and always only one HEAD. It will reference to the currently checked-out branch or commit.

    - Pointer is located in the .git/HEAD file
    - Default is "ref: refs/heads/master"
    - Which again refer to last commit.


    If we have created a new branch and add or modify something in files and without merging that to main branch if i try to delete, git won't allow to delete it until it merged. You can delete with git branch -D <branch_name> but in that way commit becomes the orphaned commit and overtime, git runs garbage collector, eventually it delete that commit.

    HEAD --> usually points to last commit becuase now Git knows the parent of next commit

    git checkout <commit_id> will lead you to the Detached HEAD state , we have to create a new branch on it to keep the changes alive and tracked by git.

MERGING THE BRANCHES:
    There are two types of merge:
    1) Fast forward merge:
        It is possible when there are not further commits in the receiving or main/master branch after the commit where feature or new branch was created.
        Basically no merge rather just rewrite the tree or refer to a new commit, zero chance for conflict.
        It just simply moves the pointer (HEAD) to last commit in new branch as (master and new_branch)
        Post merger, we can delete the new_branch (git branch -d <branch_name> (delete merged branch))

        Merging Process:
            a. Create a new feature branch from the main/master branch
            b. Make changes in new feature branch and commit
            c. checkout back to main/master branch
            d. merge feature branch to main/master branch (git merge <new_branch>)

        ** It will automatically decide the merge strategy based on commit history, if its fast forward then you can see something like this:

        Updating bd0abbf..14b7a30
        Fast-forward     <------------- merge strategy type.

    2) 3 way merge:
        It is to be choosen by git when a receiving branch has more commit than the new_branch was created.
        This merge will have all commit history from main/master and new branch as well hence, final commit where HEAD point, would have 2 parents.
        It creates a new merge commit based on both branches and their common parent, whereas Fast Forward does not create a new commit.

        Merge >>> Diversion --> Conversion

        Merging Process:
            a. Create a new feature branch from the main/master branch
            b. Make changes in new feature branch and commit
            c. checkout to main/master branch and commit new file message
            d. now main/master branch have more commit from the point where new feature branch was created
            e. merge feature branch to main/master (git merge <new_branch>)

        ** It will automatically decide the merge strategy based on commit history, if its more commit from the pointer where new feature branch was created then you can see something like this:

        Merge made by the 'ort' strategy.
        (here ORT = Optimized Recursive Tree)

*******
    🎯 Git Branch Naming Convention Explained
        Branch naming conventions help teams stay organized, communicate purpose, and maintain clean workflows in Git.
        A proper naming pattern makes it easy to understand why a branch exists and what type of change it contains.

        The common format is:
        a. feat/ → Feature development: Used when adding new functionality.
            Examples:
                feat/user-authentication
            Use case:
                Implementing a new user story, enhancement, or module.

        b. fix/ or bugfix/ → Fixing bugs: Used for normal bug fixes that are not urgent.
            Examples:
                fix/login-button
            Use case:
                Resolving issues reported by QA or production bugs that are not critical.

        c. hotfix/ → Critical production fixes: Used for immediate, urgent fixes to production.
            Examples:
                hotfix/payment-failure
            Use case:
                Something is broken in production and must be fixed ASAP.

        d. docs/ → Documentation changes: Used when updating readme files, wiki pages, comments, diagrams.
            Examples:
                docs/update-installation-guide

        e. style/ → Non-functional formatting changes: Used for visual / formatting fixes, without changing logic.
            Examples:
                style/remove-extra-spaces
            Use case:
                Whitespace fixes, code linting, indentation cleanup.

        f. refactor/ → Code restructuring without changing behavior: Used when improving code structure or quality.
            Examples:
                refactor/auth-service
            Use case:
                Improving readability, performance, or maintainability.

        g. test/ → Adding or updating tests
            Examples:
                test/add-unit-tests-for-auth

        h. chore/ → Maintenance tasks: Used for tasks that don’t change application behavior.
            Examples:
                chore/update-dependencies
            Use case:
                CI configuration updates, build script changes, dependency upgrades.

    🧩 Why do we need naming conventions?
        ✔ Improve clarity
            You instantly know what the branch is for.
        ✔ Faster reviews
            Reviewers understand the purpose without opening the code first.
        ✔ Better automation
            CI/CD systems can trigger different workflows based on branch type.
        Example:
            Deploy feature branches to a dev environment
            Deploy hotfix branches to production immediately
        ✔ Reduce confusion in teams
            Everyone uses the same style.


    Rebase ---> Relocates a branch to a new parent
        new_feture # git rebase master