# Git branches: re-using your **dev** branch

```{warning}
Be sure you have completed all the steps from last week, when you created a *dev* branch and then created, committed, and pushed up a change to your `.gitignore` file, and then created a pull request in the *dev* branch on GitHub and merged it into your main branch.

Also be sure that you have used `git pull origin main` and `git pull origin dev` to sync your **main** and **dev** branches back into your project directory in your `/spare11/atm533/<NetID>/<teamName>` folder.
```

## Your project repo on GitHub

Let's take a look at the project repository after we merged the pull
request pertaining to the revision of `.gitignore`. We see that our
**main** branch has commits, and the most
recent commit was related to that merge:

![Graphical user interface, text, application, email Description
automatically generated](media/image1.png)

Click on the **3 commits** link:

![Graphical user interface, text, application, email Description
automatically generated](media/image2.png)

We see the following:

1.  Our initial commit, when we first created this repo

2.  The modification of `.gitignore`, which we staged and committed, and
    then pushed up to our **dev** branch

3.  The merging of our **dev** branch into our **main** branch

Now, let's see what our **dev** branch looks like. Mouse over the
**main** branch pull-down menu, and select **dev**:

![Graphical user interface, text, application Description automatically
generated](media/image3.png)

![Graphical user interface, text, application, email Description
automatically generated](media/image4.png)

We see that the **dev** branch is 1 commit behind the main branch. It
doesn't have the 3rd commit that we see in **main**; namely, the
*merge* of the **dev** branch into **main**.

![Graphical user interface, application Description automatically
generated](media/image5.png)

Recall that when we completed the merge, GitHub offered us the option of
removing the **dev** branch. *In general, this is a good practice*, but
let's say we want to keep our **dev** branch around, and use it for
periodic updates that we'll eventually merge with **main**.

We could try performing a new pull request on the **dev** branch,
pulling in the 3rd commit ... but this would result in a constant
"ping-pong" back and forth of superfluous commits that relate just to
intra-branch merging. Instead, *let's stick with a practice of only
merging from a development branch into our main branch*, not the other
way around.

## Sync your *dev* branch locally

To do this, let's go back to our terminal session, and sync up the
**dev** branch with the **main** branch using command-line **git**
commands, and follow these steps:

1. `cd` to your team folder

1.  Check out your **dev** branch: `git checkout dev`

1.  Merge the **dev** branch with the main branch: `git merge main`

1.  Verify that the two branches are at the same commit: `git branch -v`

1.  Push the **dev** branch up to GitHub: `git push origin dev`

A screenshot of a terminal session that follows these steps appears
below:

![Text, letter Description automatically
generated](media/image6.png)

## View the *dev* branch again on GitHub

Now, back on GitHub, the **dev** branch is the same as **main** in terms
of its commit history:

![Graphical user interface, text, application, email Description
automatically generated](media/image7.png)

We can then resume using the **dev** branch to make additional changes
to the project repository; stage/commit/push them, and then, only when
we feel it's time to merge them into **main** (for the SoS project, this
would be once everyone on your team has made changes to their relevant
notebook), we can follow the workflow we did with our simple change to
**.gitignore**: open up a pull request; review the request; then accept
and merge it into **main**.

You will do this as you address the *Issues* that have been posted on your team's repo on GitHub.