Branches

One of the key advantages of Git, is the ability to create specific branches to complete different tasks in the code. All the work above has been completed in the master branch, the default first branch. Branches should be created for specific tasks, and then get “merged” back into the master branch when complete.

Often, a “development” branch is created as an intermediate level branch - feature branches get merged into development, development gets merged into master.

1 Checking Current Branches

To look at the current branches in a repo, git branch can be used. This lists all of the local branches, or with an added modifier, all the branches on any associated remote repository as well.

Remote repositories will be covered in the Collaboration section, but are fundamentally a cloud stored copy of the repository allowing collaboration with colleagues.

$ git branch                # List all local branches
$ git branch -a             # List all local and remote branches

2 Checkout

Branches can be moved between by using the command git checkout <branchname>. This will move the repository to the branch specified. When moving between branches, files might seem to appear or disappear in our File Explorer if they are in just one of the branches and not in the other.

For example, you create a file new_feature_A.txt on branch feature_A_branch then commit it. If you then move to feature_B_branch then new_feature_A.txt will not appear in your folder.

git checkout branchname will move the repository to the specified branchname. If there is no local branch called branchname, Git will look at remote tracking branches, and if one exists, checkout a tracked version of that branch.

Other parameters can be added to the checkout command:

• -b will create the new branch specified, and then move into it.
• --track origin/branchname will checkout a tracked version of the remote branch branchname - equivalent to git checkout branchname if no local branch branchname can be found.

The remote branch/origin refers to branches held on a remote server such as Github.

$ git checkout feature_A            # Move to the `feature_A` branch. The branch must exist. 
$ git checkout -b feature_B         # Create the `feature_B` branch and move into it.
$ git checkout --track origin/feature_C  # Create a local branch tracking `origin/feature_C`.

Instead of checking out specific branches, specific commits can be checked out, by replacing the branch name with the commit ID - the short form of which can be found from a git log --oneline command.

$ git checkout 602a1ee          # Checkout the commit with commit ID specified.

The first checkout we will be doing will always be from the master branch, as this is the only branch that first exists. However, we can create a new branch from any existing branch.

Which branch we want to create a new one from depends on the feature we want to create, and which phase of development we are in.

If we want to make changes to a certain feature, we would checkout a new branch from the branch where that feature is being developed.

If we wanted to create an entirely new feature we could branch off from the develop branch.

The naming convention and branch workflow you use will be determined by any team style guide you have.

If this does not exist there are some general style guides you can follow such as this one.

We would recommend you discuss with an appropriate person in your department/team as to what branch workflow to follow. An example is given at the end of this course.

3 Merge

Once work has been completed within a feature branch, it needs to be merged back in. git merge mergingbranch targetbranch will take the commits from mergingbranch, and attempt to automatically merge them into targetbranch.

Before you merge a branch, you must move to the target branch by using git checkout targetbranch.

• Source Branch - the branch with the new changes
• Target Branch - the branch you want add the new changes to

# If you are on the feature_B branch you need 
# to change to the target branch 
$ git checkout development

$ git merge feature_B development       # Merge branch feature_B into development

If the changes made within the mergingbranch do not conflict with any other commits within the targetbranch, the merge will be successful.

3.1 Merge Conflicts

Merge conflicts arise when two merging commits have made edits to the same parts of the same files. Git is often clever enough to be able to merge changes made to different parts of the same file, but can fall down at times.

When a merge fails to auto merge the branch name will convert to the target branch name, followed by a pipe |, and the word MERGING to indicate that the merge is half complete.

We also get the following message in our Git Bash.

It falls to the user to fix the merge conflict, before committing the completed merge.

$ git merge feature_B development 

Auto-merging preprocessing.py
CONFLICT (add/add): Merge conflict in preprocessing.py
Automatic merge failed; fix conflicts and then commit the result.

hoskim1@ONS22675 MINGW64 //NDATA11/hoskim1$/Desktop/working_git (development|MERGING)
$

The status will also specify that there are conflicts to fix, and list the files with changes that have been both added - by both of the merging branches.

To resolve these issues, open the conflicting files, locate the conflicts, and choose which version of the code should be retained. Conveniently, the file will have added some extra identifying lines around the conflicting areas.

Before each conflicting section, the line <<<<<<< HEAD will be added, followed by the content from the target branch - the one being merged into. A line of equals signs - ======= will signify the end of that branch’s code, and lead into the version from the merging branch. That will end with the line >>>>>>> feature_B, with the name of the merging branch.

<<<<<<< HEAD
dev code 
can be found
in here
...
=======
feature code 
can be found 
in here 
...
>>>>>>> feature_B

