@@ -64,19 +64,29 @@ You should see the files from this repository appear in the project's directory.
You can open the source files in "/src" with any text editor or a development environment of your choice.
I will be using "Code::Blocks" for my demonstrations.
Once you have changed a source code file and want to keep your changes save, you can use
`git add <file_path>`
in order to register the file for subsequent versioning.
The command
`git status`
should give you an overview of which files are new, which have been removed and which have been changed.
All three types of changes can be registered for subsequent versioning via `git add`
Make sure not to add any binary/compiled files as git is not good at keeping those files and it bloats your repository.
In case you ever accidentally add any file, you can revert the registration (not the actual changes to the file) via
`git reset <file_path_to_unregister>`
If you have accidentally changed or deleted a file and would like to reset it to its last stored state, you need to use
`git checkout <file_path_to_restore>`
Once you have registered all changed files that you would like to store, run
`git commit`
and enter a message describing the changes you performed.
This will be done using a command line text editor.
If you have vim set as your default editor, you first need to type the letter `i` to enter "input" mode.
...
...
@@ -92,14 +102,18 @@ A good practice would be to add and commit every smallest set of changes to the
### How to protect the versions and work on multiple machines.
If you want to protect your stored versions/commits from hard drive failure/loss or if you plan to cooperate with other people you will want to copy your changes back to the gitlab server.
You can always do that by running
`git push`
and entering your credentials.
When running this command for the first time, git might recommend running an alternate version of this command to setup the repository even further.
In that case just copy the recommended command and run that.
Any subsequent pushes can be run by just `git push`.
It might happen that git rejects your push due to changes on the server.
In that case you will need to retrieve the changes on the server using
`git pull`
first.
Git will attempt to unify your changes with the version on the server.
If it succeeds it will suggest a commit message for the merge of the versions which you can simply accept and retry the push.
...
...
@@ -118,9 +132,13 @@ Congratulations, you have successfully created your own version of this reposito
You can even grant other people access to your code on the gitlab which should always be the preferred version over sending someone a zip archive via E-mail.
The default options for `git push` and `git pull` will only update your own version of the project and will only retrieve changes to your own gitlab repository.
If you ever wish to obtain changes introduced to other remote repositories such as this template repository ("vorlage") you can tell git to specifically look for changes there by calling
`git pull <remote_name>`
most likely
`git pull vorlage`
Merge conflict might still occur.
You can resolve them the same way that you resolve merge conflicts within your own project.
