|
|
Using Git Branches
|
|
|
--------------------
|
|
|
# Using Git Branches
|
|
|
|
|
|
|
|
|
Git branches are a good way to handle contributions of several developers, where some are working on new, maybe somewhat experimental parts of the content, while the established part of the content is protected from being ``messed up'' by premature or erroneous contributions.
|
|
|
|
... | ... | @@ -8,6 +8,7 @@ By default, every repository has at least one branch, which is called Master. If |
|
|
If a new branch is created, the version history bifurcates at this point and is being kept separately for Master and the new branch. Users can synchronize local clones with either of them (this process is called checkout) and can commit and push to one or the other (provided that they have permission to push to the Master branch -- the project owner can restrict the permission to that). At a later stage, if it turns out that the content of the new branch is useful, it can be re-included into the Master branch -- this is called Merging.
|
|
|
|
|
|
**Creating a new branch**
|
|
|
|
|
|
In the following, we assume that you have access to a repository called MyProject on OpenVT, which you have readily cloned to your computer. Open a terminal and browse into the respective folder. In order to make sure to have the latest version of the content, do a
|
|
|
|
|
|
```bash
|
... | ... | @@ -37,7 +38,7 @@ git status |
|
|
will tell you all that.
|
|
|
|
|
|
**Merging branches**
|
|
|
tbc
|
|
|
In many cases, after having successfully modified the branch and tested the modifications, you might want to re-include the modifications into the master branch. This process is called merging and Git helps you to do it flawlessly, no matter how many modifications have been done on either of the branches in the mean time.
|
|
|
|
|
|
|
|
|
|
... | ... | |