To resolve each conflict, edit the conflicting code to retain only the lines that you want, then delete the three identifying lines. Repeat for each conflict - CTRL-F can be useful to find them, it is unlikely your code will naturally have the line <<<<<<< HEAD in it.

Once you have made these changes, add then commit them. The branch you are on in Git Bash will go from displaying (development|MERGING) to just (development). Your branches have now been merged.

4 Delete

Branches should be deleted when they are no longer useful - normally after they have been merged successfully and since abandoned.

A different modifier can be added to git branch to remove old branches - -d or -D.

Care should be taken when removing branches - if they have not been merged successfully, their contents could be lost!

$ git branch -d feature_B       # Delete branch feature_B Will only work if the branch has been merged!
$ git branch -D feature_B       # Delete branch feature_B Will work regardless of whether the branch has been merged.

The modifier is case sensitive. If it is lowercase, it will only work if the branch has been merged. If uppercase, it will delete the branch without checking, and could result in lost work.

As a result - we would advise you use -d by default, and only then use -D if you are confident that’s what you want to do.

After completing the exercises below, you can take a deeper dive into git branching by completing the tasks at https://learngitbranching.js.org/.

5 Exercises

Questions

1. Create and checkout a new branch called dev

2. Create a new file within the Intro_to_Git folder called dev_test.txt. Add a line of text to it, then add it within Git, and commit it with a useful commit message.

3. Merge the dev branch into the master branch.

4. Create and checkout a new branch called alt_dev from the master.

5. Create a new file key_information.txt and write your favourite colour. add and commit this change with an accompanying message.

6. Change to the master branch. Create the new file key_information.txt and write in your favourite animal. add and commit this change with an accompanying message.

7. Merge the alt_dev branch into the master branch. Resolve the conflicts such that the file contains both your favourite colour and animal. add and commit the resolved conflict file and check the status of the master branch.

Answers

Question 1

1. Create and checkout a new branch called dev

$ git checkout -b dev

Switched to a new branch 'dev'

Question 2

2. Create a new file within the Intro_to_Git folder called dev_test.txt. Add a line of text to it, then add it within Git, and commit it with a useful commit message.

To create a new file, right click within the folder in Windows Explorer, then select New/Text Document`. Give it a name, open it, and add a line of text.

Then, within Git Bash:

$ git add dev_test.txt
$ git commit -m 'Added dev test file to repo'

[dev bd9330e] Added dev_test file to repo
1 file changed, 1 insertion(+)
create mode 100644 dev_test.txt  

Note: A new file can be created from within Git Bash, by typing: touch filename.txt

Question 3

3. Merge the dev branch into the master branch.

Move to the master branch, then make the merge.

$ git checkout master
$ git merge dev master

Switched to branch 'master'
Updating 86d7ea6..bd9330e
Fast-forward
 dev_test.txt | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 dev_test.txt

Question 4

4. Create and checkout a new branch called alt_dev from the master branch.

$ git checkout -b alt_dev

Switched to a new branch 'alt_dev'

Question 5

5. Create a new file key_information.txt and write your favourite colour. add and commit this change with an accompanying message.

Create and open the key_infomation.txt file and change the contents of the first line.

Then, within Git Bash:

$ git add key_information.txt
$ git commit -m "added favourite colour to key_information.txt"

[alt_dev 532f49e] added favourite colour to key_information.txt
 1 file changed, 1 insertion(+)
 create mode 100644 key_information.txt

Question 6

6. Change to the master branch. Create the new file key_information.txt and write in your favourite animal. add and commit this change with an accompanying message.

$ git checkout master

Create and open the key_infomation.txt file and change the contents of the first line.

Then, within Git Bash:

$ git add key_information.txt
$ git commit -m "added favourite animal to key_information.txt"

[master 899373a] added favourite animal to key_information
 1 file changed, 1 insertion(+)
 create mode 100644 key_information.txt

Question 7

7. Merge the alt_dev branch into the master branch. Resolve the conflicts such that the file contains both your favourite colour and animal. add and commit the resolved conflict file and check the status of the master branch.

$ git merge alt_dev master

Auto-merging key_information.txt
CONFLICT (add/add): Merge conflict in key_information.txt
Automatic merge failed; fix conflicts and then commit the result.

melloj@ONS27519 MINGW64 //MDATA1/melloj$/Desktop/Intro_to_Git (master|MERGING)
$

Open the key_information.txt file.

The contents of key_information.txt then becomes:

<<<<<<< HEAD
Dog
=======
Blue
>>>>>>> alt_dev

Remove the conflict the file is changed to:

Dog
Blue

$ git add key_information.txt
$ git commit -m "resolved conflicts"

[master bd0fe3d] resolved conflict

$ git status

On branch master
nothing to commit, working tree clean

Reuse