Git Tutorials/Branching - Revision history

Kamil-braschke-0d3e@uni-wuppertal.de at 14:23, 1 September 2022

2022-09-01T14:23:28Z

Show changes

Kamil-braschke-0d3e@uni-wuppertal.de at 09:45, 1 September 2022

2022-09-01T09:45:45Z

Show changes

Kamil-braschke-0d3e@uni-wuppertal.de at 12:42, 25 August 2022

2022-08-25T12:42:29Z

Kamil-braschke-0d3e@uni-wuppertal.de at 12:04, 25 August 2022

2022-08-25T12:04:45Z

Kamil-braschke-0d3e@uni-wuppertal.de: Created page with "Git Tutorials: Branching {{DISPLAYTITLE:Git Tutorial: Branching}} {{Syllabus Git Tutorials}} Branching is an important feature o..."

2022-08-24T12:29:31Z

Created page with "Git Tutorials: Branching<nowiki /> {{DISPLAYTITLE:Git Tutorial: Branching}}<nowiki /> {{Syllabus Git Tutorials}} Branching is an important feature o..."

New page

[[Category:Tutorials|Git Tutorials: Branching]]<nowiki />
{{DISPLAYTITLE:Git Tutorial: Branching}}<nowiki />
{{Syllabus Git Tutorials}}

Branching is an important feature of Git, which enables simultaneous work on different parts of a code with minimal interference between acting parties. As the name implies, branching refers to the creation of a separate line of repository tracking that branches of from your "main" repository (also called a branch, but can be understood as the trunk). When developing new features you do not necessarily want to directly <syntaxhighlight inline>commit</syntaxhighlight> your changes to "main", because they might interfere with your colleagues contribution of other features on a different branch. Even when differences do not directly interfere, they can still lead to a more cumbersome <syntaxhighlight inline>merge</syntaxhighlight> of both branches into "main", once all changes are complete. In larger projects this <syntaxhighlight inline>merge</syntaxhighlight> ''ing'' into the "main" branch is often blocked for most users. A so-called <syntaxhighlight inline>pull</syntaxhighlight> request must be made, so that a responsible person can <syntaxhighlight inline>pull</syntaxhighlight> your changes from your branch into "main".
To view all existing branches use the <syntaxhighlight inline>git branch --list</syntaxhighlight> command:
<syntaxhighlight lang="text" line>
user@HPC.NRW:~$ git branch --list
* main
</syntaxhighlight>

We can see that currently the project contains only one branch called "main" (line 2). The "*" next to it is used to mark our current branch.

== Handling Branches ==

Creating a new branch is as easy as entering <syntaxhighlight inline>git branch <name of branch></syntaxhighlight>:
<syntaxhighlight lang="text" line>
user@HPC.NRW:~$ git branch branchingTut
user@HPC.NRW:~$ git branch --list
branchingTut
* main
user@HPC.NRW:~$ git branch -a
branchingTut
* main
remotes/origin/main
</syntaxhighlight>
In above example we can see that creating a new branch does not imply switching to it (the "*" is still next to "main"). Further, displaying all local and remote branches through <syntaxhighlight inline>git branch -a</syntaxhighlight>, we see that the new branch does only exist locally and not in the remote repository unlike "main" (line 8). The new branch will be identical to the last <syntaxhighlight inline>commit</syntaxhighlight> of the current branch, in our case "main".

To switch to a different branch we use <syntaxhighlight inline>git checkout <name of branch></syntaxhighlight>:
<syntaxhighlight lang="text" line>
user@HPC.NRW:~$ git checkout branchingTut
M someFile
Switched to branch 'branchingTut'
user@HPC.NRW:~$ git branch -a
* branchingTut
main
remotes/origin/main
</syntaxhighlight>
Line 2 informs us about a <syntaxhighlight inline>M</syntaxhighlight>odified file named "someFile". This can happen if we make changes to our repository (like <syntaxhighlight inline>A</syntaxhighlight>dding or <syntaxhighlight inline>M</syntaxhighlight>odifying files), but do not <syntaxhighlight inline>commit</syntaxhighlight> them before switching the branch. Naturally, this also happens when we want to switch to a branch with different contents than in hour current branch.
Keep in mind that a <syntaxhighlight inline>git checkout <name of branch></syntaxhighlight> is not like a <syntaxhighlight inline>git clone</syntaxhighlight> operation and therefore does not make a full copy of a different code branch. Instead, it tracks the <syntaxhighlight inline>commit</syntaxhighlight> history of the chosen branch and reproduces the changes in your repository. Any modifications you <syntaxhighlight inline>commit</syntaxhighlight> now will be added to that branch.

