Safe experiments: working with branches

1. What branches are and why they matter

Working with branches in Git is one of the key aspects of version control that allows you to develop multiple lines of work in parallel within a single repository. Branching makes Git a powerful tool for collaboration, experimentation, and managing different versions of a project.

            gitGraph
            commit id: "Initial setup"
            commit id: "Add base features"
            branch feature/new-idea
            checkout feature/new-idea
            commit id: "Implement new logic"
            commit id: "Refactor the logic"
            checkout main
            commit id: "Urgent bugfix on main"
            merge feature/new-idea
            commit id: "Prepare for release"
        

Imagine you want to seriously rework something in your project or run a risky experiment. What would you do without Git? Most likely, you would copy the entire project into a new folder and work there. If the result looks good—you would move it to the main folder. If not—you would simply delete the copy.

Branches in Git work on the same principle, but far more elegantly. Let’s look at an example of writing a book:

1. You have a finished manuscript (this is your main branch, main).
2. You want to write an alternative ending (you create a new branch, for example feature/new-idea).
3. You write the new ending without touching the main text of the manuscript (you work in the new branch).
4. If the new ending turns out better, you replace the old one with it (you merge the branches — merge).
5. You can delete the old draft with the unnecessary ending (you delete the branch).

2. Creating a new branch and working in it

Step 1. Open the branch management menu.

On the IDE’s top toolbar there is a widget that shows the name of the current branch (by default — main). Click it and select + New Branch.

Step 2. Name the new branch.

A good practice is to name branches according to the task you are solving. For example, feature/add-usage-examples.

After creating the branch, the IDE will switch to it automatically. You will see the new name in the same widget.

Step 3. Make and commit your changes.

Now you are in your “sandbox.” Let’s add a new “Usage examples” section to our README.md file. Make your changes and create a commit, as you learned in the previous lecture.

3. Switching between branches

Your changes with usage examples are now safely stored in the feature/add-usage-examples branch. Let’s return to the main branch, main, and see what’s there.

Step 1. Click the widget with the current branch name again.

Step 2. In the Local or Recent list, select the main branch, and in the submenu click Checkout.

Step 3. Check the result.

As soon as you switch, open the README.md file. You will see that the “Usage examples” section is not there! It stayed in the other branch. This way you can work on new functionality without touching the stable version in the main branch.

4. Merging branches (Merge)

The merge command takes all commits from the feature/add-examples branch (in this case, commit C3) and combines them with the current main branch, creating a new merge commit.

            gitGraph
            commit id: "C1"
            commit id: "C2"
            branch feature/add-examples
            checkout feature/add-examples
            commit id: "C3: Add new section"
            checkout main
            merge feature/add-examples
        

So, you have finished your task in the feature/add-usage-examples branch and want to add these changes to the main project.

Step 1. Switch to the target branch.

Make sure you are on the branch WHERE you want to add the changes. In our case, that is main.

Step 2. Perform the merge.

Click the branch management widget again. In the list, select the branch you want to merge FROM (feature/add-usage-examples), and in the submenu choose Merge feature/add-usage-examples into main.

Step 3. Check the result.

Now your new section with examples has appeared in README.md in the main branch. You have successfully merged your work with the main version of the project!

5. Merge conflicts: don’t worry, that’s normal!

Sometimes merge operations cause conflicts. This happens when the same lines in the same file were changed in both branches. Git cannot decide which version is correct and asks for your help.

            gitGraph
            commit id: "C1: Common base"
            branch feature/new-title
            checkout main
            commit id: "C2: Change in main"
            checkout feature/new-title
            commit id: "C3: Change in feature"
        

Let’s simulate a conflict:

1. Make sure you are on the main branch and you have no uncommitted changes.
2. Create a new branch feature/new-title, but do not switch to it yet. Make sure the Checkout branch checkbox is unchecked.
3. Now, while on main, change the first line in README.md to “My Awesome Project” and create a commit.
4. Switch to the feature/new-title branch. You will see that the first line in README.md here is still the old one: this is the state of the file at the moment the branch was created. Change the same line to “My Super Project” and create a commit.
5. Go back to main and merge with feature/new-title.

Now Git will see that both branches have new, diverging histories from their common ancestor. The same line was changed in both histories, so Git cannot choose which version is correct and will show you a window for resolving the conflict.

Merge Revision

What you see here:

• On the left (Your changes): the file version from your current branch (main).
• On the right (Changes from branch...): the file version from the branch you are merging.
• In the center (Result): the final file version that you need to assemble.

You can click the arrows >> or << to accept one side entirely.

When you are satisfied with the result in the center panel, click Apply. The IDE will create a merge commit for you, and the conflict will be resolved.

Why didn’t a conflict occur?

You might encounter a situation where you followed all the steps, but no conflict happened. Most often this is because Git was able to do a fast-forward merge, since one branch’s history simply continued the other’s history. For a conflict to be guaranteed, the branch histories must diverge in different directions from their common ancestor.

Example:

1. You have a commit in main (say, C1).
2. You make a new commit in main with the text “My Awesome Project”. The main branch now points to commit C2 (main -> C1 -> C2).
3. You create the feature/new-title branch from the current position of the main branch. That means the new branch also starts at commit C2.
4. You make a commit in feature/new-title with the text “My Super Project”. This branch “moves ahead” and now points to commit C3 (feature/new-title -> C1 -> C2 -> C3).
5. You return to main (which is still at commit C2) and issue a merge of feature/new-title.

Git looks at the situation and sees that the main branch is a direct ancestor of the feature/new-title branch. There were no new commits in main while you worked in the other branch. Git thinks: “Oh, we just need to fast-forward main to commit C3. There are no contradictions.” And it simply moves the main pointer to commit C3.

            gitGraph
            commit id: "C1"
            commit id: "C2"
            branch feature/new-title
            checkout feature/new-title
            commit id: "C3"
            checkout main
            merge feature/new-title
        

6. Viewing the change history

To better understand what is happening in your project, it helps to look at its history.

Open the Git tab at the bottom of the IDE and select Log. You will see a graphical representation of all your branches and commits. This helps visualize which branch split from which and where they were merged.

Here you can click any commit to see what changes went into it, who made it, and when. It’s a real time machine for your code!

1

Task

JAVA 25 SELF, level 25, lesson 2

Locked

Architectural Bureau: Calculating Areas of Shapes 🧱

Architectural Bureau: Calculating Areas of Shapes 🧱

Open

1

Task

JAVA 25 SELF, level 25, lesson 2

Locked

Advanced Email Client: Composing a Message 📦

Advanced Email Client: Composing a Message 📦

Open