differences for PR #5

Author: actions-user

branches.md

@@ -25,8 +25,7 @@ exercises: 15
 
 Branches are independent development lines. Working independently, you can likely get away with using git without creating any branches, as in the first diagram in the figure below. However, when you begin to work with others, branches allow team members to work on the code without impacting the work of other developers or users.
 
-![Figure showing three graph diagrams representing different repository states. Each is a graph consisting of vertices (circles) and directed edges (arrows) where each horizontal path is a branch. The first shows a single path representing a repository with a single main branch, the second has two branches, a main and a feature branch, and the third has three branches, a main and two feature branches.](../fig/branches/branches.png){alt="" width="75%"}
-*These graph diagrams show repositories with different numbers of branches. The vertices, or circles, in these graphs show different commits, and each horizontal path is a branch. The first shows a repository with 1 main branch, the second a repository with 1 main and 1 feature branch, and the third repository 1 main and 2 feature branches.*
+![These graph diagrams show repositories with different numbers of branches. The vertices, or circles, in these graphs show different commits, and each horizontal path is a branch. The first shows a repository with 1 main branch, the second a repository with 1 main and 1 feature branch, and the third repository 1 main and 2 feature branches.](../fig/branches/branches.png){alt='Graph diagram of nodes/circles and edges/arrows representing repository state. Each horizontal path is a branch. The first shows a single path representing a repository with a single main branch, the second has two branches, a main and a feature branch, and the third has three branches, a main and two feature branches.' width="75%"} 
 
 Branches can have a few different purposes. Branches created to develop a specific feature are referred to as feature branches, and are often short-lived. Branches can also be used for longer-term purposes, such as having separate development and production branches. How you organize and use branches in your project is referred to as a branching strategy, which we will cover more when we talk about git workflows.
 
@@ -51,11 +50,9 @@ git checkout -b my_new_branch
 
 This will create the branch `my_new_branch` and move you to the new branch. If you run `git status` at this point it will display `On branch my_new_branch`. Making and committing any changes will only update `my_new_branch`.
 
-![Figure showing the process of creating a branch. First a graph diagram of a repository is shown with two commits on the main branch. To the left is an arrow with the text "git checkout -b my_branch" followed by the same repository with the new feature branch added. A smiley face is used on each diagram to show where you are in the repository, the first has it on the second commit in the main branch, the second on the feature branch.](../fig/branches/create_branch.png){alt="" width="75%"}
-*Creating a new branch. When you run `git checkout -b my_branch` your new branch gets created and checked out, meaning you are now on your new branch (represented by the smiley face). Any commits you make will be on this branch until you checkout another one.*
+![Creating a new branch. When you run `git checkout -b my_branch` your new branch gets created and checked out, meaning you are now on your new branch (represented by the star). Any commits you make will be on this branch until you checkout another one.](../fig/branches/create_branch.png){alt='Figure showing the process of creating a branch. From left to right: a repository with two commits on the main branch, followed by an arrow with the text "git checkout -b my_branch" followed by the same repository with the new feature branch added. A star is used on each repository to show which commit you are on, the first has it on the second commit in the main branch, the second on the first commit of the feature branch.' width="75%"}
 
-![Figure creating commits on a branch. First a graph diagram of a repository is shown with two commits on the main branch and one on a feature branch. To the left is an arrow with the text "git commit (x2)", followed by the same repository with to additional commits on the feature branch. A smiley face is used on each diagram to show where you are in the repository, each on the last commit on the feature branch.](../fig/branches/commit_branch.png){alt="" width="75%"}
-*Every time you run the `git commit` command the commit will be added to your current branch.*
+![Every time you run the `git commit` command the commit will be added to your current branch.](../fig/branches/commit_branch.png){alt='Figure showing creating commits on a branch. From left to right: a repository with two commits on the main branch and one on a feature branch, followed by an arrow with the text "git commit (x2)", followed by the same repository with to additional commits on the feature branch. A star is used on each diagram to show where you are in the repository, each on the last commit on the feature branch.' width="75%"}
 
 The first time you push your branch to the remote repository, you will need to publish the branch by running run:
 
