The index may contain unmerged entries because of a previous failed merge. By default, if you try to check out such an entry from the index, the checkout operation will fail and nothing will be checked out. Using -f will ignore these unmerged entries. The contents from a specific side of the merge can be checked out of the index by using --ours or --theirs. With -m, changes made to the working tree file can be discarded to re-create the original conflicted merge result.
How do I use it?
The following sequence checks out the master branch, reverts the Makefile to two revisions back, deletes hello.c by mistake, and gets it back from the index.
$ git checkout master
$ git checkout master~2 Makefile
$ rm -f hello.c
$ git checkout hello.c
switch branch
take a file out of another commit
restore hello.c from the index
If you want to check out all C source files out of the index, you can say
$ git checkout — ‘*.c’
Note the quotes around *.c. The file hello.c will also be checked out, even though it is no longer in the working tree, because the file globbing is used to match entries in the index (not in the working tree by the shell).
If you have an unfortunate branch that is named hello.c, this step would be confused as an instruction to switch to that branch. You should instead write:
$ git checkout — hello.c
After working in the wrong branch, switching to the correct branch would be done using:
$ git checkout mytopic
However, your “wrong” branch and correct “mytopic” branch may differ in files that you have modified locally, in which case the above checkout would fail like this:
$ git checkout mytopic
error: You have local changes to ‘frotz’; not switching branches.
You can give the -m flag to the command, which would try a three-way merge:
$ git checkout -m mytopic
Auto-merging frotz
After this three-way merge, the local modifications are not registered in your index file, so git diff would show you what changes you made since the tip of the new branch.
When a merge conflict happens during switching branches with the -m option, you would see something like this:
$ git checkout -m mytopic
Auto-merging frotz
ERROR: Merge conflict in frotz
fatal: merge program failed
At this point, git diff shows the changes cleanly merged as in the previous example, as well as the changes in the conflicted files. Edit and resolve the conflict and mark it resolved with git add as usual:
$ edit frotz
$ git add frotz
To learn about all the options in details, you can run
$ man git checkout
Git Add
What is does ?
Adds file contents to the index
How it does ?
This command updates the index using the current content found in the working tree, to prepare the content staged for the next commit. It typically adds the current content of existing paths as a whole, but with some options it can also be used to add content with only part of the changes made to the working tree files applied, or remove paths that do not exist in the working tree anymore.
The “index” holds a snapshot of the content of the working tree, and it is this snapshot that is taken as the contents of the next commit. Thus after making any changes to the working directory, and before running the commit command, you must use the add command to add any new or modified files to the index.
This command can be performed multiple times before a commit. It only adds the content of the specified file(s) at the time the add command is run; if you want subsequent changes included in the next commit, then you must run git add again to add the new content to the index.
The git status command can be used to obtain a summary of which files have changes that are staged for the next commit.
The git add command will not add ignored files by default. If any ignored files were explicitly specified on the command line, git add will fail with a list of ignored files. Ignored files reached by directory recursion or filename globbing performed by Git (quote your globs before the shell) will be silently ignored. The git add command can be used to add ignored files with the -f (force) option.
Please see git-commit(1) for alternative ways to add content to a commit.
How do I use it?
- Adds content from all *.txt files under Documentation directory and its subdirectories:
$ git add Documentation/\*.txt
Note that the asterisk * is quoted from the shell in this example; this lets the command include the files from subdirectories of Documentation/ directory.
- Considers adding content from all git-*.sh scripts:
Because this example lets the shell expand the asterisk (i.e. you are listing the files explicitly), it does not consider subdir/git-foo.sh.
To learn about all the options in details, you can run
$ man git pull
Git Commit
What is does ?
Records changes to the repository
How it does ?
The content to be added can be specified in several ways:
- by using git add to incrementally “add” changes to the index before using the commit command (Note: even modified files must be “added”);
- by using git rm to remove files from the working tree and the index, again before using the commitcommand;
- by listing files as arguments to the commit command, in which case the commit will ignore changes staged in the index, and instead record the current content of the listed files (which must already be known to Git);
- by using the -a switch with the commit command to automatically “add” changes from all known files (i.e. all files that are already listed in the index) and to automatically “rm” files in the index that have been removed from the working tree, and then perform the actual commit;
- by using the –interactive or –patch switches with the commit command to decide one by one which files or hunks should be part of the commit, before finalizing the operation. See the “Interactive Mode” section of git-add(1) to learn how to operate these modes.
The --dry-run option can be used to obtain a summary of what is included by any of the above for the next commit by giving the same set of parameters (options and paths).
If you make a commit and then find a mistake immediately after that, you can recover from it with git reset.
How do I use it?
When recording your own work, the contents of modified files in your working tree are temporarily stored to a staging area called the “index” with git add. A file can be reverted back, only in the index but not in the working tree, to that of the last commit with git reset HEAD -- <file>, which effectively reverts git add and prevents the changes to this file from participating in the next commit. After building the state to be committed incrementally with these commands, git commit (without any pathname parameter) is used to record what has been staged so far. This is the most basic form of the command. An example:
$ edit hello.c
$ git rm goodbye.c
$ git add hello.c
$ git commit
Instead of staging files after each individual change, you can tell git commit to notice the changes to the files whose contents are tracked in your working tree and do corresponding git add and git rm for you. That is, this example does the same as the earlier example if there is no other change in your working tree:
$ edit hello.c
$ rm goodbye.c
$ git commit -a
The command git commit -a first looks at your working tree, notices that you have modified hello.c and removed goodbye.c, and performs necessary git add and git rm for you.
After staging changes to many files, you can alter the order the changes are recorded in, by giving pathnames to git commit. When pathnames are given, the command makes a commit that only records the changes made to the named paths:
$ edit hello.c hello.h
$ git add hello.c hello.h
$ edit Makefile
$ git commit Makefile
This makes a commit that records the modification to Makefile. The changes staged for hello.c andhello.h are not included in the resulting commit. However, their changes are not lost — they are still staged and merely held back. After the above sequence, if you do:
this second commit would record the changes to hello.c and hello.h as expected.
After a merge (initiated by git merge or git pull) stops because of conflicts, cleanly merged paths are already staged to be committed for you, and paths that conflicted are left in unmerged state. You would have to first check which paths are conflicting with git status and after fixing them manually in your working tree, you would stage the result as usual with git add:
$ git status | grep unmerged
unmerged: hello.c
$ edit hello.c
$ git add hello.c
After resolving conflicts and staging the result, git ls-files -u would stop mentioning the conflicted path. When you are done, run git commit to finally record the merge:
Git push
What is does ?
Updates remote refs along with associated objects
How it does ?
Updates remote refs using local refs, while sending objects necessary to complete the given refs.
You can make interesting things happen to a repository every time you push into it, by setting up hooksthere. See documentation for git-receive-pack(1).
When the command line does not specify where to push with the <repository> argument,branch.*.remote configuration for the current branch is consulted to determine where to push. If the configuration is missing, it defaults to origin.
When the command line does not specify what to push with <refspec>... arguments or --all, --mirror, --tags options, the command finds the default <refspec> by consulting remote.*.pushconfiguration, and if it is not found, honors push.default configuration to decide what to push (See git1for the meaning of push.default).
How do I use it?
git push
Works like git push <remote>, where <remote> is the current branch’s remote (or origin, if no remote is configured for the current branch).
git push origin
Without additional configuration, works like git push origin :.
The default behavior of this command when no <refspec> is given can be configured by setting thepush option of the remote, or the push.default configuration variable.
For example, to default to pushing only the current branch to origin use git config remote.origin.push HEAD. Any valid <refspec> (like the ones in the examples below) can be configured as the default for git push origin.
git push origin :
Push “matching” branches to origin. See <refspec> in the OPTIONS section above for a description of “matching” branches.
git push origin master
Find a ref that matches master in the source repository (most likely, it would findrefs/heads/master), and update the same ref (e.g. refs/heads/master) in origin repository with it. If master did not exist remotely, it would be created.
git push origin HEAD
A handy way to push the current branch to the same name on the remote.
git push mothership master:satellite/master dev:satellite/dev
Use the source ref that matches master (e.g. refs/heads/master) to update the ref that matchessatellite/master (most probably refs/remotes/satellite/master) in the mothershiprepository; do the same for dev and satellite/dev.
This is to emulate git fetch run on the mothership using git push that is run in the opposite direction in order to integrate the work done on satellite, and is often necessary when you can only make connection in one way (i.e. satellite can ssh into mothership but mothership cannot initiate connection to satellite because the latter is behind a firewall or does not run sshd).
After running this git push on the satellite machine, you would ssh into the mothership and rungit merge there to complete the emulation of git pull that were run on mothership to pull changes made on satellite.
git push origin HEAD:master
Push the current branch to the remote ref matching master in the origin repository. This form is convenient to push the current branch without thinking about its local name.
git push origin master:refs/heads/experimental
Create the branch experimental in the origin repository by copying the current master branch. This form is only needed to create a new branch or tag in the remote repository when the local name and the remote name are different; otherwise, the ref name on its own will work.
git push origin :experimental
Find a ref that matches experimental in the origin repository (e.g. refs/heads/experimental), and delete it.
Abhishek Srivastava
Ishant
Rahul K Upadhyaya
Romil Gupta
Mayank Kumar
Yatin Kumbhare
iLearnStack 