# data[].attributes.body
Remove staged without removing the actual files
git rm --cached -r .

https://stackoverflow.com/questions/19730565/how-to-remove-files-from-git-staging-area#:~:text=to%20unstage%20all%20the%20staged%20files.&text=git%20rm%20%2D%2Dcached%20%2Dr,you%20want%20to%20keep%20tracking.

# data[].attributes.body
Git stores four kinds of objects in the repo: blobs (files)

trees (directories)
commits (which form a directed acyclic graph through parent identifiers, with each commit carrying one tree object, one author, one committer, its set-of-parents, and an arbitrary log message)

annotated-tag objects (which have no strongly defined relationship, but every tag has exactly one target object, normally a commit).

# data[].attributes.attachment_link.readable_text
As others have said, there's nothing built in to do this. We might, however, note that Git stores four kinds of objects in the repository itself: blobs (files), trees (representing directories-full-of-files), commits (which form a directed acyclic graph through parent identifiers, with each commit carrying one tree object, one author, one committer, its set-of-parents, and an arbitrary log message), and annotated-tag objects (which have no strongly defined relationship, but every tag has exactly one target object, normally a commit).

Aside: how git notes work

Git's notes are represented internally as commits. Each commit has, as its tree, a set of "files" whose names merely happen to be-entirely by accident :-) ... cough, ahem-exactly the same ¹ as some set of commits in the repository. When git log goes to display a commit whose ID is C, it "accidentally" checks to see if refs/notes/commits exists, and if so, whether a file named C exists in the commit to which refs/notes/commits points, and if so, it appends the contents of that file to the log message. So this is how notes attach to commits: one built-in part of Git checks to see if a special reference ( refs/notes/commits) points to a commit containing a tree containing a "file" (and it really is a file in the end, as it's an ordinary Git blob object) that should be tacked on to the commit log message.

When you revise the set of notes, Git simply makes a new commit with a new tree. The new commit points back to the previous refs/notes/commits commit as its parent, so that the older notes remain in existence and can (with some difficulty) be viewed as they were in the past (this used to be very hard; I believe it has become easier). Git's natural pack-file compression handles these quite well, so that the space occupied by notes grows only linearly with new note additions.

¹For efficiency, the "name" gets modified somewhat, so that instead of the note file being named deadbeefcafebabec0ffeedecadefadedbedcede, for instance, it might be named de/ad/beefcafe....

Thus, the solution is obvious (ahem)

You want to represent a set of files arranged in a directory or series of directories. That is, of course, a tree, and Git has tree objects. Therefore you should create a tree object to hold one of these states.

You did not say whether you wish to keep multiple historical versions of this tree. If you do, the solution is obvious: handle them just as git notes does, using a new commit object to store each new tree, chaining the commits to make past versions retrievable. If not, it's up to you whether to create a commit object at all, as a single tag object could point directly to the tree object. (Some non-Git tools may have issues with tags to anything other than a commit or another tag. There are a few of these tags in the Git repository for Git itself, though.)

In any case, you will also need one top-level reference to point to your commit-or-annotated-tag-object that points to the most current tree.

Creating the tree is easy: simply populate an index file-not the regular one, but an alternate, whose name you write into the environment variable GIT_INDEX_FILE-with the file names as you wish them to appear in your tree, by git add-ing the files (this will also put the necessary blobs into the repository if they are not there already), then invoke git write-tree. This will turn the index into the desired tree object (after which you may, and probably should, discard the exported GIT_INDEX_FILE setting), printing the new object's ID to standard output as usual. Writing a commit and/or tag object to point to this tree is then merely a matter of invoking git commit-tree and/or git mktag (which will write their own new objects to the repository, printing the IDs to standard output as before). Last, use git update-ref to create or update a reference to point to the tag or commit object-and you have now re-implemented git notes, but in a form more suitable for your own desires.

You can extract any saved tree any time, to any work-tree of your choice, with a simple git checkout using another temporary index.

# data[].attributes.attachment_link.title
Labeling / Marking a group of files in Git

