When you commit to git, then you push and get rejected:

$ git push
 To my_repo:~/my_project.git
  ! [rejected]        dev -> dev (fetch first)
 error: failed to push some refs to 'my_repo:~/my_project.git'
 hint: Updates were rejected because the remote contains work that you do
 hint: not have locally. This is usually caused by another repository pushing
 hint: to the same ref. You may want to first integrate the remote changes
 hint: (e.g., 'git pull ...') before pushing again.
 hint: See the 'Note about fast-forwards' in 'git push --help' for details.

To prevent merging with your local and making your git history filthy, reset head to the latest commit (head~1):

$ git reset HEAD~1
 Unstaged changes after reset:
 M   another_file_here.py
 M   some_file_here.py

Now git pull and the commit again and push. The world is cleaner now.

#git #reset_head #merge #repository

pip install from git repository:

pip install git+https://github.com/tangentlabs/django-oscar-paypal.git@issue/34/oscar-0.6

#git #repo #pip #install

clone is used in git to copy a project into your machine as a git project and do you works on it. Sometime a project (specially front projects) are so heavy and has lots of history which makes cloning to takes an hour or more (depending on the depth and the size of the repo).

The solution is --depth, with --depth you can specify how shallow a clone could be and how much commit of the past should be brought into your system. So for example you can clone like this:

git clone myhost:frontier/web.git --depth=1

It will copy the whole project BUT it just copies the last commit on the tip of the current branch in your server (most likely master) which is the default behaviour of git that set --single-branch. So if you checkout to dev you wont see your last changes
in dev branch. In case you want to shallow copy the whole project and retrieve the lat commit on the tip of all remote branches just use --no-single-branch.

So finally we can:

git clone myhost:frontier/web.git --depth=1 --no-single-branch

Now if you change your branch (checkout) to dev, you will see that recent changes of the dev branch on the remote repo server is present in your system.

to see the last commit ids that you have in your system, open YOUR_PROJECT/.git/shallow file and see the content of the file. Mine is as below:

8252b87c82b4be7b7b4edaa12f2168ff165fc7af #refers to my master last commit id
 d50bdeeecc595e86818c68d734613542206bf972 #refers to my dev last commit id

#git #branch #no-single-branch #single-branch #depth #clone

#ebook #epub #git

In normal git flow in case you have to checkout a file you would use:

git checkout -- your_file_name

In case you want to checkout multiple files you give other file names in front of checkout --. Sometimes there are bunch of modified files that you want to checkout all of them at once, so you need to go to the root of the project and:

git checkout -- .

It will checkout all files in your project.

You can also use:

git reset --hard

It will reset your working directory and replace all changes (including the index).

#git #checkout #reset #hard

How to work with stash in git?

Often, when you’ve been working on part of your project, things are in a messy state and you want to switch branches for a bit to work on something else. The problem is, you don’t want to do a commit of half-done work just so you can get back to this point later. The answer to this issue is the git stash command.

Stashing takes the dirty state of your working directory — that is, your modified tracked files and staged changes — and saves it on a stack of unfinished changes that you can reapply at any time.

Now you want to switch branches, but you don’t want to commit what you’ve been working on yet, to stash your modified files in your project use git stash:

$ git stash
 Saved working directory and index state \
   "WIP on master: 049d078 added the index file"
 HEAD is now at 049d078 added the index file
 (To restore them type "git stash apply")

Now your working directory should be clean:

$ git status
 # On branch master
 nothing to commit, working directory clean

To list all your stashes use git stash list:

$ git stash list
 stash@{0}: WIP on master: 049d078 added the index file
 stash@{1}: WIP on master: c264051 Revert "added file_size"
 stash@{2}: WIP on master: 21d80a5 added number to log

Now if you want to apply the most recent stashed files:

$ git stash apply
 # On branch master
 # Changes not staged for commit:
 #   (use "git add <file>..." to update what will be committed)
 #
 #      modified:   index.html
 #      modified:   lib/simplegit.rb

In order to remove a stash, use git stash drop YOUR_STASH:

$ git stash list
  stash@{0}: WIP on master: 049d078 added the index file
  stash@{1}: WIP on master: c264051 Revert "added file_size"
  stash@{2}: WIP on master: 21d80a5 added number to log
 $ git stash drop stash@{0}
  Dropped stash@{0} (364e91f3f268f0900bc3ee613f9f733e82aaed43)

These are some general, most useful commands to work with stash. Enjoy the article :)

#git #stash #stash_apply #stash_list #stash_drop #stash_save

Commit part of a file in git:

You can use git add --patch <filename> (or -p for short), and git will begin to break down your file into what it thinks are sensible hunks (portions of the file). It will then prompt you with this question:

Stage this hunk [y,n,q,a,d,/,j,J,g,s,e,?]?

Here is a description of each option:
y stage this hunk for the next commit
n do not stage this hunk for the next commit
q quit; do not stage this hunk or any of the remaining hunks
a stage this hunk and all later hunks in the file
d do not stage this hunk or any of the later hunks in the file
g select a hunk to go to
/ search for a hunk matching the given regex
j leave this hunk undecided, see next undecided hunk
J leave this hunk undecided, see next hunk
k leave this hunk undecided, see previous undecided hunk
K leave this hunk undecided, see previous hunk
s split the current hunk into smaller hunks
e manually edit the current hunk

#git #patch #commit #hunk #stage #git_add #git_add_patch

https://gist.github.com/pixelsonly/fabfa0245beccdf7d138

#git #zsh #oh_my_zsh #commands

Did you push a very large file into git? Does everyone yell at you about your commit and your uselessness? Are you a junky punky like me that just ruin things? Oh I'm kidding...

Because of that big file cloning the repo again would take a long long time. Removing the file locally and pushing again would not solve the problem as that big file is in Git's history.

If you want to remove the large file from your git history, so that when everyone clone the repo should not wait for that large file, just do as follow:

git filter-branch --tree-filter 'rm path/to/your/bigfile' HEAD

 git push origin master --force

I should note that you should be in the root of git repo.

If you need to do this, be sure to keep a copy of your repo around in case something goes wrong.

#git #clone #rm #remove #large_file #blob #rebase #filter_branch

I usually use linux copy command cp to copy files from my project into a production environment project. I copied wrong files by accident from a different repo into production environment and messed up the repo. Some files got into modified state, many untracked
files added into the project.

To revert all the C**P and make a clean slate of your project again, you just need to do 2 things:

1- git checkout .

2- git clean -f


First command will revert all modified files into their previous state. Second one will remove all untracked files.

Happy copying :)

#git #revert #checkout #clean #git_clean

If you have untracked directories not files then rather than using git clean -f use git clean -d. So if you want to clean both:

git clean -df

#git #clean #untrack