Git and GitHub Workflow

#github #git

A (distributed) version control system, compared to SVN which is central.
Git is a version control
GitHub is a cloud service that follows git protocols
Timestamp for every modification
Maintain history of code
use git commit --amend flag -m to fix the commit message
Diff → A diff is a formatted display of the differences between two sets of files
git diff —> tells you which line has changed
git diff -r HEAD
. The -r flag means "compare to a particular revision", and HEAD is a shortcut meaning "the most recent commit".
Logging →git log or git lg (this is cleaner and concise) —> shows the history of what you did
use the spacebar to see additional pages
Press q to end the log
Branching → git checkout → to change branches
Useful for when a team works on multiple features at the same time
or use git checkout -b
git branch → to create a new branch (then your current branch will be the new branch u made)
git branch -v → lists all branches

***********************Major Differences to Understand***********************

Each fork of the main repo corresponds to a contributor's work. A fork is really a GitHub (not Git) construct to store a clone of the repo in your user account. As a clone, it will contain all the branches in the main repo at the time you made the fork.
Each branch within the fork and/or in the main repo can correspond to several kinds of things, depending on how you want to work. Each branch could refer to a version of the project but can also correspond to different channels of development, like hotfixes or experimental work.
Merging → 1st you go back to the master branch using git checkout master, then you merge it using git merge —no-ff <branch name
It's very useful because, if you checkout to master, you can see the load stuff before you made the changes in the checkout branch
Once the branch is merged with the master, u can consider it dead (kinda)
Always switch to master branch and with merge child, and if there is a problem → fix it in the child, then merge it back to master.
If there is an update on the master branch after merge, then the child will mere with master→ then after the bug is fix on child the master will merge with child.

***************Undo A Merge***************

You should always keep in mind that you can return to the state before you started the merge at any time. This should give you the confidence that you can‘t break anything. On the command line, a simple “git merge --abort” will do this for you.
In case you‘ve made a mistake while resolving a conflict and realize this only after completing the merge, you can still easily undo it: just roll back to the commit before the merge happened with “git reset --hard ” and start over again

Getting new branches: At the initial point of a clone, you will have all the branches. However, if other developers add branches and push them to the remote there needs to be a way to 'know' about those branches and their names in order to be able to pull them down locally.
This is done via a git fetch which will get all new and changed branches into the local repository using the tracking branches (e.g., origin/).
Once fetched, one can git branch --remote to list the tracking branches and git checkout [branch] to actually switch to any given one
Delete → to delete the branch you have merged use, git branch -d
GitHub → Just a server in the cloud where push ur git repo to
Remote → use git remote add origin
git remote -v → shows what is added to the remote configuration (GitHub link)
after adding remote origin u can see what sort of command u can use like (fetch & push)
But, you can also have multiple remote locations
if u use Heroku you will use git push Heroku master(the branch name) for the production
while git push origin (GitHub) master sends to GitHub
You could have a branch of a branch

*****Pull*****

git pull → use this when there is a change in their server and u have the old code, this will update ur code

Push

Rebase and Merge?

When doing the checkout of master it's also recommended to do a git pull origin master to get the very latest version of the remote master merged into your local master. If the remote master changed, i.e., moved forward, you will see information that reflects that during that git pull
If that is the case (master changed) you are advised to git checkout your_branch and then rebase it to master so that your changes actually get 'replayed' on top of the 'new' master. Then you would continue with getting master up-to-date as shown in the next paragraph.
When the process doesn't work well you will find that git merge --abort is very handy to reset things.

GitFlow

git flow -h → shows u all the commands u can use with gitflow
git flow init → initial gitflow in repo
here now if u do git branch → u got 2 branches, develop & master
git flow feature -h → gives a list of help commands (list , -h , -v)
here if we use git flow feature list →msg says we don't have any feature because we have to start
git flow feature start → this switches us to a new branch called feature/
now if we do git branch → along with develop and master brah we have feature/
now if u do git checkout develop, ur on the develop branch
then you need to checkout back into the feature/ branch using checkout
then if u do git flow feature finish, this will merge the files on the develop branch and delete the feature branch

*******Alias*******

use git config --global alias.lg "log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"
then use git lg it get a cleaner view on commits at logs

*************MarkDown*************

DEV Community