$darkmode
Elektra 0.11.0
|
If you are uncomfortable with command line interfaces, there are also plenty of GUI options available.
To configure git, you can use the git config
command. You can configure each project individually, just by running git config <setting> <value>
anywhere within a checked out repository, or for all projects for a user on the local machine using git config --global <setting> <value>
. We recommend you set the following configuration options, when using git:
Also ensure that you have your username and e-mail configured, so your work can be attributed to you:
A commit message should have the following syntax: component: short change description
For a clean and meaningful log the commit message should fulfill the following:
Most commits should have a longer description in the body.
If multiple people worked on a commit, GitHub, supports a nice way to represent this. You can attribute them by leaving two blank lines at the end and then add a single line of Co-authored-by: NAME <NAME@EXAMPLE.COM>
for every other person that worked on it. More Details here
To list all remote branches use:
To checkout a remote branch initially use:
Once you have done this, it will be a local branch, too. Following remote branches should exist:
master
This is the development branch. Please try to not work directly on it, but instead you should use feature branches. So the only commits on master should be non-fastforward merges from features branches. Commits on master should always compile, and all test cases should pass successfully. (see config option above)
To communicate with remote branches, Git supports the file protocol (acessible through the local file system), http and ssh. We generally recommend ssh, as it is encrypted and authentication with ssh-keys is simple and secure.
GitHub supports both HTTP and SSH for communication. Using SSH, you can remove the annoyance of having to enter your password every time. To learn how to add an SSH-Key follow this guide provided by GitHub.
You should always make your own feature branch with:
On this branch it is not so important that every commit compiles or all test cases run.
To merge a branch use (no-fastforward):
If you already did some commits, but want them in a branch, you can do:
We recommend you use your own fork of the main libelektra
repository, if you want to contribute. For more information on creating a fork, please take a look at GitHub's tutorial.
Once you have set up and cloned your fork, you need to keep it in sync with the main repository. To do that, we recommend you never directly commit anything to your fork's master
branch. You also need to add a remote for the main repository:
When you want to sync changes from the main repository into your fork, you can use these commands:
Note: These commands work with any branch checked out. You don't need to switch to the
master
branch first. However, this only works, if you have not modified yourmaster
branch, i.e. the latest commit in your forkedmaster
branch was once the latest commit in the mainmaster
branch.
When you work on a local feature branch, it might happen that a change occurs within the master branch, that introduces merge conflicts. I.e. if you create a pull request, it cannot be merged into master automatically anymore. In these cases, we expect you to rebase your feature branch, so it can be merged automatically once again.
To achieve this, make sure you have your master branch synced up. Then switch to the feature branch you want to update using git checkout <feature-branch-name>
and then type git rebase master
. Sometimes, this will result in a merge conflict.
If you already have pushed changes from your feature branch to a remote branch, you'll need to either overwrite it using git push --force
or push to a new remote branch.
To resolve merge conflicts, edit the files that need to be merged manually. You can check which files need to be merged using git status
. After you are done merging a file manually, you can use git add <path-to-file>
and when you have merged all files, continue with git rebase --continue
.
Note: Keep in mind that manual merges within a rebase are potentially destructive. If you accidentally remove changes you've done in your feature branch, you might be able to recover them using git-reflog, but they could also be deleted by the git-gc. If you're new to manually merging files, consider creating a new branch from your feature branch using
git checkout -b <new-branch-name>
on which you can perform the merge without risk. When you're stuck on a manual merge, you can also always abort the rebase usinggit rebase --abort