Category: git

Git – Move Operation ”; Previous Next As the name suggests, the move operation moves a directory or a file from one location to another. Tom decides to move the source code into src directory. The modified directory structure will appear as follows − [tom@CentOS project]$ pwd /home/tom/project [tom@CentOS project]$ ls README string string.c [tom@CentOS project]$ mkdir src [tom@CentOS project]$ git mv string.c src/ [tom@CentOS project]$ git status -s R string.c −> src/string.c ?? string To make these changes permanent, we have to push the modified directory structure to the remote repository so that other developers can see this. [tom@CentOS project]$ git commit -m “Modified directory structure” [master 7d9ea97] Modified directory structure 1 files changed, 0 insertions(+), 0 deletions(-) rename string.c => src/string.c (100%) [tom@CentOS project]$ git push origin master Counting objects: 4, done. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 320 bytes, done. Total 3 (delta 0), reused 0 (delta 0) To [email protected]:project.git e86f062..7d9ea97 master −> master In Jerry’s local repository, before the pull operation, it will show the old directory structure. [jerry@CentOS project]$ pwd /home/jerry/jerry_repo/project [jerry@CentOS project]$ ls README string string.c But after the pull operation, the directory structure will get updated. Now, Jerry can see the src directory and the file present inside that directory. [jerry@CentOS project]$ git pull remote: Counting objects: 4, done. remote: Compressing objects: 100% (2/2), done. remote: Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. From git.server.com:project e86f062..7d9ea97 master −> origin/master First, rewinding head to replay your work on top of it… Fast-forwarded master to 7d9ea97683da90bcdb87c28ec9b4f64160673c8a. [jerry@CentOS project]$ ls README src string [jerry@CentOS project]$ ls src/ string.c Print Page Previous Next Advertisements ”;

