Multi-Threaded Programming II - Native Thread for Win32 (B) Multi-Threaded Programming II - Native Thread for Win32 (A) Multi-Threaded Programming - Terminology - Semaphore, Mutex, Priority Inversion etc. Inheritance & Virtual Inheritance (multiple inheritance) GTest (Google Unit Test) with Visual Studio 2012
Sponsor Open Source development activities and free contents for everyone.Īpplication (UI) - using Windows Forms (Visual Studio 2013/2012)īoost - shared_ptr, weak_ptr, mpl, lambda, etc.īoost.Asio (Socket Programming - Asynchronous TCP/IP).Ĭ++11(C++0x): rvalue references, move constructor, and lambda, etc.Įclipse CDT / JNI (Java Native Interface) / MinGWĮmbedded Systems Programming I - IntroductionĮmbedded Systems Programming II - gcc ARM Toolchain and Simple Code on Ubuntu and FedoraĮmbedded Systems Programming III - Eclipse CDT Plugin for gcc ARM Toolchainįunctors (Function Objects) I - Introductionįunctors (Function Objects) II - Converting function to functor Git/GitHub via SourceTree IV : Git Reset.Git/GitHub via SourceTree III : Git Work Flow.Git/GitHub via SourceTree II : Branching & Merging.Setting up a remote repository / pushing local project and cloning the remote repo.GIT on Ubuntu and OS X - Focused on Branching.
Anything we didn't stage is still sitting there modified we can do another commit to add it to our history. Remember that the commit records the snapshot we set up in our staging area. The commit gives us some output about itself: which branch we committed to (master), what SHA-1 checksum the commit has (463dc4f), how many files were changed, and statistics about lines added and removed in the commit. The simplest way to commit is to type git commit: When we run git status, if we see that everything has been staged, then we're ready to commit our changes. They will stay as modified files on our disk.
Remember that anything that is still unstaged - any files we have created or modified but we haven't run git add after we edited them - won't go into this commit. Now that our staging area is set up the way we want it, we can commit our changes. Though we learned how we commit in the previous chapter, in this chapter, we'll review it again. This can be confusing, because if we've staged all of our changes, git diff will give us no output as shown in the picture below:
It's important to note that git diff by itself doesn't show all changes made since our last commit - only changes that are still unstaged. (In Git versions 1.6.1 and later, we can also use git diff -staged, which may be easier to remember.) This command compares our staged changes to our last commit: If we want to see what we've staged that will go into our next commit, we can use git diff -cached. The result tells us the changes we've made that we haven't yet staged. Git diff command compares what is in our working directory with what is in our staging area. If we want to see what we've changed but not yet staged, type git diff with no other arguments: If we run status command, we see something like this: Let's say we edit and stage the readme file again and then edit the readme file without staging it. We'll probably use it most often to answer these two questions: What have we changed but not yet staged? And what have we staged that we are about to commit? Although git status answers those questions very generally, git diff shows us the exact lines added and removed. Usually, since the git status command is too vague and does not give enough information about the change, when we want to know exactly what we changed not just which files were changed, we can use the git diff command.
Picture source: How to compare the working copy, staging copy and committed copy of a file using git? This is the continuation from the previous tutorial: GIT and GitHub - 2.