# data[].attributes.attachment_link.description
As others have said, there's nothing built in to do this. We might, however, note that Git stores four kinds of objects in the repository itself: blobs (files), trees (representing directories-full-of-files), commits (which form a directed acyclic graph through parent identifiers, with each commit carrying one tree object, one author, one committer, its set-of-parents, and an arbitrary log message), and annotated-tag objects (which have no strongly defined relationship, but every tag has exactly one target object, normally a commit).

# data[].attributes.headline
Remove untracked files added to .ignore (.gitignore is is ignoring the untracked files)

# data[].attributes.subject
Remove untracked files added to .ignore (.gitignore is is ignoring the untracked files)

# data[].attributes.body
git rm -r --cached .
git add .
git commit -m "F untracked files"

# data[].attributes.attachment_link.description
Rebase is one of two Git utilities that specializes in integrating changes from one branch onto another.

# data[].attributes.body
"git merge" used to allow merging two branches that have no common base by default, which led to a brand new history of an existing project created and then get pulled by an unsuspecting maintainer, which allowed an unnecessary parallel history merged into the existing project. The command has been taught not to allow this by default, with an escape hatch --allow-unrelated-histories option to be used in a rare event that merges histories of two projects that started their lives independently.

# data[].attributes.attachment_link.title
Git refusing to merge unrelated histories

# data[].attributes.attachment_link.description
During git rebase origin/development following error message is shown from git: fatal: refusing to merge unrelated histories Error redoing merge 1234deadbeef1234deadbeef My git version is 2.9.0. ...

# data[].attributes.body
git branch -a // list my branches

case1: the name of my new branch do not exist :

git checkout -b [my new branch name] // creates new brach

case 2: the name of my new branch is already exist but i dont have that branch on my local :

git checkout -b [already existing branch] origin/[already existing branch]  /

