git - goatandsheep/goatandsheep.github.com GitHub Wiki

Cloning

git clone https://github.com/angular/angular-phonecat.git

Light-cloning: Choose the size of your clone with --depth=<number of commits>

git clone --depth=5 https://github.com/angular/angular-phonecat.git

Clone to server with self-signed certificate: git config http.sslVerify "false"

Cleaning your local workspace

  1. git reset --hard
  2. git clean -f -d

Branching

Switch to existing branch

  1. Commit & Push / Clean working directory. It's better to branch before you start making changes. I'm not sure about how to do it if you want to push a local commit to a new branch.
  2. Update and switch to working directory to match branch: git checkout <existing-branch>

Switch to new branch

  1. Commit & Push / Clean working directory. It's better to branch before you start making changes. I'm not sure about how to do it if you want to push a local commit to a new branch.
  2. Create and switch to new branch: git checkout -b <branch_name>
  3. Push branch to server: git push --set-upstream origin <branch_name>

Deleting a branch

After merging

  1. Merge your changes
  2. Push deletion to remote: git push origin -d <branch_name> (git push origin --delete <branch_name>)
  3. git branch -d <branch_name>

Otherwise

  1. Clean your local workspace
  2. Push forced deletion to remote: git push origin -D <branch_name> (git push origin --delete --force <branch_name>)
  3. git branch -D <branch_name>

Clearing branches

When you have branches with squashed merges, prune doesn't always delete locally.

Powershell:

git branch -vv | Select-String -Pattern ": gone]" | % { $_.toString().Trim().Split(" ")[0]} | % {git branch -D $_}

Merging Changes from another branch

A tip for merging is to use origin/branchB instead of branchB because be default it tries to merge the local copy of the branch, which may not have been updated. Alternatively, pull the most recent changes to branchB before merging.

Keep your changes

git merge -X ours branchB

Update your code with new changes

git merge -X theirs branchB

Merging from another repo

  1. Add the other repo as a remote: git remote add <nickname for secondary remote, use a single word> <remote location>, e.g. for merging https://github.com/bob/by into your local https://github.com/rob/by, git remote add bob https://github.com/bob/by.
  2. git remote update
  3. Checkout into <new-remote>/<branch> and pull
  4. Checkout into local <branch>
  5. git merge /`
  6. Fix conflicts and push!

Processes

Hot fix

1. Cherry pick

Test merging a commit locally before committing to it

  1. git cherry-pick <commit hash>
  2. See / fix merge conflicts
  3. Test
  4. To revert marge: git reset --hard
  5. Else commit, push

If cherry-pick doesn't work, step 2

2. Hotfix branch

  1. Create hotfix branch from production code
  2. Manually re-create fix in the production code without applying the new dev version

Undoing a test

When you try something but it doesn't quite work out, but you learn stuff on the way, it may be useful to keep that code.

  1. Commit code
  2. Revert commit: git revert <commit hex>
  3. Commit message (I usually just leave it how it is). :q for the vim noobs.
  4. Push

Pulling all subdirectories

for d in *; do pushd $d && git pull && popd; done

Stash

If you've made some changes but need to go to a different branch briefly before you're ready to commit you can use git stash

Initial saving:

git stash

List saved stashes:

git stash list

Revert to first stash in list:

git stash apply

Reverting to saved stash:

git stash apply <number>

Editing in the wrong branch

  1. git stash
  2. git checkout correct-branch
  3. git stash pop

Branching strategies

Merge

Easy, but relies on multiple histories of code.

  1. After changes are ready, merge current state of master into the feature branch: git pull git merge origin master
  2. Resolve conflicts
  3. Push changes: git commit -m "merges+conflicts" git push
  4. Create pull request

This creates an additional commit for the merge itself.

Rebase

A trickier strategy uses rebase to make for cleaner progression because it ensures a linear code history. Rebase to change the course of time to make your current code changes happen after the current changes in master. It can be tricky to use when you have already pushed some of the changes to remote.

  1. git checkout branch
  2. git rebase master
  3. git push -f origin branch

Or if you look at the history, you can get the commit hash and do:

  1. git checkout <branch>
  2. git rebase -i <hash>
  3. git push -f origin branch

When you get to the interactive rebase screen, change the pick to squash for the commits you are trying to squash.

⚠️ **GitHub.com Fallback** ⚠️