Git and git workflow best practice

Git and Git Workflow Best Practices Majid Hosseini Scala Backend Developer @ ModernPal www.linkedin.com/in/majidin

Base command ● git init ● git commit -m ● git add ● git clone <address> [directoryName] ● git status -s ● git diff / git diff --cached / git diff --staged / git diff HEAD ● git commit => git config --global core.editor ○ git commit -a -m 'added new benchmarks ● rm vs git rm ● git mv

.gitignore ● Blank lines or lines starting with # are ignored. ● Standard glob patterns work, and will be applied recursively throughout the entire working tree. ● You can start patterns with a forward slash (/) to avoid recursivity. ● You can end patterns with a forward slash (/) to specify a directory. ● You can negate a pattern by starting it with an exclamation point (!). Tip: https://github.com/github/gitignore

Git log ● git log / git log -p -2 (--patch) ● git log --stat ● git log --pretty=... ○ git log --pretty=oneline ○ git log --pretty=format:"%h - %an, %ar : %s" (more format) ○ git log --pretty=format:"%h %s" --graph ○ git log --since=2.weeks / “2 years 1 day 3 minutes ago” / “2018-01-15”/ --author / --grep ○ git log -S [functionName] ○ git log --oneline --graph --all

Undoing Things ● git commit --amend ○ Combine staged change to previous commit ○ Change commit message ● git reset HEAD <file> #Unstaging a Staged File ● git reset --hard # removes staged and working directory changes ○ git reset --hard 0254ea7 ● git checkout -- CONTRIBUTING.md ● git clean -f -d # remove untracked ● git clean -f -x -d # CAUTION: as above but removes ignored files like config. ● git clean -fxd :/ # CAUTION: as above, but cleans untracked and ignored files through the entire repo (without :/, the operation affects only the current directory) ● git revert #Instead of removing the commit from the project history ○ -n/--no-commit

Git Stash By default, running git stash will stash: ● changes that have been added to your index (staged changes) ● changes made to files that are currently tracked by Git (unstaged changes) But it will not stash: ● new files in your working copy that have not yet been staged ● files that have been ignored commands: ● git stash ● git stash pop/apply ● git stash -u/--include-untracked ● git stash -a/--all #ignore-files ● git stash list ● git stash save "some description" ● git stash pop stash@{2}

Git Stash ● git stash show -p ○ Stash this hunk [y,n,q,a,d,/,e,?]? N ● git stash branch <baranch_name> stash@{1} ● git stash drop stash@{1} ● git stash clear ● git blame -L 1,5 <fileName> Git Blame (more in UI tools)

Remotes ● git remote -v ● git remote add <name> <url> ● git fetch <remote> ● git remote show <remote> ● git remote rename <old> <new> ● git remote remove <remote>

Tagging ● git tag ● Types ○ Lightweight: like a branch that doesn’t change (It’s just a pointer to a specific commit) ■ git tag v1.4-lw ○ Annotated: They’re checksummed;contain the tagger name, email, and date; have a tagging message; and can be signed and verified with GNU Privacy Guard (GPG) encrypt and sign your data and communications ■ git tag -a v1.4 -m “my version 1.4” ● git show <tagname> ● git tag -a v1.2 9fceb02 ● git push origin <tagname> / git push origin --tags ● git checkout <tagname> ● git checkout -b <new_branch_name> <tagname>

Aliases ● git config --global alias.co checkout ● git config --global alias.br branch ● git config --global alias.ci commit ● git config --global alias.st status ● git config --global alias.unstage 'reset HEAD --' ● git config --global alias.last 'log -1 HEAD'

Branching and Merging (three-way merge) ● git checkout -b <branch_name> ● git branch <branch_name> -> git checkout <branch_name> ● git merge <branch_name> ○ git merge --no-ff #keep all of your commits from your feature branch ○ git merge --squash #combine your commits and clean up your repo ● git branch -d/-D <branch_name> ● git mergetool ● git branch -v / git branch --merged / git branch --no-merged / git branch -vv ● git ls-remote <remote> / git remote show <remote> ● git remote add <remote> <address>

Branching and Merging (three-way merge) ● git cherry-pick ● git checkout -b <branch_name> <remote>/<branch_name> (Tracking - upstream branch/ direct relationship to a remote branch) ● git checkout --track <remote>/<branch_name> ● git branch -u <remote>/<branch_name> or --set-upstream-to Note: “origin” is not special (git clone -o <name_replace_to_origin>)

● git push <remote> --delete <branch> ● git rebase ○ -i ○ -s #squash Branching and Merging (three-way merge)

● git push <remote> --delete <branch> ● git rebase ● git pull --rebase Branching and Merging (three-way merge)

Git Workflows What is a successful Git workflow? ● Does this workflow scale with team size? ● Is it easy to undo mistakes and errors with this workflow? ● Does this workflow impose any new unnecessary cognitive overhead to the team? And ● There is no one-size-fits-all Git workflow ● A workflow should be simple and enhance the productivity of your team ● Your business requirements should help shape your Git workflow

Centralized Workflow the Centralized Workflow uses a central repository to serve as the single point-of-entry for all changes to the project (A great Git workflow for teams transitioning from SVN) ● Central repositories should always be bare repositories (they shouldn’t have a working directory) ssh user@host git init --bare /path/to/repo.git ● git pull --rebase origin master ○ After conflict and fix it run: ■ git add <some-file> ■ git rebase --continue ○ Or ■ git rebase --abort

Feature branching ● Continuous Integration Environments ● Encapsulating feature

Gitflow Workflow ● managing larger projects ● for projects that have a scheduled release cycle ● Git-flow ○ git flow feature start feature_branch ○ git flow feature finish feature_branch ○ git flow release start 0.1.0 ○ git flow hotfix start hotfix_branch

Gitflow Workflow The overall flow of Gitflow is: 1. A develop branch is created from master 2. A release branch is created from develop 3. Feature branches are created from develop 4. When a feature is complete it is merged into the develop branch 5. When the release branch is done it is merged into develop and master 6. If an issue in master is detected a hotfix branch is created from master 7. Once the hotfix is complete it is merged to both develop and master

Forking Workflow ● most often seen in public open source projects ● contributions can be integrated without the need for everybody to push to a single central repository ● do not directly clone the official repository ● git remote add upstream https://bitbucket.org/maintainer/repo ● git pull upstream master

Forking Workflow 1. A developer 'forks' an 'official' server-side repository. This creates their own server-side copy. 2. The new server-side copy is cloned to their local system. 3. A Git remote path for the 'official' repository is added to the local clone. 4. A new local feature branch is created. 5. The developer makes changes on the new branch. 6. New commits are created for the changes. 7. The branch gets pushed to the developer's own server-side copy. 8. The developer opens a pull request from the new branch to the 'official' repository. 9. The pull request gets approved for merge and is merged into the original server-side repository

Branching Workflows Long-Running Branches Linear view

Branching Workflows Long-Running Branches Silo View

Branching Workflows Topic Branches (useful in projects of any size)

Thanks to everyone Resources: ● git-scm.com ● atlassian.com/git/tutorials

Git and git workflow best practice

More Related Content

What's hot

Similar to Git and git workflow best practice

Recently uploaded

Git and git workflow best practice

Editor's Notes