Git – Update Operation ”; Previous Next Modify Existing Function Tom performs the clone operation and finds a new file string.c. He wants to know who added this file to the repository and for what purpose, so, he executes the git log command. [tom@CentOS ~]$ git clone [email protected]:project.git The above command will produce the following result − Initialized empty Git repository in /home/tom/project/.git/ remote: Counting objects: 6, done. remote: Compressing objects: 100% (4/4), done. Receiving objects: 100% (6/6), 726 bytes, done. remote: Total 6 (delta 0), reused 0 (delta 0) The Clone operation will create a new directory inside the current working directory. He changes the directory to newly created directory and executes the git log command. [tom@CentOS ~]$ cd project/ [tom@CentOS project]$ git log The above command will produce the following result − commit d1e19d316224cddc437e3ed34ec3c931ad803958 Author: Jerry Mouse <[email protected]> Date: Wed Sep 11 08:05:26 2013 +0530 Changed return type of my_strlen to size_t commit 19ae20683fc460db7d127cf201a1429523b0e319 Author: Tom Cat <[email protected]> Date: Wed Sep 11 07:32:56 2013 +0530 Initial commit After observing the log, he realizes that the file string.c was added by Jerry to implement basic string operations. He is curious about Jerry’s code. So he opens string.c in text editor and immediately finds a bug. In my_strlen function, Jerry is not using a constant pointer. So, he decides to modify Jerry’s code. After modification, the code looks as follows − [tom@CentOS project]$ git diff The above command will produce the following result − diff –git a/string.c b/string.c index 7da2992..32489eb 100644 — a/string.c +++ b/string.c @@ -1,8 +1,8 @@ #include <stdio.h> -size_t my_strlen(char *s) +size_t my_strlen(const char *s) { – char *p = s; + const char *p = s; while (*p) ++p; } After testing, he commits his change. [tom@CentOS project]$ git status -s M string.c ?? string [tom@CentOS project]$ git add string.c [tom@CentOS project]$ git commit -m ”Changed char pointer to const char pointer” [master cea2c00] Changed char pointer to const char pointer 1 files changed, 2 insertions(+), 2 deletions(-) [tom@CentOS project]$ git log The above command will produce the following result − commit cea2c000f53ba99508c5959e3e12fff493b Author: Tom Cat <[email protected]> Date: Wed Sep 11 08:32:07 2013 +0530 Changed char pointer to const char pointer commit d1e19d316224cddc437e3ed34ec3c931ad803958 Author: Jerry Mouse <[email protected]> Date: Wed Sep 11 08:05:26 2013 +0530 Changed return type of my_strlen to size_t commit 19ae20683fc460db7d127cf201a1429523b0e319 Author: Tom Cat <[email protected]> Date: Wed Sep 11 07:32:56 2013 +0530 Initial commit Tom uses git push command to push his changes. [tom@CentOS project]$ git push origin master The above command will produce the following result − Counting objects: 5, done. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 336 bytes, done. Total 3 (delta 1), reused 0 (delta 0) To [email protected]:project.git d1e19d3..cea2c00 master −> master Add New Function Meanwhile, Jerry decides to implement string compare functionality. So he modifies string.c. After modification, the file looks as follows − [jerry@CentOS project]$ git diff The above command will produce the following result − index 7da2992..bc864ed 100644 — a/string.c +++ b/string.c 30Git Tutorials @@ -9,9 +9,20 @@ size_t my_strlen(char *s) return (p -s ); } +char *my_strcpy(char *t, char *s) + { + char *p = t; + + while (*t++ = *s++) + ; + + return p; + } + int main(void) { int i; + char p1[32]; char *s[] = { “Git tutorials”, “Tutorials Point” @@ -20,5 +31,7 @@ int main(void) for (i = 0; i < 2; ++i) printf(“string lenght of %s = %lun”, s[i], my_strlen(s[i])); + printf(“%sn”, my_strcpy(p1, “Hello, World !!!”)); + return 0; } } After testing, he is ready to push his change. [jerry@CentOS project]$ git status -s M string.c ?? string [jerry@CentOS project]$ git add string.c [jerry@CentOS project]$ git commit -m “Added my_strcpy function” [master e944e5a] Added my_strcpy function 1 files changed, 13 insertions(+), 0 deletions(-) Before push operation, he verifies commit by viewing log messages. [jerry@CentOS project]$ git log The above command will produce the following result − commit e944e5aab74b26e7447d3281b225309e4e59efcd Author: Jerry Mouse <[email protected]> Date: Wed Sep 11 08:41:42 2013 +0530 Added my_strcpy function commit d1e19d316224cddc437e3ed34ec3c931ad803958 Author: Jerry Mouse <[email protected]> Date: Wed Sep 11 08:05:26 2013 +0530 Changed return type of my_strlen to size_t commit 19ae20683fc460db7d127cf201a1429523b0e319 Author: Tom Cat <[email protected]> Date: Wed Sep 11 07:32:56 2013 +0530 Initial commit Jerry is happy with the changes and he wants to push his changes. [jerry@CentOS project]$ git push origin master The above command will produce the following result − To [email protected]:project.git ! [rejected] master −> master (non-fast-forward) error: failed to push some refs to ”[email protected]:project.git” To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes before pushing again. See the ”Note about fast-forwards” section of ”git push –help” for details. But Git is not allowing Jerry to push his changes. Because Git identified that remote repository and Jerry’s local repository are not in sync. Because of this, he can lose the history of the project. To avoid this mess, Git failed this operation. Now, Jerry has to first update the local repository and only thereafter, he can push his own changes. Fetch Latest Changes Jerry executes the git pull command to synchronize his local repository with the remote one. [jerry@CentOS project]$ git pull The above command will produce the following result − remote: Counting objects: 5, done. remote: Compressing objects: 100% (3/3), done. remote: Total 3 (delta 1), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. From git.server.com:project d1e19d3..cea2c00 master −> origin/master First, rewinding head to replay your work on top of it… Applying: Added my_strcpy function After pull operation, Jerry checks the log messages and finds the details of Tom’s commit with commit ID cea2c000f53ba99508c5959e3e12fff493ba6f69 [jerry@CentOS project]$ git log The above command will produce the following result − commit e86f0621c2a3f68190bba633a9fe6c57c94f8e4f Author: Jerry Mouse <[email protected]> Date: Wed Sep 11 08:41:42 2013 +0530 Added my_strcpy function commit cea2c000f53ba99508c5959e3e12fff493ba6f69 Author: Tom Cat <[email protected]> Date: Wed Sep 11 08:32:07 2013 +0530 Changed char pointer to const char pointer commit d1e19d316224cddc437e3ed34ec3c931ad803958 Author: Jerry Mouse <[email protected]> Date: Wed Sep 11 08:05:26 2013 +0530

