... | ... | @@ -72,8 +72,9 @@ Now you can start working on your branch. |
|
|
```bash
|
|
|
# back into the feature branch
|
|
|
$ git checkout feat-0001-my-example
|
|
|
## add new file(s) and commit with a proper message
|
|
|
# add new file(s) and commit with a proper message
|
|
|
$ git add newfile
|
|
|
# commit should be signed
|
|
|
$ git commit -s
|
|
|
```
|
|
|
|
... | ... | @@ -81,12 +82,23 @@ If your development takes longer, make sure to synchronize regularly with `origi |
|
|
|
|
|
```bash
|
|
|
$ git checkout feat-0001-my-example
|
|
|
# Retrieve the latest and merge into feature branch
|
|
|
# Retrieve the latest and rebase the feature branch with develop
|
|
|
$ git fetch origin
|
|
|
$ git rebase origin/develop
|
|
|
```
|
|
|
|
|
|
However you may have forgotten to do the `rebase` for a long time. The `git rebase` process is replaying all the commits from the `develop` branch.
|
|
|
|
|
|
In case of merge conflicts, it can be painful because you may have to resolve conflicts several times. The rebase will stop each time you have a conflict, you need to resolve it manually and then continue the rebase. In that case it certainly better (not necesserily easy) to resolve merge conflicts at once.
|
|
|
|
|
|
```bash
|
|
|
$ git checkout feat-0001-my-example
|
|
|
# Retrieve the latest from develop and merge into feature branch
|
|
|
$ git fetch origin
|
|
|
$ git merge origin/develop
|
|
|
```
|
|
|
|
|
|
****IT IS THE DEVELOPER/CONTRIBUTOR'S RESPONSABILITY TO PERFORM REGULAR MERGES ONTO ITS FEATURE BRANCH****
|
|
|
**IT IS THE DEVELOPER/CONTRIBUTOR'S RESPONSABILITY TO PERFORM REGULAR MERGES ONTO ITS FEATURE BRANCH**
|
|
|
|
|
|
## 2.3. Pushing into the central repository ##
|
|
|
|
... | ... | @@ -96,6 +108,12 @@ To have a backup, to collaborate with other people, or to create a merge request |
|
|
$ git push origin feat-0001-my-example
|
|
|
```
|
|
|
|
|
|
In case of problem, you may have to force the push:
|
|
|
|
|
|
```bash
|
|
|
$ git push --force origin feat-0001-my-example
|
|
|
```
|
|
|
|
|
|
# 3. Bug-fix branches #
|
|
|
|
|
|
Bug-fix branches are very much like release branches in that they are also meant to prepare for a new production release, albeit unplanned.
|
... | ... | |