GIT CONFIG COMMANDS-

to view differences in colored manner -

>> git config --global color.ui auto

to add your name and email address to make a commit -

>> git config --global user.email "[email protected]"

>> git config --global user.name "Your Name"

GIT COMMANDS-

to spot differences between two files on linux command line -

>> diff -u old_file.ext new_file.ext

to view git commits on linux cmd line -

>> git log

>> git log --stat

to view difference between different versions on git in cmd line -

>> git diff old_commit_id new_commit_id

to copy a repository from one computer to another computer along with history of commits -

>> git clone url_of_repo

to roll back to a previous version of the code (basically, to find a bug)-

>> git checkout commit_id

now when we will run >>git log<< , we will see that the commit to which we checked out will be the last commit in the log. all the commits above it are lost. we should have remembered the ids of those commits to roll into that.

to initialise a new git repository on your computer -

>> git init

to view status of the repository -

>> git status

to add a file from working directory in the staging area -

>> git add filename.ext

to commit changes in the repository after adding to the staging area -

>> git commit

>> git commit -m "type the message here"

to view differences in files between working directory and staging area -

staging area consist of files from the last commit. so, if any modification is done in file in wd, to view differences between that file and last commit's file, we compare files in wd to that of staging area because staging area consist of files from the last commit.

>> git diff

to view diff between staging area and commits -

this is done to make sure what actually you are comitting from staging area

>> git diff --staged

to remove accidentally added file in the staging area -

>> git reset filename.ext

to reset changes in file in wd,staging area as compared to last commit file-

>> git reset --hard

to show all the available branches in the git repo -

>> git branch

to create a branch consisting of same code as master -

>> git branch branch_name

to go into a branch -

>> git checkout branch_name

to merge two branches. First, checkout to the branch where you want the head to be after the merge has taken place. in this case master. then merge the new feature to the master branch and delete feature branch. if however, i would want a separate easy mode of the game, i would have checked out that and merged master branch into that. and this time, i wont delete the master branch ofcourse since i need it too.-

>> git merge master branch_to_be_merged

to delete a branch (usually after merging) only label Will get deleted, commits will remain -

>> git branch -d branch_name

to show difference between a commit and its parent -

>> git show commit_id

to visualise branch structure in a readable way-

>> git log --graph --oneline branch1 branch2 branch3

to see commit history of a particular branch -

>> git log branch_name

GITHUB COMMANDS

A remote in a local repo is actually a reference to the github repository. It is used to push and pull from github. When we pull, a remote origin pointing to the repo to be cloned automatically gets setup. So, cloning is effectively equal to creating a remote pointing to the repo and pulling changes to the remote.

to view remotes -

>> git remote -v

to create a remote -

>> git remote add remote_name repo_url.git

to push branch to github -

>> git push remote_name branch_name

to pull branch from github (always make a pull request of the same branch on which you are checked out. (always try it to be master) otherwise automatic merging might take place.) -

>> git pull remote_name branch_name

Forking -

Forking is just like cloning, but on github machines themselves.

Collaborators -

Collaborators can be added to your GitHub repository by their github usernames. adding a collaborator allows him to push changes to your github repository.

3 types of conflicts --

1. When there is a different commit in both local repo and github repo separately

to update the local copy of only the remote branch (actually called origin/master branch) but not the local master branch -

>> git fetch remote_name

actually, git pull is equal to "git fetch origin" and "git merge master origin/master". so, when you pull, first the remote branch gets updated and points to the new commit. (the local master remains as it is). then, local master branch is checked out and a merge of remote branch takes place on that. the local master points to the new merged commit now.

So, why does a "git pull origin master" doesn't generate a merge commit message? reason is fast-forward merges. In a typical pull request, only github has an extra commit than the last sync. in such a case, when pull request is done, origin/master gets updated to that latest commit and master is left behind. (go in a straight line.) so commit line is something like master -> origin/master. say a->b. suppose a and b were on different branches, if we merged them, then it will make a point to show a merge message that the merge came from two different branches a and b. but there is no point in doing so if they are on the same line. because if we merge b into a, and remove label b and add label a to that (actually what fast forward merges do). we, can eventually point to every commit since there is no branching.

So, you should check what method to use to pull contents from github to your local repo. If you are sure of what the changes are, simple make a pull request otherwise do stepwise.

Pull requests - Separate branches with experimental features can be created and pushed into the git repo. then a pull request is made to the original person from which we have forked the repo asking him to review and merge our branch into master branch. If there are any mistakes, the OP can comment. We can fix the code, add, commit and push them to github. Automatically a new pull request will get generated with the commit message to OP.

When someone else also generates a pull request, there can be a conflict between the two pull request. merge other's pull requests, then resolve the yours. It can be resolved by pulling the merged master branch from github to local pc. Merge the master into your branch and resolve the conflicts.(Dont directly merge your branch into master and resolve conflicts and push. this is not acceptable by the op.) Then push it to your repo and a new pull request will be created automatically.

Summary -

You just saw that the workflow when making changes in a separate branch is more complicated than working directly in master, especially when you need to stay up-to-date with changes others are making. Rather than simply pulling and pushing, you need to pull changes into your local master branch, merge the local master into your branch (different-oil, in our case), then push your branch to the remote before finally merging your branch into master, either locally or on GitHub.

2.

When a contributor commit pull request generates a merge conflict with your pull request.

First, merge the contributor's pull request. Then pull the master branch. Merge it into your branch. Resolve the merge conflict.

and create a new pull request.

3.

Keeping fork up-to-date -

If a pull request is generated to the original repository which was forked, there might be a possibility that the master branch

of that repo might have changed the same lines. This might create a merge conflict. To resolve this, create a remote to the

original repo name 'upstream' and run git pull upstream master. Then, merge the master branch to your branch and resolve the

merge conflict. Then push to create a new pull request.