Lesson 15: Git Github (Part 2) - CodeAcademy-Online/python-level-1 GitHub Wiki

When we are working on a bigger project it is a good practice to NOT PUSH DIRECTLY TO MAIN/MASTER. We usually create feature branch and then work on our feature there, once the work is done we ask our colleagues to review change with Pull Request (We will see what that is shortly). Once we are given feedback and solve all the issues - we are allowed to merge our codebase with the one that is in the main branch.

command to create new branch is:

git checkout -b <branch_name>

Once you start working on it and do the first push, just do git push - git will throw an error but will suggest the correct command on how to set upstream (basically this means that we are mapping the branch from our computer to the one on remote - GitHub, GitLab, bitbucket or whatever you are using)

Note: git terminal is extremely useful - it gives you suggestions whenever you are doing something wrong. So just keep an eye on terminal messages!

As mentioned before once you finish working on the feature and you feel that everything is done - you now should create a pull request and inform your colleagues that they now have to review your changes. This way you get feedback from senior colleagues, maybe some guidance how to fix, implement something etc. You can exchange comments in GitHub and other popular version control platforms. Let's go through quick demo of how typical pull request looks like.

It is quite usual scenario when we are working on branches and let's say you and your colleague change a certain part in the code. And once you are trying to merge those codebases they end up in the merge conflict. As scary as it may sound it actually a typical scenario in everyday life. You just do not need to panic if you see something like that. Just keep inspecting git status and look into the files where the changes are appearing. We will now do a quick demo to demonstrate this scenario.

Follow the steps in order to get the merge conflict

1. split into pairs of 2 people
2. create an empty repo
3. invite each other to collaborate
4. create a python file, write couple of functions and commit changes and push.
5. let another party to pull latest changes
6. At this point it is important that both of you do a change to the same file, same function. Try reimplementing it in some other way. But important thing here is that both parties should be trying to do changes in the same place of the file.
7. One party does classic -> add, commit , push. Then another tries doing so as well... And get's a merge conflict
8. communicate with your party which version is the right one and should stay in source code.
9. solve conflict.
10. push changes.

The git revert command can be considered an 'undo' type command, however, it is not a traditional undo operation. Instead of removing the commit from the project history, it figures out how to invert the changes introduced by the commit and appends a new commit with the resulting inverse content. This prevents git from losing history, which is important for the integrity of your revision history and for reliable collaboration. command:

git revert <commit_hash>

reverting multiple commits:

git revert --no-commit HEAD~3..

git commit -m "your message regarding reverting the multiple commits"

Merging is git's way of putting a forked history back together again. The git merge command lets you take the independent lines of development created by git branch and integrate them into a single branch.

command

git merge <branch_name>

This moves the entire feature branch to begin on the tip of the main branch, effectively incorporating all of the new commits in main. But, instead of using a merge commit, rebasing re-writes the project history by creating brand new commits for each commit in the original branch.

git rebase <branch_name>

git log

simply allows us to see all the history, commit after commit of what happened.

If after a commit you have done some changes, but at some point decided that you want to roll back you can do:

git restore <file_name>

Note that commited changes cannot be restored like that.

The git reset command is a complex and versatile tool for undoing changes. It has three primary forms of invocation. These forms correspond to command line arguments --soft, --mixed, --hard. The three arguments each correspond to Git's three internal state management mechanism's, The Commit Tree (HEAD), The Staging Index, and The Working Directory.

This is the most direct, DANGEROUS, and frequently used option. When passed --hard The Commit History ref pointers are updated to the specified commit. Then, the Staging Index and Working Directory are reset to match that of the specified commit. Any previously pending changes to the Staging Index and the Working Directory gets reset to match the state of the Commit Tree. This means any pending work that was hanging out in the Staging Index and Working Directory will be lost.

This is the default operating mode. The ref pointers are updated. The Staging Index is reset to the state of the specified commit. Any changes that have been undone from the Staging Index are moved to the Working Directory. Let us continue.

When the --soft argument is passed, the ref pointers are updated and the reset stops there. The Staging Index and the Working Directory are left untouched. This behavior can be hard to clearly demonstrate. Let's continue with our demo repo and prepare it for a soft reset.

command simply lets us see the differences in a file. command: git diff <file_name>

Software as we know it comes in version - Windows 98,2000,7,8,10,11... Python 2.7, 3.5, 3.6.... Usually naming is as follows:

command:

git tag -a v1.4 -m "my version 1.4"

This is a multipurpose command that allows us to do a lot of things, main things are:

1. Jumping from one branch to another git checkout <branch_name>
2. create branch git checkout -b <branch_name>
3. Can jump into a certain commit hash and look around, check files etc. (This returns Detached HEAD, scenario show in picture below)

1. Create a simple project in a pair , add some code and try to emulate work in a team with git workflow.
2. Try playing around with all of the commands shown in this lecture

• More on git commands

---