git status  // check changes
git add .    // if some and we want to stage them all (or we can do it individually etc.)
git commit -m "doc: Check the commit message to prevent error propagation"
git push -u [my new branch name] OR git push (if I'm already on the branch)
git merge --no-ff origin/[my new branch name/existing branch] // merges your branch

# data[].attributes.attachment_link.description
GitHub Flow is a lightweight, branch-based workflow that supports teams and projects where deployments are made regularly. This guide explains how and why GitHub Flow works.

# data[].attributes.body
subject (mandatory) =  type + title

Subjects should be no greater than 50 characters, should begin with a capital letter and do not end with a period. Use an imperative tone to describe what a commit does.

type (values):

feat: a new feature

fix: a bug fix

docs: changes to documentation

style: formatting, missing semi colons, etc; no code change

refactor: refactoring production code

test: adding tests, refactoring test; no production code change

chore: updating build tasks, package manager configs, etc; no production code change

\n (mandatory)

body(optional):  Use the body to explain the what and why of a commit, not the how. 72 chars max.
\n (mandatory)
footer(optional): The footer is optional and is used to reference issue tracker IDs.

# data[].attributes.attachment_link.description
This style guide acts as the official guide to follow in your projects. Udacity evaluators will use this guide to grade your projects. There are many opinions on the "ideal" style in the world of development.

# data[].attributes.headline
Git Clone and Working with remotes (Push/Pull)

# data[].attributes.subject
Git Clone and Working with remotes (Push/Pull)

# data[].attributes.body
$ git clone file:///home/thunk/repo dental
A remote is like a browser bookmark with a name and a URL. If you are in a repository, you can list the names of its remotes using git remote.

How can I define remotes?

When you clone a repository, Git automatically creates a remote called origin that points to the original repository. You can add more remotes using:

***************  Add remote  ********************

git remote add remote-name URL

git remote add remote-name URL

and remove existing ones using:

git remote rm remote-name

$ git remote add thunk file:///home/thunk/repo

You are in the master branch of the repository dental, which has a remote called origin. Pull all of the changes in the master branch of that remote repository into the master branch of your repository.

$ git pull origin master
$ git push origin master

****************  Change remote  ******************

git remote -v
git remote set-url origin https://github.com/USERNAME/REPOSITORY.git
git push -u origin master

# data[].attributes.body
$ git merge summary-statistics master
Git without edit and message
$ git merge --no-edit -m "Merging altered report title" alter-report-title master

# data[].attributes.body
$ git rm report.txt

# data[].attributes.body
Git list branches
$ git branch
Git differences btw branches
$ git diff summary-statistics..master
Change branch name
$ git checkout branch-name
Create branch
git checkout -b deleting-report

# data[].attributes.body
Git command to remove all files from the staging area
$ git reset HEAD .
Re-set those files to their previous state
$ git checkout -- .

# data[].attributes.body
$ git checkout 2242bd report.md

# data[].attributes.body
$ git checkout -- filename
Discard the changes in your repository.
will undo changes that have not yet been staged.
If you want to undo changes that have been staged, you can use

$ git reset HEAD filename
This does not restore the file to the state it was in before you started making changes. Instead, it resets the file to the state you last staged.
If you want to go all the way back to where you were before you started making changes, you must

$ git checkout -- filename

(You may be wondering why there are two commands for re-setting changes. The answer is that unstaging a file and undoing changes are both special cases of more powerful Git operations that you have not yet seen.)

# data[].attributes.attachment_link.readable_text
In general, git reset's function is to take the current branch and reset it to point somewhere else, and possibly bring the index and work tree along. More concretely, if your master branch (currently checked out) is like this:

- A - B - C (HEAD, master)

and you realize you want master to point to B, not C, you will use git reset B to move it there:

- A - B (HEAD, master) # - C is still here, but there's no branch pointing to it anymore

Digression: This is different from a checkout. If you'd run git checkout B, you'd get this:

- A - B (HEAD) - C (master)

You've ended up in a detached HEAD state. HEAD, work tree, index all match B, but the master branch was left behind at C. If you make a new commit D at this point, you'll get this, which is probably not what you want:

- A - B - C (master) \ D (HEAD)

Remember, reset doesn't make commits, it just updates a branch (which is a pointer to a commit) to point to a different commit. The rest is just details of what happens to your index and work tree.

I cover many of the main use cases for git reset within my descriptions of the various options in the next section. It can really be used for a wide variety of things; the common thread is that all of them involve resetting the branch, index, and/or work tree to point to/match a given commit.

--hard can cause you to really lose work. It modifies your work tree.

git reset [options] commit can cause you to (sort of) lose commits. In the toy example above, we lost commit C. It's still in the repo, and you can find it by looking at git reflog show HEAD or git reflog show master, but it's not actually accessible from any branch anymore.

Git permanently deletes such commits after 30 days, but until then you can recover C by pointing a branch at it again ( git checkout C; git branch <new branch name>).

Paraphrasing the man page, most common usage is of the form git reset [<commit>] [paths...], which will reset the given paths to their state from the given commit. If the paths aren't provided, the entire tree is reset, and if the commit isn't provided, it's taken to be HEAD (the current commit). This is a common pattern across git commands (e.g. checkout, diff, log, though the exact semantics vary), so it shouldn't be too surprising.

For example, git reset other-branch path/to/foo resets everything in path/to/foo to its state in other-branch, git reset -- . resets the current directory to its state in HEAD, and a simple git reset resets everything to its state in HEAD.

There are four main options to control what happens to your work tree and index during the reset.

Remember, the index is git's "staging area" - it's where things go when you say git add in preparation to commit.

--hard makes everything match the commit you've reset to. This is the easiest to understand, probably. All of your local changes get clobbered. One primary use is blowing away your work but not switching commits: git reset --hard means git reset --hard HEAD, i.e. don't change the branch but get rid of all local changes. The other is simply moving a branch from one place to another, and keeping index/work tree in sync. This is the one that can really make you lose work, because it modifies your work tree. Be very very sure you want to throw away local work before you run any reset --hard.

--mixed is the default, i.e. git reset means git reset --mixed. It resets the index, but not the work tree. This means all your files are intact, but any differences between the original commit and the one you reset to will show up as local modifications (or untracked files) with git status. Use this when you realize you made some bad commits, but you want to keep all the work you've done so you can fix it up and recommit. In order to commit, you'll have to add files to the index again ( git add ...).

--soft doesn't touch the index or work tree. All your files are intact as with --mixed, but all the changes show up as changes to be committed with git status (i.e. checked in in preparation for committing). Use this when you realize you've made some bad commits, but the work's all good - all you need to do is recommit it differently. The index is untouched, so you can commit immediately if you want - the resulting commit will have all the same content as where you were before you reset.

--merge was added recently, and is intended to help you abort a failed merge. This is necessary because git merge will actually let you attempt a merge with a dirty work tree (one with local modifications) as long as those modifications are in files unaffected by the merge. git reset --merge resets the index (like --mixed - all changes show up as local modifications), and resets the files affected by the merge, but leaves the others alone. This will hopefully restore everything to how it was before the bad merge. You'll usually use it as git reset --merge (meaning git reset --merge HEAD) because you only want to reset away the merge, not actually move the branch. ( HEAD hasn't been updated yet, since the merge failed)

