techiepriyansh/GitExercisesWriteUp.md

## GitExercisesWriteUp.md

      
    Raw
  

              GitExercisesWriteUp.md
            
          
    GitExercises WriteUp

This is a write-up of the GitExercises upto level "fixed-old-typo".
master

Problem Statement


The first exercise is to push a commit that is created when you run the  git start  command.


Just try  git verify  after you have initialized the exercises and be proud of passing the first one :-)

Solution

We do as instructed in the problem, i.e., run git verify and we are done!
commit-one-file

Problem Statement


There are two files created in the root project directory -  A.txt  and  B.txt.


The goal is to commit only one of them.

Solution

In order to commit just a single file, we need to have only one file in our staging area. So we run git add A.txt to just add A.txt to the staging are and then simply commit it with git commit -m "commit_message".
commit-one-file-staged

Problem Statement


There are two files created in the root project directory -  A.txt  and  B.txt. They are both added to the staging area.


The goal is to commit only one of them.

Solution

First we unstage everything with git reset and then simply proceed as in the "commit-one-file" level.
ignore-them

Problem Statement


It is often good idea to tell Git which files it should track and which it should not. Developers almost always do not want to include generated files, compiled code or libraries into their project history.


Your task is to create and commit configuration that would ignore:


all files with  exe  extension
all files with  o  extension
all files with  jar  extension
the whole  libraries  directory


Sample files are generated for you.

Solution

It turns out that there is something called a .gitignore file which can be used instruct git to ignore some files. So, we simply create a .gitignore file and specify the file-patterns we wish to ignore as illustrated below:
# .gitignore file
*.exe
*.o
*.jar
libraries/
chase-branch

Problem Statement


You are currently on chase-branch branch. There is also escaped branch that has two more commits.

   HEAD
     |
chase-branch        escaped
     |                 |
     A <----- B <----- C


You want to make chase-branch to point to the same commit as the escaped branch.

                    escaped
                       |
     A <----- B <----- C
                       |
                  chase-branch
                       |
                      HEAD

Solution

The problem is simply asking us to merge the escaped branch with chase branch. As we are already on the chase-branch we can simply execute git merge escaped to do so.
merge-conflict

Problem Statement


Merge conflict appears when you change the same part of the same file differently in the two branches you're merging together. Conflicts require developer to solve them by hand.


Your repository looks like this:

        HEAD
         |
    merge-conflict
         |
A <----- B
 \
  \----- C
         |
another-piece-of-work


You want to merge the  another-piece-of-work  into your current branch. This will cause a merge conflict which you have to resolve. Your repository should look like this:

                 HEAD
                  |
             merge-conflict
                  |
A <----- B <----- D
 \               /
  \----- C <----/
         |
another-piece-of-work

Solution

Let's first try to execute git merge another-piece-of-work .
This will result in a merge conflict and the equation.txt file will be modified by git to look something like this:
<<<<<<< HEAD
2 + ? = 5
=======
? + 3 = 5
>>>>>>> another-piece-of-work


This is a way of git to provide us information regarding the merge-conflict.
We can resolve this conflict by modifying the equation.txt file and then committing it.
equation.txt  after the desired changes may look something like this:
2 + 3 = 5

Now, simply committing this change will resolve the merge-conflict and the branches will be merged.
save-your-work

Problem Statement


You are working hard on a regular issue while your boss comes in and wants you to fix a bug. State of your current working area is a total mess so you don't feel comfortable with making a commit now. However, you need to fix the found bug ASAP.


Git lets you to save your work  on a side  and continue it later. Find appropriate Git tool and use it to handle the situation appropriately.


Look for a bug to remove in  bug.txt.


After you commit the bugfix, get back to your work. Finish it by adding a new line to  bug.txt  with

Finally, finished it!


Then, commit your work after bugfix.

Solution

The save your work on a side thing the question is talking about can be done with the git stash command.
So first, we add the current changes to the staging area with git add .  and then we save it for later using the git stash command. This will remove all the current changes from the working area and save them for later use.
Now we look for the bug in bug.txt file and remove it.
This file contains bug
It has to be somewhere.
I feel like I can smell it.
THIS IS A BUG - remove the whole line to fix it.
How this program could work with such bug?