Git – Different Platforms ”; Previous Next GNU/Linux and Mac OS uses line-feed (LF), or new line as line ending character, while Windows uses line-feed and carriage-return (LFCR) combination to represent the line-ending character. To avoid unnecessary commits because of these line-ending differences, we have to configure the Git client to write the same line ending to the Git repository. For Windows system, we can configure the Git client to convert line endings to CRLF format while checking out, and convert them back to LF format during the commit operation. The following settings will do the needful. [tom@CentOS project]$ git config –global core.autocrlf true For GNU/Linux or Mac OS, we can configure the Git client to convert line endings from CRLF to LF while performing the checkout operation. [tom@CentOS project]$ git config –global core.autocrlf input Print Page Previous Next Advertisements ”;

Git – Fix Mistakes ”; Previous Next To err is human. So every VCS provides a feature to fix mistakes until a certain point. Git provides a feature that we can use to undo the modifications that have been made to the local repository. Suppose the user accidentally does some changes to his local repository and then wants to undo these changes. In such cases, the revert operation plays an important role. Revert Uncommitted Changes Let us suppose Jerry accidentally modifies a file from his local repository. But he wants to undo his modification. To handle this situation, we can use the git checkout command. We can use this command to revert the contents of a file. [jerry@CentOS src]$ pwd /home/jerry/jerry_repo/project/src [jerry@CentOS src]$ git status -s M string_operations.c [jerry@CentOS src]$ git checkout string_operations.c [jerry@CentOS src]$ git status –s Further, we can use the git checkout command to obtain a deleted file from the local repository. Let us suppose Tom deletes a file from the local repository and we want this file back. We can achieve this by using the same command. [tom@CentOS src]$ pwd /home/tom/top_repo/project/src [tom@CentOS src]$ ls -1 Makefile string_operations.c [tom@CentOS src]$ rm string_operations.c [tom@CentOS src]$ ls -1 Makefile [tom@CentOS src]$ git status -s D string_operations.c Git is showing the letter D before the filename. This indicates that the file has been deleted from the local repository. [tom@CentOS src]$ git checkout string_operations.c [tom@CentOS src]$ ls -1 Makefile string_operations.c [tom@CentOS src]$ git status -s Note − We can perform all these operations before commit. Remove Changes from Staging Area We have seen that when we perform an add operation, the files move from the local repository to the stating area. If a user accidently modifies a file and adds it into the staging area, he can revert his changes, by using the git checkout command. In Git, there is one HEAD pointer that always points to the latest commit. If you want to undo a change from the staged area, then you can use the git checkout command, but with the checkout command, you have to provide an additional parameter, i.e., the HEAD pointer. The additional commit pointer parameter instructs the git checkout command to reset the working tree and also to remove the staged changes. Let us suppose Tom modifies a file from his local repository. If we view the status of this file, it will show that the file was modified but not added into the staging area. tom@CentOS src]$ pwd /home/tom/top_repo/project/src # Unmodified file [tom@CentOS src]$ git status -s # Modify file and view it’s status. [tom@CentOS src]$ git status -s M string_operations.c [tom@CentOS src]$ git add string_operations.c Git status shows that the file is present in the staging area, now revert it by using the git checkout command and view the status of the reverted file. [tom@CentOS src]$ git checkout HEAD — string_operations.c [tom@CentOS src]$ git status -s Move HEAD Pointer with Git Reset After doing few changes, you may decide to remove these changes. The Git reset command is used to reset or revert changes. We can perform three different types of reset operations. Below diagram shows the pictorial representation of Git reset command. Soft Each branch has a HEAD pointer, which points to the latest commit. If we use Git reset command with –soft option followed by commit ID, then it will reset the HEAD pointer only without destroying anything. .git/refs/heads/master file stores the commit ID of the HEAD pointer. We can verify it by using the git log -1 command. [jerry@CentOS project]$ cat .git/refs/heads/master 577647211ed44fe2ae479427a0668a4f12ed71a1 Now, view the latest commit ID, which will match with the above commit ID. [jerry@CentOS project]$ git log -2 The above command will produce the following result. commit 577647211ed44fe2ae479427a0668a4f12ed71a1 Author: Tom Cat <[email protected]> Date: Wed Sep 11 10:21:20 2013 +0530 Removed executable binary commit 29af9d45947dc044e33d69b9141d8d2dad37cc62 Author: Jerry Mouse <[email protected]> Date: Wed Sep 11 10:16:25 2013 +0530 Added compiled binary Let us reset the HEAD pointer. [jerry@CentOS project]$ git reset –soft HEAD~ Now, we just reset the HEAD pointer back by one position. Let us check the contents of .git/refs/heads/master file. [jerry@CentOS project]$ cat .git/refs/heads/master 29af9d45947dc044e33d69b9141d8d2dad37cc62 Commit ID from file is changed, now verify it by viewing commit messages. jerry@CentOS project]$ git log -2 The above command will produce the following result. commit 29af9d45947dc044e33d69b9141d8d2dad37cc62 Author: Jerry Mouse <[email protected]> Date: Wed Sep 11 10:16:25 2013 +0530 Added compiled binary commit 94f7b26005f856f1a1b733ad438e97a0cd509c1a Author: Jerry Mouse <[email protected]> Date: Wed Sep 11 10:08:01 2013 +0530 Added Makefile and renamed strings.c to string_operations.c mixed Git reset with –mixed option reverts those changes from the staging area that have not been committed yet. It reverts the changes from the staging area only. The actual changes made to the working copy of the file are unaffected. The default Git reset is equivalent to the git reset — mixed. hard If you use –hard option with the Git reset command, it will clear the staging area; it will reset the HEAD pointer to the latest commit of the specific commit ID and delete the local file changes too. Let us check the commit ID. [jerry@CentOS src]$ pwd /home/jerry/jerry_repo/project/src [jerry@CentOS src]$ git log -1 The above command will produce the following result. commit 577647211ed44fe2ae479427a0668a4f12ed71a1 Author: Tom Cat <[email protected]> Date: Wed Sep 11 10:21:20 2013 +0530 Removed executable binary Jerry modified a file by adding single-line comment at the start of file. [jerry@CentOS src]$ head -2 string_operations.c /* This line be removed by git reset operation */ #include <stdio.h> He verified it by using the git status command. [jerry@CentOS src]$ git status -s M string_operations.c Jerry adds the modified file to the staging area and verifies it with the git status command. [jerry@CentOS src]$ git add string_operations.c [jerry@CentOS src]$ git status The above command will produce the following result. # On branch master # Changes to be committed: # (use “git reset HEAD <file>…” to unstage) # # modified: string_operations.c # Git status is showing that the file is present in the staging area. Now,