@@ -75,8 +72,7 @@ git checkout main
 
 Remember, if you aren't sure which branch you are on you can run `git status`. It is good practice before you start making changes to any of your files to check that you are on the right branch with `git status`, particularly if you haven't touched the code recently.
 
-![Figure showing the process of changing, or checking out a branch. First a graph diagram of a repository is shown with two commits on the main branch and three on the feature branch. A smiley face is on the third commit of the feature branch to show the current location. To the left is an arrow with the text "git checkout main" followed by the same repository with the smiley face now on the second commit in the main branch.](../fig/branches/checkout_branch.png){alt="" width="85%"}
-*Switching branches using `git checkout`.*
+![Switching branches using `git checkout`.](../fig/branches/checkout_branch.png){alt='Figure showing The process of changing, or checking out a branch. From left to right: a repository with two commits on the main branch and three on the feature branch with current location on the third commit of the feature branch, followed by an arrow with the text "git checkout main”, followed by the same repository with the current location now on the second commit in the main branch.' width="85%"}
 
 ### Merging Branches
 
@@ -89,8 +85,8 @@ git merge main
 
 will merge any changes introduced to `main` into the `my_new_branch`. Merging in this direction is especially useful when you've been working on `my_new_branch` for a while and `main` has changed in the meantime.
 
-![Figure showing the process of merging the main branch into the feature branch. First a graph diagram of a repository is shown with a main and feature branch. The feature branch with three commits splits off the main branch after two commits, and the main branch has an additional two commits after the split. A smiley face is on the third commit of the feature branch to show the current location. Below is an arrow with the text "git merge main" followed by the same repository with a new arrow from the last commit on the main branch to a new commit on the feature branch, showing the changes from the main branch have been merged into the changes on the feature branch.](../fig/branches/merge_into_branch.png){alt="" width="60%"}
-*Merging new commits from the main branch into the feature branch with `git merge main`.*
+![Merging new commits from the main branch into the feature branch with `git merge main`.](../fig/branches/merge_into_branch.png){alt='Figure showing the process of merging the main branch into the feature branch. On the top is a repository with a main and feature branch. The feature branch starts at the second commit on the main branch and has three commits, and the main branch has an additional two commits after the split. The current location is the third commit of the feature branch. Below is an arrow with the text "git merge main" followed by the same repository with a new arrow from the last commit on the main branch to a new commit on the feature branch, showing the changes from the main branch have been merged into the changes on the feature branch.' width="60%"}
+
 
 When development is complete on `my_new_branch`, it would be merged into `main`:
 