After the bugfix, bug.txt will look something like this:
This file contains bug
It has to be somewhere.
I feel like I can smell it.
How this program could work with such bug?


We commit these changes with git commit -am "fixed bug".
Finally, we recover our previous changes with git stash pop, do the required changes and commit them.
change-branch-history

Problem Statement


You were working on a regular issue while your boss came in and told you to fix recent bug in an application. Because your work on the issue hasn't been done yet, you decided to go back where you started and do a bug fix there.


Your repository look like this:

        HEAD
         |
change-branch-history
         |
A <----- B
 \
  \----- C
         |
     hot-bugfix


Now you realized that the bug is really annoying and you don't want to continue your work without the fix you have made. You wish your repository looked like you started after fixing a bug.

                 HEAD
                  |
         change-branch-history
                  |
A <----- C <----- B
         |
     hot-bugfix


Achieve that.

Solution

We basically need to rebase our current branch change-branch-history on top of hot-bugfix. This can be achieved by the git rebase command as follows:
$ git rebase hot-bugfix
Successfully rebased and updated refs/heads/change-branch-history.

remove-ignored

Problem Statement


File  ignored.txt  is ignored by rule in  .gitignore  but is tracked because it had been added before the ignoring rule was introduced.


Remove it so changes in  ignored.txt  file are not tracked anymore.

Solution

We simply remove the file from our working area by executinggit rm ignored.txt and then finish off by committing the changes.
case-sensitive-filename

Problem Statement


You have committed a  File.txt  but then you realized the filename should be all lowercase:  file.txt. Change the filename.


This one is tricky on Windows, or in any filesystem that treats  File.txt  and  file.txt  as the same files.

Solution

On unix based systems, one can simply do mv File.txt file.txt but an OS-independent solution would be git mv File.txt file.txt.
fix-typo

Problem Statement


You have committed  file.txt  but you realized you made a typo - you wrote  wordl  instead of  world.


Edit previous commit so no one would realize you haven't checked the file before committing it.


Pay attention to the commit message, too!

Solution

The last commit can be modified by first doing and staging the required changes and then executing git commit with --amend flag.
So first we fix the typo in file.txt, save it and then stage it. Then we execute git commit --amend. This will open up a text editor with the commit message which can be modified. Here we fix the typo in the commit message and we are done.
forge-date

Problem Statement


You should have finished your work a week ago. However, you had some more important things to do so you have committed the work just now.


As a git expert, change the date of the last commit. Don't be modest - make it look like it was committed in 1987!

Solution

In order to change the date of the commit, we can simply executegit commit --amend with the added date=$date option as follows:
git commit --amend --no-edit --date="1987-01-01"
The extra --no-edit flag tells git not to open up editor as we don't need to modify the commit message.
fix-old-typo

Problem Statement


While you were working you noticed a typographic error in  file.txt  - you wrote  wordl  instead of  world.


Unfortunately, you have made another commit on top of the typo so simple  git commit --amend  is not enough.


Fix the typographic error by amending commit in history. Pay attention to the commit message, too!

Solution

We need to modify the second last commit. In order to modify commits before the last commit, we will need to use the git rebase command in interactive mode. For our case, we execute
git rebase -i HEAD~2
The HEAD~n tells the rebase command that the commits we need to modify are present in the last n commits. This will open up a file in a text editor which will look something like this:
pick 40658cb Add Hello wordl
pick 20f0601 Further work on Hello world

We need to modify the "Add hello wordl" commit. So we change it's command from pick to edit like this
edit 40658cb Add Hello wordl
pick 20f0601 Further work on Hello world

After doing this change, we save the file. The interactive rebase is now stopped at the "Add Hello wordl" commit. We can now do the desired changes in this commit.
Once all the required changes are done, we stage the relevant files and execute git rebase --continue . Executing this will amend the current commit and then move on to the next one.
But it turns out that these changes have given rise to a merge-conflict in merging the next commit with the current commit that we have modified. We will need to resolve the conflict by doing appropriate changes, staging the changed files and then executing git rebase --continue. And with that, we are done!