Once you’ve cloned or initialized a new Git project, just start changing files as needed for your current assignment. There is no pessimistic locking of files by teammates. In fact, there’s no locking at all. Git operates in a very optimistic manner, confident that its merge capabilities are a match for any conflicted changes that you and your colleagues can craft.
If you need to move a file, Git can often detect your manual relocation of the file and will show it as a pending “move.” However, it is often more prudent to just directly tell Git to relocate a file and track its new destination.
git mv originalfile.txt newsubdir/newfilename.txt
If you wish to expunge a file from the current state of the branch, simply tell Git to remove it. It will be put in a pending deletion state and can be confirmed and completed by the next commit.
git rm fileyouwishtodelete.txt
Daily work calls for strong support of viewing current and historical facts about your repository, often from different, perhaps even orthogonal points of view. Git satisfies those demands in spades.
To check the current status of a project’s local directories and files (modified, new, deleted, or untracked) invoke the status command:
A patch-style view of the difference between the currently edited and committed files, or any two points in the past can easily be summoned. The .. operator signifies a range is being provided. An omitted second element in the range implies a destination of the current committed state, also known as HEAD:
git diff 32d4..
git diff --summary 32d4..
Git allows for diffing between the local files, the stage files, and the committed files with a great deal of precision.
||everything unstaged diffed to the last commit
|git diff --cached
||everything staged diffed to the last commit
|git diff HEAD
||everything unstaged and staged diffed to the last commit
The full list of changes since the beginning of time, or optionally, since a certain date is right at your fingertips, even when disconnected from all networks:
git log --since=yesterday
git log --since=2weeks
If trying to discover why and when a certain line was added, cut to the chase and have Git annotate each line of a source file with the name and date it came into existence:
git blame <filename>
Git offers a useful feature for those times when your changes are in an incomplete state, you aren’t ready to commit them, and you need to temporarily return to the last committed (e.g.a fresh checkout). This feature is named “stash” and pushes all your uncommitted changes onto a stack.
When you are ready to write the stashed changes back into the working copies of the files, simply pop them back of the stack.
git stash pop
If you want to abort your current uncommitted changes and restore the working copy to the last committed state, there are two commands that will help you accomplish this.
git reset --hard
Resetting with the hard option recursively discards all of your currently uncommitted (unstaged or staged) changes.
To target just one blob, use the checkout command to restore the file to its previous committed state.
git checkout -- Person.java
When the developer is ready to put files into the next commit, they must be first staged with the add command. Users can navigate to any directory, adding files item by item, or by wildcard.
git add <file name, folder name, or wildcard>
git add submodule1/PrimaryClass.java
git add .
git add *.java
Specifying a folder name as the target of a git add recursively stages files in any subdirectories.
The -i option activates interactive add mode, in which Git prompts for the files to be added or excluded from the next commit.
git add -i
The -p option is a shortcut for activation of the patch sub-mode of the interactive prompt, allowing for precise pieces within a file to be selected for staging.
git add -p
Once all desired blobs are staged, a commit command transactionally saves the pending additions to the local repository. The default text $EDITOR will be opened for entry of the commit message.
To supply the commit message directly at the command prompt:
git commit –m”<your commit message>”
To view the statistics and facts about the last commit:
If a mistake was made in the last commit’s message, edit the ext while leaving the changed files as-is with:
Branching superficially appears much the same as it does in other version control systems, but the difference lies in the fact that Git branches can be targeted to exist only locally, or be shared with (pushed to) the rest of the team. The concept of inexpensive local branches increases the frequency in which developers use branching, opening it up to use for quick private experiments that may be discarded if unsuccessful, or merged onto a well-known branch if successful.
git branch <new branch name> <from branch>
git branch <new branch name>
Choosing a Branch
Checking out (switching to) a branch is as simple as providing its name:
git checkout <branch name>
Local and remote git branches are checked out using the same command, but in somewhat of a radical change of operation for users coming from other systems like Subversion, remote branches are read-only until “tracked” and copied to a local branch. Local branches are where new work is performed and code is committed.
git branch<new branch name> <from branch>
git checkout <new branch name>
or alternatively, in a combined command:
git checkout -b <ew branch name> <from branch>
Starting with Git 1.6.6, a shorthand notation can be used to track a remote branch with a local branch of exactly the same name when no local branch of that name already exists and only one remote location is configured.
<remote and local branch name>
git checkout performanceexperiment
To list the complete set of current local and remote branches known to Git:
git branch -a
The local branches typically have simple names like master and experiment. Local branches are shown in white by Git’s default syntax highlighting. Remote branches are prefixed by “remotes” and are shown in red.
Like other popular VCSes, Git allows you to merge one or more branches into the current branch.
git merge <branch one>
git merge <branch one> <branch two>
If any conflicts are encountered, which is rare with Git, a notification message is displayed and the files are internally marked with >>>>>>>>> and <<<<<<<< around the conflicting portion of the file contents. Once manually resolved, git-add the resolved file, then commit in the usual manner.
Rebasing is the rewinding of existing commits on a branch with the intent of moving the “branch start point” forward, then replaying the rewound commits. This allows developers to test their branch changes safely in isolation on their private branch just as if they were made on top of the mainline code, including any recent mainline bug fixes.
git rebase <source branch name>
git rebase <source branch name> <destination branch name>
In Git, tagging operates in a simple manner that approximates other VCSes, but unlike Subversion, tags are immutable from a commit standpoint. To mark a point in your code timeline with a tag:
git tag <tag name>
git tag <tag name> <treeish>