Git – Stash Operation ”; Previous Next Suppose you are implementing a new feature for your product. Your code is in progress and suddenly a customer escalation comes. Because of this, you have to keep aside your new feature work for a few hours. You cannot commit your partial code and also cannot throw away your changes. So you need some temporary space, where you can store your partial changes and later on commit it. In Git, the stash operation takes your modified tracked files, stages changes, and saves them on a stack of unfinished changes that you can reapply at any time. [jerry@CentOS project]$ git status -s M string.c ?? string Now, you want to switch branches for customer escalation, but you don’t want to commit what you’ve been working on yet; so you’ll stash the changes. To push a new stash onto your stack, run the git stash command. [jerry@CentOS project]$ git stash Saved working directory and index state WIP on master: e86f062 Added my_strcpy function HEAD is now at e86f062 Added my_strcpy function Now, your working directory is clean and all the changes are saved on a stack. Let us verify it with the git status command. [jerry@CentOS project]$ git status -s ?? string Now you can safely switch the branch and work elsewhere. We can view a list of stashed changes by using the git stash list command. [jerry@CentOS project]$ git stash list stash@{0}: WIP on master: e86f062 Added my_strcpy function Suppose you have resolved the customer escalation and you are back on your new feature looking for your half-done code, just execute the git stash pop command, to remove the changes from the stack and place them in the current working directory. [jerry@CentOS project]$ git status -s ?? string [jerry@CentOS project]$ git stash pop The above command will produce the following result: # On branch master # Changed but not updated: # (use “git add …” to update what will be committed) # (use “git checkout — …” to discard changes in working directory) # # modified: string.c # # Untracked files: # (use “git add …” to include in what will be committed) # # string no changes added to commit (use “git add” and/or “git commit -a”) Dropped refs/stash@{0} (36f79dfedae4ac20e2e8558830154bd6315e72d4) [jerry@CentOS project]$ git status -s M string.c ?? string Print Page Previous Next Advertisements ”;

