When we develop as a team, we often use *branches* to organize our

changes. Here we walk through an example of branches.

To get more practice, we'll start a new project and initialize it.

```{figure} https://imgs.xkcd.com/comics/git.png

1. Let's repeat the setup we did before...

```bash

mkdir project2

cd project2

echo "a second git project" > README

git init

```

2. Now let's add our `README` to git and commit:

```bash

git add README

git commit

```

(Remember to enter a log and save...)

3. Let's create and add another file.

We write a simple shell script. Open a new file, called `myscript`, e.g., with nano:

```bash

nano myscript

```

and copy-paste the following content into it:

```bash

ls -l > script.out

```

be sure to end with a new line.

Now, this script is not that fancy and it needs to be run as:

```bash

bash ./myscript

```

when you do this, you should see the output `script.out` created.

Now let's tell git that we want it to track this:

```bash

git add myscript

git commit

```

Be sure to add a useful message.

4. Ignoring things.

Let's look at the status of our project:

```bash

git status

```

You'll see something like:

```

```

It is telling us that it is not keeping track of `script.out`.

But we don't want it to—that is the output from running out

script, and generally we don't keep the output of our codes in

version control.

So we'd like to tell git to ignore that file. The way to do this is to

create a `.gitignore` file:

```bash

nano .gitignore

```

and add the following:

```

```

now if you do `git status`, that file will not appear, but `.gitignore` does!

Be sure to add `.gitignore` to git by doing `git add` followed

by `git commit`.

Now let's imagine that our project is mature and we don't want to break it as

we test out some new ideas. This is where *branches* come into play.

Let's create a new branch called `feature` that we can work on without

disturbing our code in ``main``.

git checkout -b feature

This creates a new branch called `feature` that is initially identical to `main`.

You can tell what branch you are on by doing:

git branch

and we see:

The `*` indicates which branch we are currently on.

What about the log?

git log

we see:

Notice that the most recent commit line shows that both `feature` and `main`

are at the same hash, and it also calls that commit `HEAD`.

`HEAD` is the most recent change on the branch.

Now let's make a change.

Let's put a "Hello, World" code in our repo! Create a file called

`hello.cpp` and add the following:

#include <iostream>

int main() {

std::cout << "Hello, World!" << std::endl;

}

Let's add it to git control:

git add hello.cpp

git commit

Now look at the log:

Now it is clear that `main` is still on the last commit but

`feature` is on the latest (`HEAD`) commit.

Recall that we can compile our `hello.cpp` via:

g++ -o hello hello.cpp

Let's go back to `main`. The `checkout` command does this for us:

git checkout main

Now notice that if you do `ls`, you don't see `hello.cpp`! That

file is in your `feature` branch, and under git control, and git

knows it is not on `main` so when you switch to main, it does not

appear.

Let's add an `authors.txt` file to our project, just containing your name.

```{admonition} Try it...

Note that this is on `main`. If you switch to `feature` you won't see it:

git checkout feature

Switch back to ``main``.

Let's look at the differences between our branches. Since we're on

`main`, we can ask git what the difference between our current code

and the code in `feature` is via:

git diff feature

As you use git more and more, you'll see that `diff` is very handy.

Now we're happy with the changes we made on `feature` and we want to

incorporate them into `main`&mdash;this is called *merging*, we

accomplish this by doing

git merge feature

This is a special type of commit, and your editor will pop up with a

merge commit already entered. Just save this, and it will be logged.

If we look at our project history so far:

git log

We see something like this (again, your hashes will be different)

Imagine that our current code is not working, but we remember that it

was before we did our branching and added the `hello.cpp`. Looking

at the log or the graph shows that that change came in with the commit

`22e1d58cee38021da961516b24dde689d3b8a66e`. We can checkout the

state of the code before that commit by using the hash from the

previous commit:

git checkout 69eb3bf482bd78c3bf63e890f52b9aac33d5ee2a

Note that you don't need to type out the entire hash&mdash;you only need the starting bits,

as long as it is unique.

This command puts you in a detached branch, but you could make it a named branch by using

`git checkout -b name`.