You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: book/version_control/version_control.md
+2-1Lines changed: 2 additions & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -76,4 +76,5 @@ Here we present a list of the terminology we may use when referring to version c
76
76
-**Conflict:** when changes made by multiple users to the same file are incompatible, you can get into a conflict. Helping users resolve those conflicts is one of the key advantages of VCS.
77
77
-**Branch:** development (time) line. The main development line is often called `main`.
78
78
-**Merge:** combining the commits of two branches, for example, changes on a development branch are merged into the `main` branch.
79
-
-**Fork:** a separate version of someone else's repository on your own GitHub account. You could see this as a branch you own yourself instead of the original owner of the repository. The original repository is generally called *upstream*, which could be added as an additional *remote* to a local repository.
79
+
-**Fork:** a separate version of someone else's repository on your own GitHub account. You could see this as a branch you own yourself instead of the original owner of the repository. The original repository is generally called *upstream*, which could be added as an additional *remote* to a local repository.
80
+
-**Pull request:** proposal on github to merge a branch or fork into another one. This proposal provides a space for feedback.
Copy file name to clipboardExpand all lines: book/workflows/git/branch_merge.md
+4-63Lines changed: 4 additions & 63 deletions
Original file line number
Diff line number
Diff line change
@@ -1,8 +1,6 @@
1
1
# Branching and merging
2
2
3
-
## What are branches
4
-
5
-
So far, we have only been making commits using the `main` or `master` branch, however, in practice, you will work on a separate branch, whose progress you will later merge with `main`.
3
+
So far, we have only been making commits using the `main` branch, however, in practice, you will work on a separate branch, whose progress you will later merge with `main`.
6
4
7
5
Commits in git have a graph structure, where every node is a commit and edges represent the transition (flow) between commits. Branches can be thought of as pointers to commits, whereas HEAD points to the current commit that we are at. When you switch between branches, you can think of HEAD as the most recent commit on that branch.
8
6
@@ -14,68 +12,11 @@ The main advantage of version control is that it allows developers to work toget
14
12
15
13
16
14
17
-
## Creating a branch
18
-
19
-
First, let us check on what branch we are currently at. On GitHub, navigate to your repository and click on the "Branch: main" dropdown to see the list of branches. The branch with a checkmark is your current branch.
Let us create a new branch from `main` on GitHub, which we will call `first-branch`. Click on the "Branch: main" dropdown, type `first-branch` in the text box, and click "Create branch: first-branch from main".
24
-
25
-
We can move to the newly created branch by selecting it from the branch dropdown.
26
-
27
-
28
-
29
-
Let us modify our `README.md` file again and add a sentence to the first line of it. Navigate to the `README.md` file, click the pencil icon to edit it, and add your content to the first line:
30
-
31
-
```
32
-
Now I've edited this file on the `first-branch`-branch.
33
-
```
34
-
35
-
We will commit the new changes by filling out the commit message and clicking "Commit changes".
36
-
37
-
38
-
39
-
## Merging branches / pull requests
40
-
41
-
Note that when we switch to `main`, the `README.md` file does not contain the changes we made on the other branch.
42
-
43
-
Before merging our progress from `first-branch`, it is advisable to merge `main` into it first. This is done because we regard the `main` branch as the "face" of our project. When somebody is looking at our repository, they are likely to check the things on `main` first. Moreover, if there are any bugs from merging, it is better to resolve them on our separate branch. Sometimes it happens that after merging your progress to the `main` branch, the code on the `main` branch is no longer working correctly.
44
-
45
-
Therefore, we will first go back to our branch `main`. Note that the edit we made is no longer visible. Let's add a commit here too to `README.md` at the last line:
46
-
47
-
```
48
-
And now I've edited this file on the `main`-branch.
49
-
```
50
-
51
-
We can merge the `main` branch into `first-branch` by creating a pull request. On GitHub, go to the "Pull requests" tab, click "New pull request", select `first-branch` as the base branch and `main` as the compare branch, and click "Create pull request". We can check (as shown below) that there are no conflicts and then we click "Merge pull request" to merge `main` into `first-branch`.
We will now return to `main` and merge `first-branch` into it with another pull request. Follow the same steps as before, but this time select `first-branch` as the compare branch and `main` as the base branch.
60
-
61
-
62
-
63
-
## Deleting branches
64
-
65
-
Branch `first-branch` has lived its use, so we can delete it as we do not plan on making new changes to it. This will not remove any of the commits made on it. It will only remove the pointer itself. Do this from the pull request page by clicking "Delete branch".
66
-
67
-
68
-
69
-
## Branches locally
15
+
In the commit graph above you see two branches (`Main` and `Dev Branch`). The orange commits `q1` and `q2` were part of a branch but that branch is merged with `main`. The `HEAD` is at `m2`, so if you're looking at the files in repository, you see the stated of all the files after that commit. E.g. the changes from `a1`, `m3` and `q2` (and all others not in front of `m2`) are not visible. So it's not only possible to change branch, but also to go back in time with `Head`!
70
16
71
-
All of the above operations can also be performed locally using a Git client like VS Code. Here are the basics:
17
+
The `Dev branch` was created from the state of the `Main` branch at `m1` and after two commits `a1` and `a2`, the changes from `m2` have been merged into that branch in commit `a3`.
72
18
73
-
1. Check Current Branch: Open the source control panel in VS Code to see the current branch.
74
-
2. Create a New Branch: Use the branch icon in the status bar or the command palette (`Ctrl+Shift+P`) and select `Git: Create Branch`.
75
-
3. Switch Branches: Click on the branch name in the status bar and select the branch you want to switch to.
76
-
4. Make Changes and Commit: Edit your files, then use the source control panel to stage and commit your changes.
77
-
5. Merge Branches: Use the command palette to select `Git: Merge Branch` and choose the branch to merge from.
78
-
6. Delete Branches: Use the command palette to select `Git: Delete Branch` and choose the branch to delete.
19
+
The orange branch was created from the state of `Main` at `m3`, while after one commit `q1`, the changes from `Dev branch` were included into the orange branch with commit `q2`. After that, it is merged into `Main` at `m5`, effectively merging the `Dev branch` into `Main too`. After that merge, the pointer of the orange branch is deleted, so it's not trivial to go back to the orange branch. However, this can still be done by checking out `Head` to commit `q2`.
0 commit comments