Why Does Git Commit Only Say Add Files via Upload
Recording Changes to the Repository
You take a bona fide Git repository and a checkout or working re-create of the files for that project. You lot need to make some changes and commit snapshots of those changes into your repository each fourth dimension the project reaches a state you want to record.
Retrieve that each file in your working directory tin be in ane of two states: tracked or untracked. Tracked files are files that were in the concluding snapshot; they can be unmodified, modified, or staged. Untracked files are everything else – any files in your working directory that were not in your last snapshot and are not in your staging area. When you get-go clone a repository, all of your files will be tracked and unmodified because you just checked them out and haven't edited annihilation.
As you lot edit files, Git sees them as modified, because you've inverse them since your terminal commit. Yous stage these modified files and and so commit all your staged changes, and the cycle repeats.
Figura 8. The lifecycle of the status of your files.
Checking the Status of Your Files
The main tool y'all apply to determine which files are in which state is the git status control. If you run this command directly after a clone, you should see something like this:
$ git status On branch master nothing to commit, working directory clean This ways you lot take a clean working directory – in other words, at that place are no tracked and modified files. Git as well doesn't see any untracked files, or they would be listed here. Finally, the command tells you which co-operative you're on and informs you that it has not diverged from the same branch on the server. For now, that branch is always "primary", which is the default; you lot won't worry about it here. [ch03-git-branching] volition become over branches and references in particular.
Permit's say y'all add a new file to your project, a simple README file. If the file didn't be earlier, and you run git condition, you lot see your untracked file similar then:
$ echo 'My Projection' > README $ git condition On branch master Untracked files: (use "git add together <file>..." to include in what will exist committed) README null added to commit but untracked files present (use "git add together" to track) You lot tin can see that your new README file is untracked, because it's nether the "Untracked files" heading in your condition output. Untracked basically means that Git sees a file y'all didn't have in the previous snapshot (commit); Git won't start including it in your commit snapshots until y'all explicitly tell it to practice and so. It does this and then you don't accidentally begin including generated binary files or other files that yous did not mean to include. Y'all exercise want to start including README, so let'southward start tracking the file.
Tracking New Files
In order to begin tracking a new file, you utilise the command git add together. To begin tracking the README file, yous can run this:
If y'all run your condition command again, you can see that your README file is now tracked and staged to be committed:
$ git condition On co-operative master Changes to exist committed: (apply "git reset Caput <file>..." to unstage) new file: README You lot can tell that information technology'southward staged because information technology's under the "Changes to be committed" heading. If you commit at this point, the version of the file at the time you ran git add together is what volition be in the historical snapshot. You may recollect that when yous ran git init before, you lot then ran git add (files) – that was to brainstorm tracking files in your directory. The git add together command takes a path proper name for either a file or a directory; if it's a directory, the command adds all the files in that directory recursively.
Staging Modified Files
Let's alter a file that was already tracked. If y'all alter a previously tracked file called "CONTRIBUTING.md" and so run your git status command once more, you get something that looks like this:
$ git status On co-operative master Changes to be committed: (employ "git reset HEAD <file>..." to unstage) new file: README Changes not staged for commit: (use "git add <file>..." to update what will be committed) (utilise "git checkout -- <file>..." to discard changes in working directory) modified: CONTRIBUTING.md The "CONTRIBUTING.doc" file appears under a section named "Changed but not staged for commit" – which means that a file that is tracked has been modified in the working directory simply non yet staged. To stage it, you run the git add together command. git add is a multipurpose command – y'all utilize it to begin tracking new files, to stage files, and to practice other things like marking merge-conflicted files as resolved. It may be helpful to think of it more as "add this content to the next commit" rather than "add this file to the project". Let'due south run git add now to phase the "CONTRIBUTING.md" file, and so run git condition again:
$ git add CONTRIBUTING.md $ git status On co-operative master Changes to exist committed: (use "git reset HEAD <file>..." to unstage) new file: README modified: CONTRIBUTING.md Both files are staged and will go into your next commit. At this point, suppose you remember one niggling change that you desire to make in CONTRIBUTING.medico before you commit it. You open information technology again and make that change, and you're ready to commit. However, let'due south run git condition one more time:
$ vim CONTRIBUTING.md $ git condition On branch master Changes to be committed: (use "git reset Head <file>..." to unstage) new file: README modified: CONTRIBUTING.md Changes not staged for commit: (use "git add <file>..." to update what volition exist committed) (utilize "git checkout -- <file>..." to discard changes in working directory) modified: CONTRIBUTING.medico What the heck? Now CONTRIBUTING.physician is listed as both staged and unstaged. How is that possible? It turns out that Git stages a file exactly equally it is when y'all run the git add command. If you lot commit at present, the version of CONTRIBUTING.physician as information technology was when y'all last ran the git add command is how information technology will go into the commit, not the version of the file as it looks in your working directory when you run git commit. If you lot modify a file after you run git add together, you take to run git add again to stage the latest version of the file:
$ git add CONTRIBUTING.md $ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: README modified: CONTRIBUTING.physician Short Status
While the git condition output is pretty comprehensive, it's also quite wordy. Git as well has a brusque status flag so you can see your changes in a more compact fashion. If yous run git condition -s or git status --short you lot become a far more simplified output from the command.
$ git status -s M README MM Rakefile A lib/git.rb Chiliad lib/simplegit.rb ?? LICENSE.txt New files that aren't tracked take a ?? adjacent to them, new files that have been added to the staging area take an A, modified files have an Yard and and so on. In that location are two columns to the output - the left hand column indicates that the file is staged and the right hand column indicates that it's modified. So for instance in that output, the README file is modified in the working directory but not yet staged, while the lib/simplegit.rb file is modified and staged. The Rakefile was modified, staged and then modified again, so there are changes to information technology that are both staged and unstaged.
Ignoring Files
Frequently, yous'll have a course of files that you don't want Git to automatically add or even show y'all as being untracked. These are by and large automatically generated files such as log files or files produced by your build system. In such cases, y'all tin create a file listing patterns to match them named .gitignore. Here is an example .gitignore file:
$ true cat .gitignore *.[oa] *~ The offset line tells Git to ignore any files ending in ".o" or ".a" – object and archive files that may be the product of building your code. The second line tells Git to ignore all files that end with a tilde (~), which is used by many text editors such as Emacs to mark temporary files. Y'all may also include a log, tmp, or pid directory; automatically generated documentation; and and so on. Setting upwardly a .gitignore file before you go going is mostly a skillful idea so you don't accidentally commit files that yous really don't want in your Git repository.
The rules for the patterns you tin can put in the .gitignore file are as follows:
-
Blank lines or lines starting with
#are ignored. -
Standard glob patterns piece of work.
-
You can end patterns with a forrard slash (
/) to specify a directory. -
Yous can negate a blueprint by starting it with an exclamation point (
!).
Glob patterns are like simplified regular expressions that shells employ. An asterisk (*) matches zero or more characters; [abc] matches any character inside the brackets (in this instance a, b, or c); a question mark (?) matches a single character; and brackets enclosing characters separated by a hyphen([0-9]) matches any character between them (in this case 0 through 9). Y'all can also use two asterisks to match nested directories; a/**/z would lucifer a/z, a/b/z, a/b/c/z, and and then on.
Here is another example .gitignore file:
# no .a files *.a # but do track lib.a, even though y'all're ignoring .a files above !lib.a # only ignore the root TODO file, not subdir/TODO /TODO # ignore all files in the build/ directory build/ # ignore md/notes.txt, but not physician/server/arch.txt doc/*.txt # ignore all .txt files in the doc/ directory md/**/*.txt | Suggerimento | GitHub maintains a fairly comprehensive list of good |
Viewing Your Staged and Unstaged Changes
If the git status command is too vague for you lot – y'all desire to know exactly what you inverse, non just which files were changed – you can use the git diff control. We'll cover git diff in more detail subsequently, but you'll probably utilise it about often to respond these 2 questions: What have you changed merely not withal staged? And what have you lot staged that you are about to commit? Although git status answers those questions very generally by listing the file names, git unequal shows you the verbal lines added and removed – the patch, as it were.
Let's say you edit and stage the README file again and and then edit the CONTRIBUTING.md file without staging it. If you run your git condition control, y'all once again run across something like this:
$ git condition On branch master Changes to exist committed: (utilize "git reset Caput <file>..." to unstage) new file: README Changes not staged for commit: (use "git add <file>..." to update what will be committed) (utilise "git checkout -- <file>..." to discard changes in working directory) modified: CONTRIBUTING.md To meet what you've changed merely not notwithstanding staged, type git diff with no other arguments:
$ git diff unequal --git a/CONTRIBUTING.md b/CONTRIBUTING.md alphabetize 8ebb991..643e24f 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.physician @@ -65,7 +65,8 @@ branch straight, things can get messy. Please include a dainty description of your changes when you submit your PR; if we accept to read the whole diff to figure out why y'all're contributing in the commencement identify, yous're less likely to become feedback and have your alter -merged in. +merged in. Also, dissever your changes into comprehensive chunks if you patch is +longer than a dozen lines. If y'all are starting to work on a particular area, feel free to submit a PR that highlights your work in progress (and note in the PR championship that it's That command compares what is in your working directory with what is in your staging area. The issue tells you lot the changes you've made that you haven't all the same staged.
If you want to run across what yous've staged that will go into your next commit, you tin can use git unequal --staged. This command compares your staged changes to your last commit:
$ git diff --staged diff --git a/README b/README new file manner 100644 index 0000000..03902a1 --- /dev/zilch +++ b/README @@ -0,0 +i @@ +My Project It's of import to note that git diff by itself doesn't bear witness all changes made since your last commit – just changes that are still unstaged. This can be confusing, because if you've staged all of your changes, git diff will requite you no output.
For another example, if you stage the CONTRIBUTING.md file and so edit it, y'all tin can use git diff to see the changes in the file that are staged and the changes that are unstaged. If our environs looks similar this:
$ git add CONTRIBUTING.dr. $ echo 'test line' >> CONTRIBUTING.dr. $ git status On branch chief Changes to be committed: (use "git reset HEAD <file>..." to unstage) modified: CONTRIBUTING.medico Changes not staged for commit: (apply "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: CONTRIBUTING.md Now you can apply git unequal to see what is still unstaged
$ git diff diff --git a/CONTRIBUTING.medico b/CONTRIBUTING.md index 643e24f..87f08c8 100644 --- a/CONTRIBUTING.doc +++ b/CONTRIBUTING.doctor @@ -119,3 +119,4 @@ at the ## Starter Projects Meet our [projects list](https://github.com/libgit2/libgit2/blob/evolution/PROJECTS.physician). +# test line and git diff --cached to encounter what y'all've staged so far (--staged and --cached are synonyms):
$ git diff --cached diff --git a/CONTRIBUTING.md b/CONTRIBUTING.dr. alphabetize 8ebb991..643e24f 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -65,7 +65,eight @@ co-operative straight, things tin go messy. Please include a nice description of your changes when you submit your PR; if we have to read the whole diff to figure out why you're contributing in the kickoff place, you're less likely to become feedback and have your alter -merged in. +merged in. Too, split your changes into comprehensive chunks if you patch is +longer than a dozen lines. If you are starting to work on a detail area, feel costless to submit a PR that highlights your work in progress (and note in the PR title that it's Committing Your Changes
Now that your staging area is ready the way yous desire it, you lot can commit your changes. Think that anything that is still unstaged – any files you have created or modified that you haven't run git add on since you edited them – won't go into this commit. They will stay as modified files on your disk. In this instance, let's say that the concluding time you ran git status, you saw that everything was staged, so y'all're ready to commit your changes. The simplest way to commit is to type git commit:
Doing and so launches your editor of choice. (This is ready past your shell'southward $EDITOR surround variable – usually vim or emacs, although you tin can configure it with whatever you want using the git config --global core.editor command as y'all saw in Per Iniziare).
The editor displays the following text (this example is a Vim screen):
# 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: # new file: README # modified: CONTRIBUTING.md # ~ ~ ~ ".git/COMMIT_EDITMSG" 9L, 283C Y'all can see that the default commit message contains the latest output of the git status control commented out and 1 empty line on top. You can remove these comments and type your commit message, or you can leave them there to assistance you remember what y'all're committing. (For an even more explicit reminder of what you've modified, you can laissez passer the -5 option to git commit. Doing so also puts the diff of your change in the editor so you lot can see exactly what changes you're committing.) When you lot exit the editor, Git creates your commit with that commit bulletin (with the comments and diff stripped out).
Alternatively, y'all can type your commit message inline with the commit command by specifying it afterward a -m flag, like this:
$ git commit -yard "Story 182: Fix benchmarks for speed" [master 463dc4f] Story 182: Fix benchmarks for speed two files changed, 2 insertions(+) create mode 100644 README Now you've created your first commit! You can encounter that the commit has given you some output almost itself: which co-operative you committed to (master), what SHA-i checksum the commit has (463dc4f), how many files were changed, and statistics about lines added and removed in the commit.
Recall that the commit records the snapshot you prepare in your staging area. Anything you didn't phase is even so sitting there modified; you can do some other commit to add it to your history. Every time you perform a commit, you're recording a snapshot of your projection that y'all can revert to or compare to later on.
Skipping the Staging Area
Although information technology can be amazingly useful for crafting commits exactly how you lot want them, the staging area is sometimes a fleck more than circuitous than yous need in your workflow. If you want to skip the staging surface area, Git provides a unproblematic shortcut. Adding the -a selection to the git commit command makes Git automatically phase every file that is already tracked earlier doing the commit, letting you skip the git add part:
$ git status On branch master Changes not staged for commit: (use "git add <file>..." to update what volition be committed) (apply "git checkout -- <file>..." to discard changes in working directory) modified: CONTRIBUTING.md no changes added to commit (apply "git add" and/or "git commit -a") $ git commit -a -g 'added new benchmarks' [master 83e38c7] added new benchmarks i file changed, 5 insertions(+), 0 deletions(-) Notice how y'all don't have to run git add together on the "CONTRIBUTING.medico" file in this example before you commit.
Removing Files
To remove a file from Git, you have to remove it from your tracked files (more accurately, remove it from your staging surface area) and then commit. The git rm control does that, and also removes the file from your working directory and so you don't see information technology as an untracked file the adjacent time around.
If yous simply remove the file from your working directory, it shows up nether the "Changed but non updated" (that is, unstaged) area of your git status output:
$ rm PROJECTS.md $ git status On co-operative primary Your branch is up-to-date with 'origin/primary'. Changes not staged for commit: (utilise "git add together/rm <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) deleted: PROJECTS.doc no changes added to commit (utilise "git add" and/or "git commit -a") Then, if you lot run git rm, it stages the file'due south removal:
$ git rm PROJECTS.md rm 'PROJECTS.md' $ git status On branch master Changes to exist committed: (use "git reset Caput <file>..." to unstage) deleted: PROJECTS.md The next time you commit, the file will be gone and no longer tracked. If y'all modified the file and added it to the alphabetize already, yous must force the removal with the -f option. This is a safe characteristic to prevent accidental removal of data that hasn't yet been recorded in a snapshot and that can't exist recovered from Git.
Another useful thing you may want to do is to keep the file in your working tree simply remove it from your staging area. In other words, you may want to keep the file on your difficult drive but non have Git track it anymore. This is particularly useful if y'all forgot to add together something to your .gitignore file and accidentally staged it, similar a large log file or a agglomeration of .a compiled files. To do this, use the --buried option:
You can pass files, directories, and file-glob patterns to the git rm command. That means you tin can practice things such as
Annotation the backslash (\) in front end of the *. This is necessary because Git does its own filename expansion in addition to your vanquish's filename expansion. This command removes all files that accept the .log extension in the log/ directory. Or, you can do something like this:
This control removes all files that terminate with ~.
Moving Files
Unlike many other VCS systems, Git doesn't explicitly track file move. If you rename a file in Git, no metadata is stored in Git that tells it you renamed the file. Notwithstanding, Git is pretty smart about figuring that out afterwards the fact – we'll deal with detecting file move a bit afterward.
Thus it's a bit confusing that Git has a mv command. If you want to rename a file in Git, you tin can run something like
$ git mv file_from file_to and it works fine. In fact, if you run something similar this and look at the status, y'all'll see that Git considers it a renamed file:
$ git mv README.dr. README $ git status On branch principal Changes to be committed: (utilize "git reset HEAD <file>..." to unstage) renamed: README.md -> README All the same, this is equivalent to running something like this:
$ mv README.md README $ git rm README.medico $ git add README Git figures out that it'southward a rename implicitly, then it doesn't matter if yous rename a file that fashion or with the mv command. The only real divergence is that mv is one command instead of three – it'due south a convenience function. More than important, yous can use any tool yous like to rename a file, and address the add/rm later, earlier you commit.
Source: https://git-scm.com/book/it/v2/Git-Basics-Recording-Changes-to-the-Repository
0 Response to "Why Does Git Commit Only Say Add Files via Upload"
ارسال یک نظر