Development using git:Basic usage: Difference between revisions

From Alpine Linux
(add subtitle for commit message format)
mNo edit summary
 
(2 intermediate revisions by one other user not shown)
Line 1: Line 1:
{{Move|Git|All git development articles should be consolidated}}
== Stashing ==
== Stashing ==


Line 28: Line 30:
  {{Cmd|git commit <specific files> --author "Name Surname <user@example.com>}}
  {{Cmd|git commit <specific files> --author "Name Surname <user@example.com>}}


=== Commit message format ===
The format of the commit message should be:
The format of the commit message should be:
  One-line description that's less than 72 chars long
  One-line description that's less than 72 chars long
  ''<second line empty>''
  ''<second line empty>''
  Optional longer description with explanation why changes were made. Lines should not
  Optional longer description with explanation why changes were made. Links to relevant issues
be longer than 72 chars.
in Bugtracker can be done with:
Links to relevant issues in Bugtracker can be done with:
   
   
   ref #<issuenumber>
   ref #<issuenumber>
Line 45: Line 44:


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.
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.
{{tip|You can add the following line to your {{path|~/.vimrc}}:<pre>autocmd FileType gitcommit set textwidth=72</pre> }}


== List your commits ==
== List your commits ==
Line 54: Line 55:
{{Cmd|git pull --rebase}}
{{Cmd|git pull --rebase}}
{{tip|You can tell git to use rebase, rather than merge (means that '--rebase' would automatically be issued at 'git pull').<BR>
{{tip|You can tell git to use rebase, rather than merge (means that '--rebase' would automatically be issued at 'git pull').<BR>
Run the command: <pre>git config branch.origin.rebase true</pre>Next time you do 'git pull' you are actually doing a 'git pull --rebase'.}}
Run the command: {{Cmd|git config branch.origin.rebase true}} Next time you do 'git pull' you are actually doing a 'git pull --rebase'.}}


== Git Tag ==
== Git Tag ==

Latest revision as of 19:23, 9 December 2018

This page is proposed for moving ...

It should be renamed to Git. All git development articles should be consolidated (Discuss)

Stashing

git stash

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

git checkout -f master

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

git branch

which should ouput

* master

List your local non committed changes

git status

Commit

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

git commit -a

or

git commit <specific files>

or

git add <specific files> git commit

If you wish to give credit to someone else's work (e.g. you are applying a third party patch):

git commit <specific files> --author "Name Surname <user@example.com>

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.

Tip: You can add the following line to your ~/.vimrc:
autocmd FileType gitcommit set textwidth=72

List your commits

git log


Keeping your local working branch in sync

Pull the changes from upstream (git.alpinelinux.org)

git pull --rebase

Tip: You can tell git to use rebase, rather than merge (means that '--rebase' would automatically be issued at 'git pull').
Run the command:

git config branch.origin.rebase true

Next time you do 'git pull' you are actually doing a 'git pull --rebase'.

Git Tag

Create an annotated tag and push it.

git tag -a tagname -m 'commit message (e.g release 1.x)' git push && git push --tags

Create a new project

Create your own directory that you want to become your new acf-mystuff project.

mkdir acf-mystuff cd acf-mystuff git init

Create your files and add/commit them to your git-project

git add ./ git commit