{| role="presentation" class="wikitable mw-collapsible mw-collapsed" style="width:62em" data-expandtext="▼" data-collapsetext="▲"
|+ style="background-color:#2e3871; color:white;text-align: center; width:10em"| <strong>Further remarks</strong>
|-
|If we want to create a new branch and directly switch to it, we use {{Avoid wrap|<syntaxhighlight inline>git checkout -b <name of new branch></syntaxhighlight>}}.
|-
| Usually, a branch is created from the most recent commit of the branch you are currently on. If we want to create it from a different branch (and switch to it), we will have to use {{Avoid wrap|<syntaxhighlight inline>git checkout -b ＜name of new branch＞＜name of different branch＞</syntaxhighlight>}}.
|-
| To delete a branch we type {{Avoid wrap|<syntaxhighlight inline>git branch -d <name of branch></syntaxhighlight>}}.
|-
| Renaming our current branch is done through the command {{Avoid wrap|<syntaxhighlight inline>git branch -m <new name of branch></syntaxhighlight>}}.
|}

== Remote Branches ==

If others are supposed to have access to our branch (or we want to have access from different locations), we need to make sure that it also exists in the remote repository by entering <syntaxhighlight inline>git push <name of remote repository> <name of branch></syntaxhighlight>:
<syntaxhighlight lang="text" line>
user@HPC.NRW:~$ git push origin branchingTut
Username for 'https://github.com': HPC.NRW-User
Password for 'https://HPC.NRW-User@github.com': ********
#Enumerating objects: 15, done.
Counting objects: 100% (15/15), done.
Delta compression using up to 12 threads
Compressing objects: 100% (13/13), done.
Writing objects: 100% (13/13), 42.00 KiB | 10.50 MiB/s, done.
Total 13 (delta 6), reused 0 (delta 0)
remote: Resolving deltas: 100% (6/6), completed with 1 local object.
remote:
remote: Create a pull request for 'branchingTut' on GitHub by visiting:
remote: https://github.com/HPC.NRW-User/Wikipages/pull/new/branchingTut
remote:
To https://github.com/HPC.NRW-User/Wikipages.git
* [new branch] branchingTut -> branchingTut

user@HPC.NRW:~$ git branch -a
* branchingTut
main
remotes/origin/branchingTut
remotes/origin/main
</syntaxhighlight>
This is very similar to the [[Git_Tutorials/Creating_and_Changing_Repositories|previous]] <syntaxhighlight inline>push</syntaxhighlight> operations with the only difference being that instead of the "main" branch in the remote repository, we will be using the "branchingTut" branch. As this branch did not exist yet, it will be created for us. In lines 18 to 22 we can see all existing branches including the newly created remote branch.

A remote <syntaxhighlight inline>checkout</syntaxhighlight> works the same way a local <syntaxhighlight inline>checkout</syntaxhighlight> does. The main difference is that your local repository might not be up to date with remote branch information, which is why we might miss updates on existing branches (as well as respective <syntaxhighlight inline>git log</syntaxhighlight> data). Below, you can see Git output for a user who cloned our repository after the first tutorial, but before branching was introduced:

<syntaxhighlight lang="text" line>
otherUser@HPC.NRW:~$ git branch -a
* main
remotes/origin/HEAD -> origin/main
remotes/origin/main
</syntaxhighlight>

In order to see the newest changes in the remote repository, they need to use the <syntaxhighlight inline>fetch</syntaxhighlight> command:

<syntaxhighlight lang="text" line>
otherUser@HPC.NRW:~$ git fetch
Username for 'https://github.com': HPC.NRW-otherUser
Password for 'https://HPC.NRW-otherUser@github.com':
remote: Enumerating objects: 15, done.
remote: Counting objects: 100% (15/15), done.
remote: Compressing objects: 100% (7/7), done.
remote: Total 13 (delta 6), reused 13 (delta 6), pack-reused 0
Unpacking objects: 100% (13/13), done.
From https://github.com/HPC.NRW-User/Wikipages
* [new branch] branchingTut -> origin/branchingTut

otherUser@HPC.NRW:~$ git branch -a
* main
remotes/origin/HEAD -> origin/main
remotes/origin/branchingTut
remotes/origin/main
</syntaxhighlight>

Line 10 informs them that a new branch exists in the remote repository. Lines 12 to 16 show that they can see the "branchingTut" branch, however, they still do not have a local version of it. Using <syntaxhighlight inline>git checkout <name of remote branch></syntaxhighlight> they can then create a local branch based on the remote one.

