Development using git:Basic usage
This page is proposed for moving ...
if you want to "hide" your changes. Do this if you think there may be other commits against the same things you are working on and want to refresh your local checkout (using a git pull --rebase) from the master. Use git stash apply to get your stash back.
Reset your local repository
if you think your tree is pretty hopeless, need a kill-and-fill to bring the master into your local repository. You will lose local changes.
List the local branch
You can now list your local branch by doing
which should ouput
List your local non committed changes
Now you can start to work on your tree. As soon as you feel you have reached a step in development where you can commit your work locally, use
If you wish to give credit to someone else's work (e.g. you are applying a third party patch):
The format of the commit message should be:
One-line description that's less than 72 chars long <second line empty> Optional longer description with explanation why changes were made. Links to relevant issues in Bugtracker can be done with: ref #<issuenumber> It is also possible to resolve issues with: fixes #<issuenumber>
Think of first line as the subject in an email and the third line and on as the body of the email, describing what the commit does. You don't need the long description but the first line, the short description should be there as it will be showed in the commit log.
List your commits
Keeping your local working branch in sync
Pull the changes from upstream (git.alpinelinux.org)
Create an annotated tag and push it.
Create a new project
Create your own directory that you want to become your new acf-mystuff project.
Create your files and add/commit them to your git-project