4. .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
6. 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
7. 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}
8. 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)
10. 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>
17. ● git push <remote> --delete <branch>
● git rebase
○ -i
○ -s #squash
Branching and Merging (three-way merge)
18. ● git push <remote> --delete <branch>
● git rebase
● git pull --rebase
Branching and Merging (three-way merge)
19. 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
20. 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
23. 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
24. 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
25. 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
![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](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)