Git – Perform Changes ”; Previous Next Jerry clones the repository and decides to implement basic string operations. So he creates string.c file. After adding the contents, string.c will look like as follows − #include <stdio.h> int my_strlen(char *s) { char *p = s; while (*p) ++p; return (p – s); } int main(void) { int i; char *s[] = { “Git tutorials”, “Tutorials Point” }; for (i = 0; i < 2; ++i) printf(“string lenght of %s = %dn”, s[i], my_strlen(s[i])); return 0; } He compiled and tested his code and everything is working fine. Now, he can safely add these changes to the repository. Git add operation adds file to the staging area. [jerry@CentOS project]$ git status -s ?? string ?? string.c [jerry@CentOS project]$ git add string.c Git is showing a question mark before file names. Obviously, these files are not a part of Git, and that is why Git does not know what to do with these files. That is why, Git is showing a question mark before file names. Jerry has added the file to the stash area, git status command will show files present in the staging area. [jerry@CentOS project]$ git status -s A string.c ?? string To commit the changes, he used the git commit command followed by –m option. If we omit –m option. Git will open a text editor where we can write multiline commit message. [jerry@CentOS project]$ git commit -m ”Implemented my_strlen function” The above command will produce the following result − [master cbe1249] Implemented my_strlen function 1 files changed, 24 insertions(+), 0 deletions(-) create mode 100644 string.c After commit to view log details, he runs the git log command. It will display the information of all the commits with their commit ID, commit author, commit date and SHA-1 hash of commit. [jerry@CentOS project]$ git log The above command will produce the following result − commit cbe1249b140dad24b2c35b15cc7e26a6f02d2277 Author: Jerry Mouse <[email protected]> Date: Wed Sep 11 08:05:26 2013 +0530 Implemented my_strlen function commit 19ae20683fc460db7d127cf201a1429523b0e319 Author: Tom Cat <[email protected]> Date: Wed Sep 11 07:32:56 2013 +0530 Initial commit Print Page Previous Next Advertisements ”;

Git – Clone Operation ”; Previous Next We have a bare repository on the Git server and Tom also pushed his first version. Now, Jerry can view his changes. The Clone operation creates an instance of the remote repository. Jerry creates a new directory in his home directory and performs the clone operation. [jerry@CentOS ~]$ mkdir jerry_repo [jerry@CentOS ~]$ cd jerry_repo/ [jerry@CentOS jerry_repo]$ git clone [email protected]:project.git The above command will produce the following result. Initialized empty Git repository in /home/jerry/jerry_repo/project/.git/ remote: Counting objects: 3, done. Receiving objects: 100% (3/3), 241 bytes, done. remote: Total 3 (delta 0), reused 0 (delta 0) Jerry changes the directory to new local repository and lists its directory contents. [jerry@CentOS jerry_repo]$ cd project/ [jerry@CentOS jerry_repo]$ ls README Print Page Previous Next Advertisements ”;

