--local, --global, --system

git config --local user.email <email>

git config --global user.name <name>

git config --global alias.<alias> <command>

git config --system core.editor "<editor> -w"

git config --local user.email "jgmarques@kpmg.com"

git config --global user.name "jgmarques"

git config --global alias.ci commit

 

git config --global alias.amend git ci --amend

git config --system core.editor "atom -w"

• command used to create new repositories

 

• creates a .git directory

 

• creates the master branch

 

• needs a remote to be configured manually so that changes can be pushed to a server

• command used to obtain an existing repository locally

 

• copies the latest version of the remote repo files on the default branch (which is usually the master)

 

• the files will be placed in a folder with the same name as the repo

 

• the full remote repo history is copied

• adds a file or directory to the staging area

 

• does not affect the repository until you execute a commit

 

• allows to group a set of changes that are meant to be commited together before actually modifying the repository

• commits the staging area to the project history

 

• git does not change a commit after it is performed

 

• commits provide a checkpoint that can be accessed later

 

• commits are local, so you can accumulate them before pushing

 

• git does not store differences. it stores the entire file content in each commit

• temporarily hides changes, so that you can change branch and work on something else, and then return and apply them

 

• good when you need to quicky change context but are in the middle of development and not yet ready to commit

 

• you can apply stashed changes to as many branches as you want

 

• new files and ignored files are not stashed by default

• all files are one of three things: tracked, untracked or ignored

 

• ignored files are usually build artifacts or machine generated files

 

• to mark a file as ignored, add it to the .gitignore file

 

• there can be many .gitignore files in the project. git will look for the closest .gitignore file recursively

• lists which files are staged, unstaged and untracked

 

• good practice to check the status before a commit

• displays committed snapshots. allows you to list, filter and search the project history. you can combine multiple options at once

git log -n <limit>

git log --oneline

git log --author="<pattern>"

 

git log --grep="<pattern>"

git log <since>..<until>

• can be used to check out files, commits, or branches

 

• checking out a commit allows you to see a previous version of the entire project

 

• checking out a file allows you to see a previous version of that file, leaving the rest of the working tree untouched

git checkout <branch>

git checkout <commit>

git checkout <commit> <file>

• undoes a commited snapshot

 

• does not remove the commit from the project history. Instead, creates a new one that undoes all the changes

 

• should only be used when the intention is to revert an entire commit. Otherwise, use checkout

• "dangerous" method of undoing changes

 

• removes commits from the project history

 

• can be used to reset a single file, to reset the staging area, or the current branch

 

• never reset code that has been pushed to the server. it is intended to be a way of cleaning up local code only

• removes untracked files from the working directory

 

• accepts a path to limit the action scope

 

• can be executed as a dry run

 

• usually handy for cleaning the directory before a build

• git allows you to rewrite history

 

• this has the potential of losing commits

 

• can be dangerous if not used properly

• convenient way of adding to the recently created commit instead of creating a new one

 

• can also be used to edit the last commit message

 

• never amend public commits

• process of moving a branch to a new base commit

 

• takes all commits, and applies them on a new base, creating a new history. this results in new commits.

 

• used to keep the project history linear instead of keeping all the merges that have happened

 

• never rebase public history

• interactive rebase

 

• allows to determine how each commit should be applied to the new base

 

• used so that a series of commits seem more logical to who is reading them

• allows to create, view and delete connections to repositories

 

• when a repo is cloned, a remote is created pointing to the original repo

 

• when a local repo is created, you need to manually add a remote so that you can interact with it

• imports commits from a remote repository into the local repo

 

• it is possible to fetch all branches or a particular branch

 

• the result is not merged. it is stored in remote branches until you want to merge them

 

• remote branches can be seen as read only branches

• fetches the specified remote content, and immediately merges with the local copy

 

• git pull <remote> is the same as git fetch <remote> followed by git merge <remote name>/<current branch>

 

• accepts a --rebase option to do a rebase instead of a merge

• the way of sending commits from the local repo to the remote repo

 

• creates a local branch in the remote repository

 

• git will not accept the push if it will result in overwriting commits

• branches represent a line of independent development.

 

• under the hood, it is just a "named commit", where the name will point to a different commits over time

 

• creating a branch always results in a fork in the project history

• allows to create, list, rename or delete branches

 

• does not allow to checkout branches

git branch 
git branch <branch>
git branch -d <branch>
git branch -D <branch>
git branch -m <branch>

• allows to navigate between branches

 

• checking out branches is saved in the project history (not read only)

 

• you can work on multiple features by switching between branches

git checkout <existing branch>

git checkout -b <new branch>

• allows to take two branches and integrate them into a single branch

 

• always merges the target merge into the current branch

 

• if git cannot figure out how to merge two files, a merge conflict appears.

 

• after conflict resolution, you need to run git add to stage the file(s) and git commit to create the merge commit

• master always represents production code
• develop always represents ready-to-deploy code
• all branches should be prefixed with their category (feature, release, bugfix, hotfix)
• hotfixes represent fixes that need to go to production asap, while bugfixes represent fixes that can be merged into develop and follow the normal flow
• release branches are always created from develop, and then merged both into master and develop
• every merge into master should be tagged
• branches like feature/DEV-BRANCH are not acceptable

• never leave the commit message empty

 

• commits should represent a set of functionalities, and the message should reflect that

 

• breaking changes should always be put in the commit message

 

• always use the imperative, present tense to describe the changes. it makes reading the project history a lot easier

• IDE for using GIT

 

• allows to perform all the operations with a visual interface

 

• a lot goes on under the hood

Q: How to discard local file modifications?

A: git checkout -- <filename>

Q: How to undo the last 2 commits?

A1: git reset HEAD~2                    (undoes and keeps changes)

A2: git reset --hard HEAD ~2    (undoes and discards changes)

Q: How to unstage a file?

A: git reset <filename>

Q: How to edit a commit message?

A: git commit --amend -m "<new message>"

Q: How to revert a commit that has already been pushed to the server?

A1: git revert <commit id>

A2: git revert <commit id 1>..<commit id 2> (reverts a range)

Q: How to undo the last commit only locally?

A: git revert -n HEAD

Q: How do I find the commit that broke the code?

A: git bisect

Q: How to revert a commit that has already been pushed to the server?

A1: git revert <commit id>

A2: git revert <commit id 1>..<commit id 2> (reverts a range)

Q: How do I know what my last actions were, accross all branches?

A: git reflog

Q: I just committed something to master that should have been in a new branch. Now what?

 

# First, create the branch that you should have been working on

git branch <branch>

# Then, reset master to the previous state, removing the last commit

git reset HEAD~ --hard

# Finally, switch to the new branch, where your commit will be

git checkout <branch>

Q: I just committed something to the wrong branch. Now what?

 

# First, undo the last commit, keeping the changes

git reset HEAD~ --soft

git stash

# Change to the correct branch

git checkout <other branch>

# Apply the changes to this branch

git stash pop

git add <whatever you want to stage>

got commit -m "<commit message>

Q: I have no idea what's going on with my repo. Nothing works. Now what?

A: Delete the repository, and clone it again :)