To be more concrete, suppose you've modified files A and B, and you attempt to merge in a branch which modified files C and D. The merge fails for some reason, and you decide to abort it. You use git reset --merge. It brings C and D back to how they were in HEAD, but leaves your modifications to A and B alone, since they weren't part of the attempted merge.

I do think man git reset is really quite good for this - perhaps you do need a bit of a sense of the way git works for them to really sink in though. In particular, if you take the time to carefully read them, those tables detailing states of files in index and work tree for all the various options and cases are very very helpful. (But yes, they're very dense - they're conveying an awful lot of the above information in a very concise form.)

The "strange notation" ( HEAD^ and HEAD~1) you mention is simply a shorthand for specifying commits, without having to use a hash name like 3ebe3f6. It's fully documented in the "specifying revisions" section of the man page for git-rev-parse, with lots of examples and related syntax. The caret and the tilde actually mean different things:

HEAD~ is short for HEAD~1 and means the commit's first parent. HEAD~2 means the commit's first parent's first parent. Think of HEAD~n as "n commits before HEAD" or "the nth generation ancestor of HEAD".

HEAD^ (or HEAD^1) also means the commit's first parent. HEAD^2 means the commit's second parent. Remember, a normal merge commit has two parents - the first parent is the merged-into commit, and the second parent is the commit that was merged. In general, merges can actually have arbitrarily many parents (octopus merges).

The ^ and ~ operators can be strung together, as in HEAD~3^2, the second parent of the third-generation ancestor of HEAD, HEAD^^2, the second parent of the first parent of HEAD, or even HEAD^^^, which is equivalent to HEAD~3.

# data[].attributes.attachment_link.title
Can you explain what "git reset" does in plain english?

# data[].attributes.attachment_link.description
In general, git reset's function is to take the current branch and reset it to point somewhere else, and possibly bring the index and work tree along.

# data[].attributes.body
$ git checkout -- filename
(two scores - - )

# data[].attributes.body
$ git config --list (AND one of these flags)

--system: settings for every user on this computer.

--global: settings for every one of your projects.

--local: settings for one specific project.

git config --global setting.name myemail@email.com

# data[].attributes.body
$ git clean -n
will show you a list of files that are in the repository, but whose history Git is not currently tracking
$ git clean -f
will then delete those files.

# data[].attributes.body
$ git diff 920252..4504188

# data[].attributes.body
$ git annotate file

# data[].attributes.body
In order to compare the file as it currently is to the changes in the staging area, you can use git diff -r HEAD filename. The -r flag means "compare to a particular revision", and HEAD is a shortcut meaning "the most recent commit". We will explore other uses of -r and HEAD in the next chapter.

# data[].attributes.body
$ git show
$ git show 2343 (first hash chars)
The first part is the same as the log entry shown by git log. The second part shows the changes; as with git diff, lines that the change removed are prefixed with -, while lines that it added are prefixed with +.

# data[].attributes.body
last commit:
$ git log -1  --> equivalent to git show HEAD
$ git log
----
$ git show HEAD~1 (previous to last commit)
$ git show HEAD~2
(HEAD-2 commits ago)