@@ -99,17 +95,15 @@ git checkout main
 git merge my_new_branch
 ```
 
-![Figure showing the process of merging the feature branch into the main branch. First a graph diagram of a repository is shown with a main and feature branch. The feature branch with three commits splits off the main branch after two commits. A smiley face is on the second commit of the main branch to show the current location. Below is an arrow with the text "git merge my_branch" followed by the same repository a new commit on the main branch with two arrows from the main and feature branches, showing the changes from the feature branch have been merged into main branch.](../fig/branches/merge_into_main.png){alt="" width="50%"}
-*Merging new commits the feature branch into the main branch with `git merge my_branch`.*
+![Merging new commits the feature branch into the main branch with `git merge my_branch`.](../fig/branches/merge_into_main.png){alt='Figure showing the process of merging the feature branch into the main branch. On the top is a repository with a main and feature branch. The feature branch starts at the second commit on the main branch and has three commits. The current location is on the second commit of the main branch. Below is an arrow with the text "git merge my_branch" followed by the same repository with a new commit on the main branch that has two incoming arrows from the main and feature branches, showing the changes from the feature branch have been merged into main branch.' width="50%"}
 
 Git will do its best to complete the merge automatically. For example, if none of the changes have happened in the same lines of code, things will usually merge cleanly. If the merge can't complete automatically, this is called a merge conflict. Any conflicts in the files must be resolved before the merge can be completed.
 
 ## Merge vs Rebase
 
 There is another way to introduce changes from one branch to another: rebasing. A rebase rewrites history. For example, if there are new commits on the main branch while you are working on a feature branch, you could merge those commits into your feature branch, as we describe above. This creates a new commit with two parent commits: one in your feature branch, one in the main branch. Alternatively, you can rebase your feature branch onto the new end of the main branch with `git rebase main`. Rebasing "replays" your feature branch commits onto the new commits of the main branch, as if you started your branch there.
 
-![Figure showing the process of rebasing the feature branch onto new commits in the main branch. First a graph diagram of a repository is shown with a main and feature branch. The feature branch with three commits splits off the main branch after two commits. A smiley face is on the third commit of the feature branch to show the current location. Below is an arrow with the text "git rebase main" followed by the same repository, but the feature branch now splits off the main branch at the last commit.](../fig/branches/rebase.png){alt="" width="50%"}
-*Rebasing the feature branch onto new commits in the main branch with `git rebase main`.*
+![Rebasing the feature branch onto new commits in the main branch with `git rebase main`.](../fig/branches/rebase.png){alt='Figure showing the process of rebasing the feature branch onto new commits in the main branch. On the top is a repository with a main and feature branch. The feature branch has three commits and starts from the second commit of the main branch, which has two additinal commits after the split. The current location is on the third commit of the feature branch. Below is an arrow with the text "git rebase main" followed by the same repository, but the feature branch now splits off the fourth and last commit of the main branch.' width="50%"}
 
 Rebasing creates a cleaner history, without the extra merge commit. However, rebases never be done on public branches that others might be using or even looking at. It will result in your repository and everyone else's having different history, which can be confusing and difficult to fix. If no one else is looking at your branch, especially if you haven't published it yet, rebasing is safe.
 

fig/branches/checkout_branch.png

@@ -5,10 +5,10 @@
 "index.md" "20a35cafbc108ef18c83f37ca98a0e3c" "site/built/index.md" "2025-06-16"
 "links.md" "8184cf4149eafbf03ce8da8ff0778c14" "site/built/links.md" "2025-06-16"
 "episodes/introduction.md" "991e1cb69dd7e392f9ff5348fa6a1cdf" "site/built/introduction.md" "2025-06-16"
-"episodes/branches.md" "0bb82fecd9759fc34aa6f52643b0b3a8" "site/built/branches.md" "2025-06-16"
-"episodes/pr.md" "81271ff20c6d52e3f3db4740bef6fa85" "site/built/pr.md" "2025-06-16"
+"episodes/branches.md" "1b9b74b551e87218a3d25b79f8bffdfd" "site/built/branches.md" "2025-07-13"
+"episodes/pr.md" "03c3563b6bc32e1c56eca45db23fc471" "site/built/pr.md" "2025-07-13"
 "episodes/git-workflows.md" "4b1183291501e5a535ef3ec78ba76272" "site/built/git-workflows.md" "2025-06-16"
 "instructors/instructor-notes.md" "cae72b6712578d74a49fea7513099f8c" "site/built/instructor-notes.md" "2025-06-16"
 "learners/reference.md" "9f1763bb4b44b2da6a2d5e9712bba822" "site/built/reference.md" "2025-06-16"
-"learners/setup.md" "4f6c609ec2d7a33704c4591113717825" "site/built/setup.md" "2025-06-16"
+"learners/setup.md" "4238af16f91642e843dcfecfcd77f347" "site/built/setup.md" "2025-07-13"
 "profiles/learner-profiles.md" "60b93493cf1da06dfd63255d73854461" "site/built/learner-profiles.md" "2025-06-16"