How to Use Git Branches and Merge Team Changes

TL;DR

Git branches let you separate work in progress from the main version history, so features and urgent bug fixes can advance without interfering with each other. Create a branch with git branch, switch with git checkout, confirm the active branch through HEAD, and inspect the full history with git log --all --graph before combining completed work through the feature branch workflow.

Transcript

In this tutorial we're going to learn the three skills that will get us to a professional level of git. And these skills are branching, merging, and the feature branch workflow. In order to follow along you'll need to know the basics of git and github. I go over that in part one and two of this tutorial, but you don't need to watch them, these are ... Read More

Key Insights

• Branching is Git's solution for developing multiple changes at the same time. A feature can accumulate work-in-progress commits on its own branch while an urgent bug fix is committed separately to the main branch and prepared for the real website.
• The main branch is generally treated as the final copy of the website's code. Work-in-progress feature commits should remain on a separate branch so uncertain or incomplete changes do not interfere with bug fixes or the code intended for the live website.
• A Git repository begins tracking changes after git init is run inside the folder containing the code. The tutorial creates a new practice repository so the branch structure and evolving version history are easier to observe without unrelated project details.
• Git staging and committing perform different jobs. The command git add . selects changes from the current folder for the next version, while git commit -m followed by a message creates the actual commit in the repository's version history.
• A branch is created with git branch followed by a descriptive branch name. The tutorial uses feature1 for simplicity, while suggesting that professional branches are usually named after their work, such as a branch dedicated to social login.
• The active branch is changed with git checkout followed by the branch name. After checkout, HEAD points to that branch, which means subsequent commits are added there until the developer checks out another branch and changes the active working context.
• The command git log --all --graph displays the repository's branches and commits as a graph. It is repeatedly used to verify branch creation, identify the branch referenced by HEAD, and confirm that feature commits and the bug-fix commit occupy separate histories.
• The feature branch workflow supports team collaboration by separating feature development before changes are combined. The tutorial's later sections cover merging, merge conflicts, updating a local repository after a merge, and resolving feature-workflow conflicts directly on the developer's computer.

Questions & Answers

Q: Why should developers use Git branches for feature work?

Git branches let developers place work-in-progress commits on a separate line of history instead of adding them directly to the main branch. This separation is useful when a large feature requires several commits but an urgent bug must also be fixed. The developer can return to the main branch, commit the tested fix, and keep unfinished feature code out of the website's final copy.

Q: How do you create and switch to a Git branch?

Create a branch by running git branch followed by the desired branch name. The tutorial creates a branch named feature1, although a name describing the actual work, such as social login, is usually appropriate. Switch to that branch with git checkout followed by its name. Running git log --all --graph afterward lets you confirm that HEAD points to the selected branch.

Q: What does HEAD mean when viewing a Git history?

HEAD identifies the branch on which the developer is currently working. When HEAD points to feature1, new commits are added to the feature1 branch. After git checkout master, HEAD points to master and new commits go there instead. Watching the HEAD label in git log --all --graph helps verify the active branch before committing feature work or a bug fix.

Q: How can you inspect all Git branches and commits?

Run git log --all --graph to display the version history, including the branches and their commit relationships. The tutorial uses this command after creating commits, creating feature1, switching branches, and recording a bug fix. The graph makes it possible to verify that feature commits remain on their branch while the master branch develops separately with the bug-fix commit.

Q: How do you keep unfinished code off the main branch?

Create a dedicated feature branch before committing the unfinished work, then switch to it with git checkout. Every commit created while HEAD points to that branch stays in its separate history. If another task arises, check out the main branch before making that change. This approach prevents incomplete feature commits from entering the branch treated as the final website code.

Q: How can you commit an urgent bug fix during feature development?

First confirm that the unfinished feature work has been committed on its feature branch. Then run git checkout with the main branch name, such as master, and verify that HEAD moved to that branch. Create and test the bug fix there, stage it with git add ., and commit it. The feature commits remain isolated while the fix advances the main history.

Q: What is the difference between git add and git commit?

The command git add selects which changes will be included in the next version, but it does not create that version. In the tutorial, git add . selects changes in the current folder. The command git commit -m followed by a message then creates a commit in the version history. Both steps are repeated to build the practice repository and its feature work.

Q: What topics are included in the Git feature branch workflow?

The tutorial connects local branching and merging with GitHub through the feature branch workflow. Its listed sections include basic merging, merge conflicts, the feature branch workflow, updating a local repository after a merge, merge conflicts within that workflow, and resolving conflicts on a computer. Together, these topics address how teams work simultaneously and later combine their changes.

Summary & Key Takeaways

• Branching solves the problem of working on several changes simultaneously. A developer can keep multiple feature commits on a separate branch while returning to the main branch for an urgent bug fix. This prevents unfinished feature code from entering the version history used as the final copy of the website.

• The tutorial builds a fresh repository with git init, creates three versions using git add . and git commit -m, and inspects them with git log --all --graph. It then creates feature1 with git branch, switches to it using git checkout, and adds two isolated feature commits.

• After the feature commits, the developer checks out master and commits a bug fix there. The resulting graph visibly separates the feature work from the production-oriented history. The remaining tutorial covers merging, merge conflicts, the GitHub feature branch workflow, updating a local repository, and resolving conflicts on a computer.