| Developer GuideEffective revision control is essential to all multi-developer projects. It allows all developers in a team to create, review, revise, and document code in a systematic and orderly manner. Red Hat Enterprise Linux 6 supports three of the most popular open source revision control systems: CVS, SVN, and Git. The tools for these revision control systems provide access to a wide range of publicly available open source code, as well as the capability to set up individual internal code repositories. The following section provides a brief overview and references to relevant documentation for each tool. 2.1. Concurrent Versions System (CVS)Concurrent Versions System (CVS) is a centralized version control system based on RCS format with a client-server architecture. It was the first version control system and the predecessor for Subversion (SVN). This section discusses the various elements of CVS, both the good and the bad. CVS was developed when network connectivity was unreliable and would often drop out. This meant that if several files were committed at once and the network dropped out, the commit would fail. This can still occur now if a network is unreliable but is less common with modern networking infrastructure. If it happens, the CVS administrator has two options to resolve the problem. The first is to use the admin command to remove stall locked files and back out the changed files. The second option is to reissue the commit command. CVS uses one central location for making back-ups, which is useful for an unstable network. It allows the enforcement of a commit policy through manually prepared triggers (automated tests, builds, Access Control Lists (ACLs), integration with a bug tracking system) due to centralized architecture. To create more detailed commits to the backup, CVS can also expand keywords that are marked by the at-sign (@) to record commit details (committer name, commit message, commit time, for example) into a committed file. In order to keep track of these commits, CVS uses a server to track the changes for each file separately and in reverse time order. By doing so, the latest version is stored directly and can be retrieved quickly, where older versions must be recomputed by the server. Each changed, committed file is tracked separately with an independent revision identifier. This can make it difficult to discover which files have been changed by the commit when multiple changed files are committed. To counter this, users should tag the repository state to refer back and view the changes when required. The CVS repository can be accessed by two methods. If the repository is on the same machine as the client (:local: access method) then the client spawns the server on its behalf. If the repository is on a remote machine, the server can be started with rsh/SSH (CVS_RHS environment variable) by a client or by an inet daemon (/etc/xinetd.d/cvs) and different authentication methods (:gserver: access method integrates Kerberos authentication, for example) can be used. Finally, for security a client-server approach is used with CVS. This means that the client is dependent on connectivity to the server and cannot perform any operation (committing, or reading the commit log) without permission to access the server. This is a sequence of commands demonstrating CVS repository creation in the $CVSROOT directory (using an absolute path to signal :local: access method), importing sources from $SOURCES, checking them out from the repository into $WORKDIR, modifying some files, and committing the changes. Procedure 2.1. Using CVS Initialize CVS storage. $ mkdir "$CVSROOT"$ cvs -d "$CVSROOT" init This creates the CVSROOT subdirectory under $CVSROOT with repositories configuration. Import code from $SOURCES directory into CVS as $REPOSITORY, tagged with $VENDOR_TAG and $RELEASE_TAG with a commit $MESSAGE. $ cd "$SOURCES"$ cvs -d "$CVSROOT" import -m "$MESSAGE" "$REPOSITORY" \ "$VENDOR_TAG" "$RELEASE_TAG" The $SOURCES content should be imported into CVS under $CVSROOT/$REPOSITORY. It is possible to have more repositories in one CVS storage, though this example just uses the one. The $VENDOR_TAG and $RELEASE_TAG are tags for implicit repository branches. Different developers can now check the code out into $WORKDIR. $ cd "$WORKDIR"$ cvs -d "$CVSROOT" checkout "$REPOSITORY" Do not check out into the original $SOURCES. This could cause data corruption on the client side and CVS will print errors on various CVS invocations. The latest version of the CVS repository has been transferred into the $REPOSITORY subdirectory. The developer can also check out multiple repositories from one server. $ cd $REPOSITORY To schedule adding a new $FILE use: $ vi "$FILE"$ cvs add "$FILE" The developer can modify an $EXISTING_FILE. $ vi "$EXISTING_FILE" Finally, the developer can commit these changes with a $COMMIT_MESSAGE. $ cvs commit -m "$COMMIT_MESSAGE"
It is possible to export the $CVSROOT value as a CVSROOT environment variable and the cvs tool will respect it. This can free the developer from repetitively supplying the -d "$CVSROOT" option. The value is stored in the CVS helper subdirectory at initial check-out, and the CVS tool takes the value from there automatically. The CVS manual page can be accessed with man cvs. There is also a local FAQ page located in /usr/share/doc/cvs-version/FAQ. 2.2. Apache Subversion (SVN)Subversion is a version control system that manages files and directories, the changes made to them, and can recover and examine them in case of a fault. It was created to match CVS's features and preserve the same development model, and to address any problems often encountered with CVS. This allowed CVS users to convert to SVN with minimal effort. This section will cover the installation of SVN and provide details on the everyday uses of SVN. SVN can be installed with a binary package, directly from source code, or from the console. The easiest way to install SVN would be through the console with the command yum install subversion. Selecting this option ensures that only Red Hat certified packages are used and removes the requirement to manually update them. Finally, SVN can be installed from source code, though this can be quite complex. From the SVN website, download the latest released source code and follow the instructions in the install file. In order to begin using SVN, first create a new repository. SVN has no way to determine the difference between projects; it is up to the user to administer the file tree and place the project in separate directories as they prefer. Use the following commands to create the repository: # mkdir /var/svn# svnadmin create /var/svn/repos# ls /var/svn/repos/conf db format hooks locks README.txt This command will create the new directory /var/svn/repos with the required database files. The SVN repository is accessed with a URL. Usually these use the standard syntax of http:// but it is not limited by this. It also accepts the following URL forms: - file:///
Direct repository access (on local disk) - http://
Access with WebDAV protocol to Subversion-aware Apache server - https://
Same as http:// but with SSL encryption - svn://
Access via custom protocol to an svnserver server - svn+ssh://
Same as svn:// but through an SSH tunnel.
If the URL contains spaces place quotation marks around it to ensure the shell treats it as a single argument. Otherwise the URL will be invalid. Assuming that a project consisting of multiple files has already been created, organize them so that they are all in one directory. It is recommended that you use three top-level directories named branches, tags, and trunk. This is not required by SVN but it is a popular convention. The trunk directory should contain the projects files, and the branches and tags directories should remain empty. For example: myproject/branches/myproject/tags/myproject/trunkfoo.cbar.cMakefile
Once the information has been organized appropriately it is time to import it into the SVN repository. This is done with the svn import command. For example: $ svn import /path/to/mytree \http://host.example.com/svn/repo/myproject \-m "Initial import"Adding myproject/foo.cAddingmyproject/bar.cAddingmyproject/subdirAddingmyproject/subdir/quux.hCommitted revision 1.$ SVN creates the required directories based on how the file tree is set up. It can now be viewed at the URL created, or by the command: $ svn list http://host.example.com/svn/repo/myproject Now that the first revision of the project has been checked into the repository, it can be edited and worked on. To do this, create a working copy. This is done with the svn checkout command. For example: $ svn checkout http://host.example.com/svn/repo/trunkA trunk/READMEA trunk/INSTALLA trunk/src/main.cA trunk/src/header.h...Checked out revision 8810.$ A directory with a working copy of the project is now created on the local machine. It is also possible to specify where the local directory a project is checked out to with the following command: $ svn checkout http://host.example.com/svn/repo/trunk my-working-copy If the local directory specified does not exist, SVN will create it. Every directory in the working copy contains a subdirectory called .svn. Being an administrative directory, it will not usually appear with a list command. This is an important file and should not be deleted or changed. Subversion uses this directory to manage the working copy and tampering with it will cause errors and instability. If the directory is accidentally deleted the best way to fix it is to delete the entire containing directory (a normal system delete, not svn delete) and run svn update from a parent directory. The deleted directory will be recreated, including the missing or changed .svn directory. This can cause a loss of data. Although the working copy is now ready to edit, keep in mind that whenever the file tree changes, these changes must be sent to the repository as well. This is done with a variety of commands. svn add filenameNewly created files or directories, including the files they contain, are flagged to be added to the repository. The next commit will add them to the repository where they can be accessed and viewed by all. svn delete filenameFiles or directories, including the files they contain, are flagged to be deleted from the repository. The next commit will remove them. However, the deleted files can still be accessed in previous revisions through SVN. svn copy filename1 filename2Creates a new file, filename2, which is an exact copy of filename1. It then schedules filename2 for addition on the next commit. Note that svn copy does not create intermediate directories unless the --parents option is passed. svn move filename1 filename2This is the same as svn copy filename1 filename2 followed by svn delete filename1. A copy is made, and then filename1 is scheduled to be deleted on the next commit. Note that svn move does not create intermediate directories unless the --parents option is passed. svn mkdir directoryThis command both creates the specified directory and then schedules it to be added to the repository on the next commit.
Sometimes it is impractical to check out an entire working copy in order to do some simple changes. In these circumstances it is possible to perform svn mkdir, svn copy, svn move, and svn delete directly on the repository URL. Be careful when using these commands as there is no way to check the results with a working copy first. 2.2.5. Committing ChangesOnce the edits are complete and have been verified to work correctly, it is time to publish them so others can view the changes. For each file in the working copy, SVN records two pieces of information: Using this information, SVN sorts the working copy on the local system into four categories: - Unchanged; current
The file in the working directory is unchanged and matches the copy in the repository, meaning no changes have been committed since the initial check out. Both svn commit and svn update will do nothing. - Locally changed; current
The file in the working directory has been edited but has not yet been committed to the repository, and the repository version has not been changed since the initial checkout. Running svn commit will update the repository with the changes in the working directory; running svn update will do nothing. - Unchanged; out of date
The file in the working directory has not been edited, but the version in the repository has, meaning that the working copy is now out of date. Running svn commit will do nothing; running svn update will merge the changes in the repository with the local working copy. - Locally changed; out of date
The file in both the working directory and the repository has been changed. If svn commit is run first, an 'out-of-date' error will occur. Update the file first. Running svn update will attempt to merge the changes in the repository with those on the working copy. If there are conflicts SVN will provide options for the user to decide on the best course of action to resolve them.
Running svn status will display all of the files in the working tree that do not match the current version in the repository, coded by a letter. - ? item
The file is not recognized by SVN; that is it is in the working copy, but has not yet been added to the repository, or been scheduled for any action. - A item
The file is scheduled for addition to the repository and will be added on the next commit. - C item
The file is in conflict with a change made on the repository. This means that someone has edited and committed a change to the same section of the file currently changed in the working copy, and SVN does not know which is 'correct'. This conflict must be resolved before the changes are committed. - D item
The file is scheduled for deletion on the next commit. - M item
The file has been modified and the changes will be updated on the next commit.
If the --verbose (-v) is passed with svn status, the status of every item in the working copy will be displayed, even those that have not been changed. For example: $ svn status -vM4423sallyREADME4430sallyINSTALLM4420harrybar.c4418irastuff4435harrystuff/trout.cD4419irastuff/fish.c4421sallystuff/thingsA 0 ? ?stuff/things/bloo.h4436harrystuff/things/gloo.c Along with the letter codes, this shows the working revision, the revision in which the item was last changed, who changed it, and the item changed respectively. It can also be useful to see which items have been modified in the repository since the last time a checkout was performed. This is done by passing the --show-updates (-u) with svn status. An asterisk (*) will be displayed between the letter status and the working revision number on any files that will be updated when performing an svn commit. Another way to view changes made is with the svn diff command. This displays changes in a unified diff format, describing changes as 'snippets' of a file's content where each line is prefixed with a character: a space for no change, a minus sign (-) for a line removed, and a plus sign (+) for an added line. Occasionally a conflict will occur. SVN provides the three most common responses (postpone, diff-full, and edit) and a fourth option to list all the options and what they each do. The options available are: - (p) postpone
Mark the conflict to be resolved later. - (df) diff-full
Display the differences between the base revision and the conflicted file in unified diff format. - (e) edit
Change merged file in an editor. - (r) resolved
Accept the merged version of the file. - (mf) mine-full
Accept my version of the entire file, ignoring the most recent changes in the repository. - (tf) theirs-full
Accept their version of the entire file, ignoring the most recent changes in the local working copy. - (l) launch
Launch an external tool to resolve conflict (this requires set up of the chosen external tool beforehand). - (h) help
Displays the list of options as detailed here.
Finally, provided the project has been changed locally and any conflicts have been resolved, the changes can be successfully committed with the svn commit command, appending the option -m: $ svn commit filename -m"Fixed a typo in filename"SendingfilenameTransmitting file data .Committed revision 57.$ As can be seen above, the -m option allows a commit message to be recorded. This is most useful when the message is meaninful, which in turn makes referring back over commits straightforward. The most updated version is now available for anyone with access to the repository to update their versions to the newest copy. The command svn --help provides information on the available commands to be used in conjunction with SVN and svn subcommand --help provides more detailed information on the specified subcommand. Git is a version control system that was not written to improve on CVS and SVN but rather in retaliation to them. Git was created with four design points in mind: Not like CVS and SVN. Torvalds, the creator of Git, does not like these programs and wanted to make something that was unlike them. Support a BitKeeper-like workflow. The way a project is managed ideally follows the same process as BitKeeper, while keeping its own design and not becoming a BitKeeper clone. Strong safeguards against accidental or malicious corruption. Very high performance.
To accomplish this, Git approaches how it handles data differently to its predecessors. This section will go through the most common processes in a day's use of Git. Previously the version controls covered (CVS and SVN) treated data as changes to a base version of each file. Instead, Git treats its data changes as separate snapshots of what the files look like and stores a reference to that file (though if the file remains unchanged, Git will store a link to the previous identical version rather than copy another file). This creates a kind of new mini file system. The image below compares these concepts visually: Git is particularly fast, aided by not having to constantly connect to a remote repository. The snapshot nature of Git and how all versions are stored on the local file system means that nearly everything can be done without connecting to any kind of network and the history of the project is available locally. To fulfill Torvalds' integrity requirement, everything in Git is check-summed before being stored and then referred to by that check-sum. This means the contents cannot be changed without Git's knowledge and information cannot be lost in transit or corrupted. A SHA-1 hash mechanism (a forty-character hexadecimal sting) is used for this. In addition, there is very little in Git that cannot be undone. This is aided by the three main states a file can reside in. - Committed
Data is safely stored on the local database, and unchanged. - Modified
The file has been changed but not yet committed to the database. - Staged
A modified file has been marked to be committed in its current version.
Git can be installed either from source or from the console. If the user is confident enough then the recommendation is to install from source, as the binary installers do not always have the most up-to-date version available. To install Git from source code, use the following procedure: Procedure 2.2. To install Git from source code Install the libraries Git depends on: curl, zlib, openssl, expat, and libiconv. # yum install curl-devel expat-devel gettext-devel \openssl-devel zlib-devel gcc Compile and install. # tar -zxf git-1.7.6.1.tar.gz# cd git-1.7.6.1# make prefix=/usr/local# make prefix=/usr/local install It is now possible to get updates for Git, from Git. $ git clone git://git.kernel.org/pub/scm/git/git.git
Installing Git with a binary installer from the console is as simple as using the following command. # yum install git
After installing there are a few steps to personalize Git and get it ready for use. Once these settings are configured, they persist for future Git sessions, however to be change them again in the future, run the commands again. These changes are made by altering variables stored in three different places: The /etc/gitconfig file contains variables for every user on the system and all their repositories. It holds the base settings and passing --system to git config sets it to read and write from this file. The ~/.gitconfig file is specific to the user. Passing --global tells Git to read and write to this file, overriding the settings made in the first point. The config file in the Git directory (.git/config) of the repository currently being used. This is specific to this repository only and overrides the settings in both the first and the second point.
Before the first commit, enter some details into Git by supplying the name and email address that will appear with change. For example, if the user's name is John Q. Smith, use the following commands: $ git config --global user.name "John Smith"$ git config --global user.email "jsmith@example.com" As explained above, by passing the --global option these settings remain constant, but can be overridden for specific repositories. By default, whenever an editor is required, Git launches Vi or Vim. However, if this is not preferred it is possible to change this to another editor. To do so, use the following command: git config --global core.editor EditorName The diff tool is often used to view the changes in various files, useful for double checking things before committing them. Use the following command to set the preferred diff tool: $ git config --global merge.tool DiffTool Finally, it is useful to check these settings to ensure they are correct. To do this run: $ git config --listuser.name=John Smithuser.email=[email protected] If there are different settings in different files, Git will list them all, with the last value for the active one. It is also possible for Git to check the specific response to a variable by using the git config {key} command. For example: $ git config user.nameJohn Smith The Git repository is where the metadata and object database is stored for a project. This is where the project is pulled from in order to get a local clone of a repository on a local system. There are two options for obtaining a Git repository. The first is used when a directory already exists and and is required to initialize a Git repository. The second is cloning a repository that already exists. To clone an existing repository (for example, to contribute to) then run the following command: $ git clone git://location/of/git/repository.git Note that the command is git clone as opposed to git checkout as it might be for a version control system similar to CVS and SVN. This is because Git receives a copy of every file in the project's entire history, as opposed to only the most recent files as with other version control systems. The above command creates a directory where the name is the last component of the URL, but with any .git suffix removed. However, the clone command can use any other name by appending the desired directory name to the end: $ git clone git://location/of/git/repository.git my_git_repo Finally, even though this command uses the git:// protocol, it is also possible to use http:// or https:// as appropriate. To create a new Git repository ready to create data for, first navigate to the project's directory and type: $ git init This creates a skeleton of a Git repository, containing all the necessary files ready for content to be created and added. Now that either a skeleton Git repository is set up or a local clone copied and ready on the local system it is time to look at the rest of the Git cycle. This image shows how the Git cycle works and will be explained in further detail in the following sections. Untracked files are those that Git does not recognize. This will occur if a file is newly created or for all files in a new project. The status of a file can be shown with the git status command. For a newly started project there will be files in the untracked status. $ git status# On branch master# Untracked files:#(use "git add <file>..." to include in what will be committed)#filenamenothing added to commit but untracked files present (use "git add" to track) As the status helpfully says, the files will not be included unless Git is told to include them with the git add command. $ git add filename The command git add filename will add that specific file first to the unmodified section. Use git add . to add all files in the current directory (including any sub-directories), or for example git add *.[ch] to add all .c and .h files in the current directory. The unmodified status is where those files that have not changed are kept. Git is aware of them and is tracking them so that when an edit is made they are transferred to the modified status. Also, after a commit, the files are returned to this state. It is also possible to remove files from this state to stop Git from tracking them. This will remove them locally as well. To do so run: $ git rm filenamefilenamefilename Note, that if a file is unmodified, git rm filename will remove the entire file. It is only when a file has uncommitted changes that git rm filename will give a diagnostic and not remove it. To remove a file despite the uncommitted changes, use the --force or -f option. To stop Git from tracking a file without removing it locally, use the --cached option, then commit the removal. $ git rm --cached filename$ git commit -m'remove file message' A copy is on the local system ready to edit. As soon as any changes are made Git recognizes the file as modified and moves it to the modified status. Running git status will show this: $ git status# On branch master# Changed but not updated:#(use "git add <file>..." to update what will be committed)##modified:filename# The file has been changed but as of yet it will not be committed (after all, more changes can still be made and it may not be ready to be committed). As the output helpfully points out, using the git add filename command again will push the modified file to the staged status, ready to be committed. $ git add filename$ git status# On branch master# Changes to be committed:#(use "git reset HEAD <file>..." to unstage)##new file:filename# This process can become a little more complex if a staged file requires one final edit before it is committed as it will appear in both the staged status and the modified status. If this occurs then a status will look like this: $ git status# On branch master# Changes to be committed:#(use "git reset HEAD <file>..." to unstage)##modified:filename1## Changed but not updated:#(use "git add <file>..." to unstage)##modified:filename1# This is where the Git snapshots are highlighted; there is a snapshot of a file ready to be committed and another snapshot in the modified status. If a commit is run then only the snapshot of the staged status will be committed, not the corrected version. Running git add again will resolve this and the modified snapshot of the file will merge with the snapshot on the staged status, ready to commit the new changes. The staged status is where the snapshot of all files that are ready to be committed reside. All files in this status will be committed when the command is given. Before committing the snapshots on the staged status, it is a good idea to check the changes made to ensure that they are acceptable. This is where the command git diff comes in. $ git diffdiff --git a/filename b/filenameindex 3cb747f..da65585 100644--- a/filename+++ b/filename@@ -36,6 +36,10 @@ def [email protected][0].parents[0].parents[0]end+some code+some more code+a comment+another change-a mistake Running the git diff command with no parameters, as above, compares the working directory to what is in the staged status, displaying changes made but not yet committed. It is also possible to compare the changes between the staged status and what the last commit was by using the --cached option. $ git diff --cacheddiff --git a/filename b/filenamenew file mode 100644index 0000000..03902a1-- /dev/null+++ b/filename@@ -0,0 +1,5 @@+file+ by name1, name2+ http://path/to/file++ added information to file In versions 1.6.1 and later of Git it is also possible to use the --staged option instead of --cached. 2.3.7.2. Committing ChangesAfter checking that all the staged files are correct and ready, it is time to commit the changes. $ git commit The above command will launch the chosen editor set in the initial setup, or if this was not set up it defaults to Vim. # Please enter the commit message for your changes. Lines starting# with '#' will be ignored, and an empty message aborts the commit.# On branch master# Changes to be committed:#(use "git reset HEAD <file>..." to unstage)##new file:filename2#modified:filename1~~~".git/COMMIT_EDITMSG" 10L, 283C As can be seen, the last status report is also included in the editor, though because of the hash (#) it will not be visible in the actual commit log. For more information on what is being committed, pass the -v option with git commit. The commit message can be entered here, or it can be entered in the command line with the -m option: $ git commit -m "commit message"[master]: created 4156dc4f: "commit message"2 files changed, 3 insertions(+), 1 deletions (-)create mode 100644 filename The commit message provides some information: the branch committed to (master in this case), what SHA-1 checksum the commit has (4156dc4f), how many files were changed, and statistics about what was changed within them. It is possible to skip the staging area which can be useful, but holds the risk of committing something that was not ready to be committed yet. This is done by passing the -a option with git commit. $ git status# On branch master## Changed but not updated:##modified:filename#$ git commit -a -m 'commit message'[master 16e15c7] commit message1 files changed, 5 insertions(+), 2 deletions(-) 2.3.8. Remote RepositoriesIn order to share a project with the world, push it to a remote repository, hosted on a network or on the internet. To be able to push to a remote directory, first one must be made. To do so, run the command git add [shortname] [URL] $ git remote add shortname git://path/to/new/repo The shortname can now be used in lieu of the URL when referring to the remote repository. Now a repository is added it is possible to print a list of remote repositories. This is done with the git remote command, passing the -v option to display the associated URL as well as just the shortname if desired. Even without adding a new remote repository, if the project was cloned it will list at least the repository it was cloned from. $ git remote -vrepo-name git://path/to/new/remote-repositoryorigin git://path/to/original/remote-repository If even this is not enough information running the git show [remote-repository] will list the URL as well as the branches Git is tracking for this particular repository. In order to fetch data from remote repositories (for example, if someone working on the project has pushed new information to them), use the following command: $ git fetch [remote-name] This pulls down any and all information from this particular remote host that differs from what is on the local copy. Alternatively, running git pull will do the same from the repository the original copy was cloned from. In order to share a project with a wider audience it is required to push it to a remote repository. $ git push remote-repository branch-name This command pushes the specified branch to the specified repository, but only if the user has write access. In the case of a conflict, pull the new work down first to incorporate it into the local version before pushing it to the remote repository. Finally to rename a repository, run the git remote rename original-name new-name. Keep in mind that this will also change the remote branch names as well. Removing a repository is similar: git remote rm remote-name. After working with a repository for some time, making several changes and commits, it may be required to view the logs of these changes. This is done with the git log command. When this is run with no arguments, it lists each commit in reverse chronological order, presenting the time and date of the commit, the SHA-1 checksum, the author's name and email, and the commit message. It is possible to include the diff report in these logs, and limit the output by a set number of entries. For example, running git log -p -2 will list the normal log information in addition to the diff reports for the two most recent entries. To include some statistics at the end of each commit entry, use the git log --stat. This command will include a list of modified files, how many files were changed, and how many lines were added and removed, followed by a summary of this information, after the commit message. Along with these useful options, there are a number of others which can be passed with this command: --shortstatSimilar to the --stat option, but this displays only the changed, insertions, and deletions in a commit. --name-onlyLists only the files modified after the commit information. --name-statusLists the files modified along with the changed, insertions, and deletions. --abbrev-commitOnly displays the first few characters of the SHA-1 checksum, instead of all forty. --relative-dateDisplays the date relative to the current date. For example, instead of reading Tue July 10:53:11 2011 -0700, it will print 2 weeks ago. --graph DisplayPrints an ASCII graph of the branch and merge history beside the log output. --since=[date]Prints the log since a specified date; that is, everything after the date. The date can be entered in a variety of different formats, be it a specific date (2010-08-23, for example) or a relative date ("1 year 3 days 4 minutes ago", for example). --until=[date]Similar to the --since option, this will print the log up until the specified date; that is, everything before the date. --author nameLists only those commits with the specified name in the author field. --committer nameLists only those commits with the specified name in the committer field.
There may come a time when mistakes are made and something has to be removed or undone. This section will cover some of the ways these errors can be fixed. This is one of the few areas in Git where data can be lost forever. If an undo is performed and then discovered it should not have been, it is highly likely that it is now impossible to recover the lost data. Proceed with caution. This occurs most often when a commit is pushed too early, committing something that is not yet ready, or making a mistake in the commit message. This can be fixed by committing over the top of the latest commit using the --amend option. $ git commit --amend If the files on the staged status are different from those in the latest commit, the commit will run normally except it will override the original. If the files are the same, then the option will be provided to change the commit message, again, overriding the previous commit. It is also possible to unstage a staged file. This can sometimes be required if git add * was used when the intention was to have two (or more) separate commits. The git status command provides a hint on how to do this as well: #(use "git reset HEAD <file>..." to unstage) So to follow its advice, use the command git reset HEAD filename and the file is now reverted to the modified status rather than the staged status. To revert a file back to what it looked like at the last commit, the git status command comes to the rescue again in the unstaged status: #(use "git checkout -- <file>..." to discard changes in working directory) Following these instructions with the git checkout -- filename reverts the file. To reiterate the above warning however, this will cause data loss; only use it when it is certain this version of the file is no longer wanted. 2.3.11. Git DocumentationThe main Git man page can be viewed with man git. This also provides the commands to access other man pages such as gittutorial(7), Everyday Git[1], and gitglossary(7). The official Git homepage can be accessed at http://git-scm.com/ where more documentation is available and can be downloaded. The following is a list of websites containing more detailed Git information. |
| |