{| role="presentation" class="wikitable mw-collapsible mw-collapsed" style="width:60em" data-expandtext="▼" data-collapsetext="▲"
|+ style="background-color:#2e3871; color:white;text-align: center; width:10em"| <strong>Further remarks</strong>
|-
|It is possible to display updated remote repository information without actually updating:{{Avoid wrap|<syntaxhighlight inline>git ls-remote origin</syntaxhighlight>}}
|-
|If we have several remote repositories, we need to further specify the desired branch: <syntaxhighlight inline>git checkout -b <name of branch> <name of remote repository>/<name of remote branch> </syntaxhighlight>
|-
|<syntaxhighlight inline>git checkout</syntaxhighlight> is actually more versatile and not only used for switching or restoring branches. Therefore, beginning with version 2.23, Git introduced {{Avoid wrap|<syntaxhighlight inline>git switch <name of existing branch></syntaxhighlight>}} for switching to a different branch.
|-
|<syntaxhighlight inline>git switch -c <name of new branch></syntaxhighlight> creates a new branch and switches to it.
|-
|<syntaxhighlight inline>git switch</syntaxhighlight> is still marked as experimental in the Git documentation, which is why we only mention it here.
|}

== Best Practices ==

== Glossary ==

== Useful Links ==

@@ Line 3: / Line 3: @@
 {{Syllabus Git Tutorials}}
-[[File:Git_tutorial_-_branching.png|thumb|700px|Figure 1: Example of basic workflow with branching. The figure can show a local or a remote repository omitting depictions of commit and push operations to keep it simple (they happen somewhere on the dashed lines). Initially, two branches are created from the main branch. Two independent developments occur on those new branches visualized by the different colors green and orange. Theses branches can both belong to one or to two different developers. Once the green segment is finished, its contribution is pulled into the main branch and work on the green segment branch stops. On the other side, the orange segment is developed simultaneously. When development is finished, a new branch is created from this branch. Instead of directly pulling the orange branch into the main branch it continues development on some light purple features while in parallel some brown features are added to orange (e.g., solving bugs in orange code). Later, a pull operation merges the orange/brown and orange/purple branch together and afterwards those orange/brown/purple changes are pulled into the main branch. At this point the main branch will contain contributions from all branches. Unlike the green branch, the orange/brown/purple branch continues to exist, because its purple features are still expanded and will later be pulled again into the main branch.]]
+[[File:Git_tutorial_-_branching.png|thumb|700px|Figure 1: Example of basic workflow with branching. The figure can show a local or a remote repository omitting depictions of commit and push operations to keep it simple (they happen somewhere on the dashed lines). Initially, two branches are created from the main branch. Two independent developments occur on those new branches visualized by the different colors green and orange. Theses branches can both belong to one or to two different developers. Once the green segment is finished, its contribution is merged into the main branch and work on the green segment branch stops. On the other side, the orange segment is developed simultaneously. When development is finished, a new branch is created from this branch. Instead of directly merging the orange branch into the main branch it continues development on some light purple features while in parallel some brown features are added to orange (e.g., solving bugs in orange code). Later, a merge operation combines the orange/brown and orange/purple branch together and subsequently those orange/brown/purple changes are merged into the main branch as well. At this point the main branch will contain contributions from all branches. Unlike the green branch, the orange/brown/purple branch continues to exist, because its purple features are still expanded and will later be merged again into the main branch.]]
-Branching is an important feature of Git, which enables simultaneous work on different parts of a code with minimal interference between acting parties. As the name implies, branching refers to the creation of a separate line of repository tracking that branches of from your "main" repository (also called a branch, but can be understood as the trunk). When developing new features you do not necessarily want to directly <syntaxhighlight inline>commit</syntaxhighlight>  your changes to "main", because they might interfere with your colleagues contribution of other features on a different branch. Even when differences do not directly interfere, they can still lead to a more cumbersome <syntaxhighlight inline>merge</syntaxhighlight> of both branches into "main", once all changes are complete. In larger projects this <syntaxhighlight inline>merge</syntaxhighlight> ''ing'' into the "main" branch is often blocked for most users. A so-called <syntaxhighlight inline>pull</syntaxhighlight> request must be made, so that a responsible person can <syntaxhighlight inline>pull</syntaxhighlight> your changes from your branch into "main".
+Branching is an important feature of Git, which enables simultaneous work on different parts of a code with minimal interference between acting parties. As the name implies, branching refers to the creation of a separate line of repository tracking that branches of from your "main" repository (also called a branch, but can be understood as the trunk). When developing new features you do not necessarily want to directly <syntaxhighlight inline>commit</syntaxhighlight>  your changes to "main", because they might interfere with your colleagues contribution of other features on a different branch. Even when differences do not directly interfere, they can still lead to a more cumbersome <syntaxhighlight inline>merge</syntaxhighlight> of both branches into "main", once all changes are complete. In larger projects this <syntaxhighlight inline>merge</syntaxhighlight> ''ing'' into the "main" branch is often blocked for most users. A so-called <syntaxhighlight inline>pull</syntaxhighlight> request must be made, so that a responsible person can <syntaxhighlight inline>pull</syntaxhighlight> your changes from your branch and <syntaxhighlight inline>merge</syntaxhighlight> them into "main".
 To view all existing branches use the <syntaxhighlight inline>git branch --list</syntaxhighlight> command:
 <syntaxhighlight lang="text" line>