Git – Basic Concepts ”; Previous Next Version Control System Version Control System (VCS) is a software that helps software developers to work together and maintain a complete history of their work. Listed below are the functions of a VCS − Allows developers to work simultaneously. Does not allow overwriting each other’s changes. Maintains a history of every version. Following are the types of VCS − Centralized version control system (CVCS). Distributed/Decentralized version control system (DVCS). In this chapter, we will concentrate only on distributed version control system and especially on Git. Git falls under distributed version control system. Distributed Version Control System Centralized version control system (CVCS) uses a central server to store all files and enables team collaboration. But the major drawback of CVCS is its single point of failure, i.e., failure of the central server. Unfortunately, if the central server goes down for an hour, then during that hour, no one can collaborate at all. And even in a worst case, if the disk of the central server gets corrupted and proper backup has not been taken, then you will lose the entire history of the project. Here, distributed version control system (DVCS) comes into picture. DVCS clients not only check out the latest snapshot of the directory but they also fully mirror the repository. If the server goes down, then the repository from any client can be copied back to the server to restore it. Every checkout is a full backup of the repository. Git does not rely on the central server and that is why you can perform many operations when you are offline. You can commit changes, create branches, view logs, and perform other operations when you are offline. You require network connection only to publish your changes and take the latest changes. Advantages of Git Free and open source Git is released under GPL’s open source license. It is available freely over the internet. You can use Git to manage property projects without paying a single penny. As it is an open source, you can download its source code and also perform changes according to your requirements. Fast and small As most of the operations are performed locally, it gives a huge benefit in terms of speed. Git does not rely on the central server; that is why, there is no need to interact with the remote server for every operation. The core part of Git is written in C, which avoids runtime overheads associated with other high-level languages. Though Git mirrors entire repository, the size of the data on the client side is small. This illustrates the efficiency of Git at compressing and storing data on the client side. Implicit backup The chances of losing data are very rare when there are multiple copies of it. Data present on any client side mirrors the repository, hence it can be used in the event of a crash or disk corruption. Security Git uses a common cryptographic hash function called secure hash function (SHA1), to name and identify objects within its database. Every file and commit is check-summed and retrieved by its checksum at the time of checkout. It implies that, it is impossible to change file, date, and commit message and any other data from the Git database without knowing Git. No need of powerful hardware In case of CVCS, the central server needs to be powerful enough to serve requests of the entire team. For smaller teams, it is not an issue, but as the team size grows, the hardware limitations of the server can be a performance bottleneck. In case of DVCS, developers don’t interact with the server unless they need to push or pull changes. All the heavy lifting happens on the client side, so the server hardware can be very simple indeed. Easier branching CVCS uses cheap copy mechanism, If we create a new branch, it will copy all the codes to the new branch, so it is time-consuming and not efficient. Also, deletion and merging of branches in CVCS is complicated and time-consuming. But branch management with Git is very simple. It takes only a few seconds to create, delete, and merge branches. DVCS Terminologies Local Repository Every VCS tool provides a private workplace as a working copy. Developers make changes in their private workplace and after commit, these changes become a part of the repository. Git takes it one step further by providing them a private copy of the whole repository. Users can perform many operations with this repository such as add file, remove file, rename file, move file, commit changes, and many more. Working Directory and Staging Area or Index The working directory is the place where files are checked out. In other CVCS, developers generally make modifications and commit their changes directly to the repository. But Git uses a different strategy. Git doesn’t track each and every modified file. Whenever you do commit an operation, Git looks for the files present in the staging area. Only those files present in the staging area are considered for commit and not all the modified files. Let us see the basic workflow of Git. Step 1 − You modify a file from the working directory. Step 2 − You add these files to the staging area. Step 3 − You perform commit operation that moves the files from the staging area. After push operation, it stores the changes permanently to the Git repository. Suppose you modified two files, namely “sort.c” and “search.c” and you want two different commits for each operation. You can add one file in the staging area and do commit. After the first commit, repeat the same procedure for another file. # First commit [bash]$ git add sort.c # adds file to the staging area [bash]$ git commit –m “Added sort operation” # Second commit [bash]$ git add search.c # adds file to the staging area [bash]$ git commit –m “Added search operation” Blobs Blob stands for Binary Large Object. Each

Git – Life Cycle ”; Previous Next In this chapter, we will discuss the life cycle of Git. In later chapters, we will cover the Git commands for each operation. General workflow is as follows − You clone the Git repository as a working copy. You modify the working copy by adding/editing files. If necessary, you also update the working copy by taking other developer”s changes. You review the changes before commit. You commit changes. If everything is fine, then you push the changes to the repository. After committing, if you realize something is wrong, then you correct the last commit and push the changes to the repository. Shown below is the pictorial representation of the work-flow. Print Page Previous Next Advertisements ”;