Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
118 changes: 118 additions & 0 deletions 07_git_exercises/Gershoz_ex1/README
Original file line number Diff line number Diff line change
@@ -0,0 +1,118 @@
------------------------------------------------
Git Basics (commit, diff, branches)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

very good!

------------------------------------------------
$ touch abc.txt
$ echo "1" >> abc.txt

RED (New file, wasnt added to index)

$ git add abc.txt (+1) - GREEN
$ git commit - WHITE

\>\

$ echo "2" >> abc.txt
BLUE (Changes has been made to a commited file)

($ git cheakout "workingtree")
$ git diff main

Because we (first created a file and added some text to it, after that we staged/added the changed new file,
and then we commited that step, so the staged tree has been cleared.
Then we added another change to the file, but we did not add/staged it into the index,
so git diff --staged at this point doesnt show anything.)
we are comparing the index to the working tree, they are iddentical, so we get nothing.
(Not sure about this one)

stage2 is not a branch in our repo

$ git add abc.txt (+2)
Now after we added the latest changes to the index "git diff" shows nothing, because we did not made any further changes relative to the index.

$ git diff --staged main

echo "3" >> abc.txt
No, because "git diff --staged" will show us the changes between the staged state at the next commit(+2),
unlike "git diff main" that will show us the changes comparing the working tree and the branch main(+2 +3).

It shows the staged changes and the unstaged changes that has been made.

$ git restore abc.txt (--3)
$ git restore --staged abc.txt
$ git restore abc.txt (--2)

\<\
------------------------------------------------
Resolve conflicts
------------------------------------------------

$ git brnach
$ git checkout -b feature/lambda_migration
$ git checkout feature/lambda_migration
$ git merge feature/version1
$ git merge feature/version2
~conflict~
after resolving the conflict, a conflict commit was added, deatailing the files in which the conflict occurd:

""
Merge branch 'feature/version2' into feature/lambda_migration

# Conflicts:
# app.py

90872ce0 Gershoz <osherovski@gmail.com> on 23/05/2022 at 22:24

In 2 branches:
HEAD
feature/lambda_migration
""

------------------------------------------------
Cherry picking
------------------------------------------------
$ git checkout main
$ git checkout -b feature/lambda_migration2

The files .env and config.json were added
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good


"Cherry Picking" and its order in which you pick the commits is not important,
First because commits to diffrent files cant conflict or lose/overwrite data,
But this might not be true for picking on commits that involve the same files - might be overwritten for each commit.
(Not sure about this one either)

------------------------------------------------
Changes in working tree and switch branches
------------------------------------------------
$ git checkout feature/lambda_migration2
$ touch take.txt && echo "some txt" >> take.txt
$ git add take.txt
$ git checkout dev

"error: Your local changes to the following files would be overwritten by checkout:
take.txt
Please commit your changes or stash them before you switch branches.
Aborting"
>> "commit" or "stash"

Using "Force Checkout" did not save my changes to the file take.txt in branch "dev"

$ git checkout feature/lambda_migration2

The take.txt file has been deleted,
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

great

I assume "Force Checkout" probably forces the changes that hasnt been
commited forcufully - Meaning if the changes can be simply inserted to the new branch they will be,
otherwise the changes will get lost as they havent been commited and cant be saved to the new brach.

------------------------------------------------
Reset
------------------------------------------------

$ git checkout reset_question

$ git reset --soft HEAD~1
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does each one of reset methods mean (soft, hard, mixed etc..)?

$ git reset --mixed HEAD~1
$ git reset --hard HEAD~1
$ git revert HEAD~1

If I undesrtand what I see it would suggest that HEAD~x is steping back in the commit history x steps..
What Im sure of is that I messed up this branch!