This is an example workflow with git to demonstrate the usage of its basic commands.
First, go to your target directory like ~/my/path/ or C:\my\path\ and create a new git repository.
$ git init
Initialized empty Git repository in c:/my/path/.git/Then create some content.
$ echo "<html><head><title>Test Website</title></head>
<body>There is no text yet</body>
</html>" > index.htmlAdd all files (index.html) from the current directory (.) to git's staging area.
$ git add .Check whether git recognized the file.
$ git status
On branch master
Initial commit
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: index.htmlCommit the staging area to the local repository. This creates a new fixed version of your repository. You can always go back to this current state of files.
$ git commit -m "Initial commit. First website."
[master (root-commit) 8d5d2b6] Initial commit. First website.
warning: LF will be replaced by CRLF in index.html.
The file will have its original line endings in your working directory.
1 file changed, 1 insertion(+)
create mode 100644 index.htmlNote: The warning message informs users that git will take care of the line feed or new line (\n) character vs. carriage return line feed (\r\n) problem on different operating systems.
Of course, "Initial commit. First website." is not an ideal commit text. Good descriptions are crucial for the comprehensibility of the changes to a repository over time.
The internet provides a few guidelines to improve expressivity and style.
A short version comes from github.com.
This is a sample for the message after a git commit command.
Capitalized, short (50 chars or less) summary
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body. The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase can get confused if you run the
two together.
Write your commit message in the present tense: "Fix bug" and not "Fixed
bug." This convention matches up with commit messages generated by
commands like git merge and git revert.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, preceded by a
single space, with blank lines in between, but conventions vary here
- Use a hanging indentAfter the file(s) are committed, check the version history. There is an entry with the commit message.
$ git log
commit 8d5d2b63b53c2d9cb3c8a0f02c552fdee52b5106
Author: myUsername <mail@server.com>
Date: Fri Oct 17 16:09:21 2014 +0200
Initial commit. First website.
user@computer /C/my/path (master)Now, add a new feature in an save environment - a branch. Therefore, the unfinished changes will not alter the main version history of your repository called the master branch. BRanches are created by the -b (branch) flag of the checkout command. Call the new branch content_for_website.
$ git checkout -b content_for_website
Switched to a new branch 'content_for_website'
user@computer /C/my/path (content_for_website)Add some changes to the file(s).
$ echo "<html><head><title>Test Website</title></head>
<body>Some text</body>
</html>" > index.htmlNow commit them. Editing, creating or deleting files cause the staging area to change.
$ git status
On branch content_for_website
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: index.html
no changes added to commit (use "git add" and/or "git commit -a")In order to commit, add the updated (-u) files to the staging area.
$ git add -u .
warning: LF will be replaced by CRLF in index.html.
The file will have its original line endings in your working directory.The current content of the stagig area. Notice that the suggestion to add disappeared.
$ git status
warning: LF will be replaced by CRLF in index.html.
The file will have its original line endings in your working directory.
On branch content_for_website
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: index.html
user@computer /C/my/path (content_for_website)Finally, commit to the current branch content_for_website.
$ git commit -m "Website's final version."
[content_for_website warning: LF will be replaced by CRLF in index.html.
The file will have its original line endings in your working directory.
c843e99] Website's final version.
warning: LF will be replaced by CRLF in index.html.
The file will have its original line endings in your working directory.
1 file changed, 1 insertion(+), 1 deletion(-)
user@computer /C/my/path (content_for_website)Commits should represent a coherent set of changes. If a new commit is only a small addition to an existing one, try to squash them into one.
Assume that the content in the example needs to be changed again and this change is to small for a proper commit.
$ echo "<html><head><title>Test Website</title></head><body>Some text. And this
..</body></html>" > index.html
user@computer /C/my/path (content_for_website)Add and commit the change.
$ git add -u .
...
$ git commit -m "Late addition to website."
...Now, there are three commits in the local git repository.
$ git log
commit 07b7eb88f933ce2160f03b85dcd54ea5f88c68cf
Author: myUsername <mail@server.com>
Date: Fri Oct 17 16:18:02 2014 +0200
Late addition to website.
commit c843e999a61e278b3096e09ac823ec8289d9fd5c
Author: myUsername <mail@server.com>
Date: Fri Oct 17 16:16:37 2014 +0200
Website's final version.
commit 8d5d2b63b53c2d9cb3c8a0f02c552fdee52b5106
Author: myUsername <mail@server.com>
Date: Fri Oct 17 16:09:21 2014 +0200
Initial commit. First website.
user@computer /C/my/path (content_for_website)Use the last two (HEAD~2) of them and change them into one by rebasing interactively (-i).
$ git rebase -i HEAD~2
[detached HEAD ae4612f] Website's final version.
1 file changed, 1 insertion(+), 1 deletion(-)
Successfully rebased and updated refs/heads/content_for_website.
user@computer /C/my/path (content_for_website)Due to the interactive mode, your default editor will show. Edit the displayed files contents in a way that the first pick is preserved and the other ones are replayed by s or squash.
pick c843e99 Website's final version.
s 07b7eb8 Late addition to website.A new file will be displayed by the text editor regarding the joined commit message. In this example, only the original or first commit message was used ("Website's final version.").
$ git log
commit ae4612f0f0c2072faac2d222adacc52c3219bf8a
Author: myUsername <mail@server.com>
Date: Fri Oct 17 16:16:37 2014 +0200
Website's final version.
commit 8d5d2b63b53c2d9cb3c8a0f02c552fdee52b5106
Author: myUsername <mail@server.com>
Date: Fri Oct 17 16:09:21 2014 +0200
Initial commit. First website.
user@computer /C/my/path (content_for_website)Switch to the master banch by filling the repositories directory with the files from master.
$ git checkout master
Switched to branch 'master'
user@computer /C/my/path (master)Notice that /C/my/path (content_for_website) changed back to /C/my/path (master).
For a rather graphical display of the current branches you may use one of these commands. More at stackoverflow.com.
$ git log --graph --oneline --all
$ git log --graph --abbrev-commit --decorate --date=relative --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(dim white)- %an%C(reset)%C(bold yellow)%d%C(reset)' --allMerge content_for_website into the current branch, which is the master.
$ git merge content_for_website
Updating 8d5d2b6..ae4612f
Fast-forward
index.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
user@computer /C/my/path (master)Show the current version of index.html in the master branch!
$ cat index.html
<html><head><title>Test Website</title></head><body>Some text. And this..</body>
</html>