Here's my favorite git oneliner:<p><pre><code> git push origin --delete $(git branch --merged origin/master -r | grep -v master | grep origin | cut -d/ -f2-)
</code></pre>
It deletes all remote branches that are merged into the remote master. Because people always forget to click the "Delete branch" button after merging their pull requests.<p>EDIT: And another thing. Turn all your Git aliases into shell aliases (e.g. "git status" is aliased to "git st" is aliased to just "st" on my system) with this one weird trick! <a href="https://github.com/majewsky/devenv/blob/2c4252d37597617a493f1addadacfbf8d88b4942/toplevel/zshrc#L55-L59" rel="nofollow">https://github.com/majewsky/devenv/blob/2c4252d37597617a493f...</a>
Love #16 and the associated article. I cringe when I see something like "js fix" as a commit message.<p>However, not on board with the hate for rebase. If it's your feature branch and you aren't sharing it with others, I'd much rather get a cleaned up PR than one filled with junk commits because the author was afraid to rebase.
I'm an avid supporter of rebasing over merging. I'll refrain from getting into my workflow, but here's what i want to say: For the love of all that is holy, never squash a merge commit nor squash onto a merge commit.<p>Squashing a merge commit is a perfect way to reintroduce old code back into master.<p>Squashing onto a merge commit is great way to lose changes. It's been a while since I have tried this, but creating a didactic repo if fairly easy. Create a repo with two feature branches, a file on each of master and the feature branches, merge featureA to featureB, make some changes or delete a file, `commit --amend` on the merge, and merge featureB to master. Then use `git cat-file` to look at those commits and commit trees. I've seen mysterious things such as simple as unreported changes to files mysteriously being deleted from the repo.
I use git often on the command line, especially for non-trivial tasks, but do not quite understand why someone would pick it for routine committing/tree view over a GUI. I find the ability to graphically see the state of the working tree and the index, and being able to stage/unstage individual lines by visual selection in a non-linear way absolutely natural. Likewise, the ability to get a context menu for a commit in a tree view and fire a command (rebase/branch most often) seems like something git was "built" for.
Since interactive rebase was mentioned I'd recommend taking a look at its --autosquash flag and the --fixup flag of commit. With autosquash the interactive rebase will move fixup commits to where they belong:<p><pre><code> git commit --fixup=<commitref>
git rebase -i --autosquash HEAD~5</code></pre>
My recommendation: configure the shell prompt (add __git_ps1 to $PS1), this saves a ton of time and makes it much easier to understand what is going on. Especially recommended for beginners (but obviously not limited to).
For vimmers: <a href="https://github.com/tpope/vim-fugitive" rel="nofollow">https://github.com/tpope/vim-fugitive</a> is awesome, especially for only adding only parts of a file to a commit.
Site is non-responsive for me. Cached link:<p><a href="http://webcache.googleusercontent.com/search?q=cache:04x449vvRhkJ:www.alexkras.com/19-git-tips-for-everyday-use/&num=1&client=ubuntu&hl=en&gl=nl&strip=1&vwsrc=0" rel="nofollow">http://webcache.googleusercontent.com/search?q=cache:04x449v...</a>
I hope I'm not the only one who thinks that "Update README file" is a poor commit message. It's overly nondescript. A better commit message would be "Update README install instructions" or "Fix README links to dependencies" or anything else that better describes what about the README file was updated.
My #1 git tip to anyone who will listen: use magit. Having the options for each command within easy reach makes getting git to do the right thing so much easier, and the UI feels very emacs.<p><a href="https://github.com/magit/magit" rel="nofollow">https://github.com/magit/magit</a>
For git commit messages.
I've began liking to initiate or end a statement with stuff like these:<p>¯\_(ツ)_/¯<p>( ͡° ͜ʖ ͡°)<p>(ง'̀-'́)ง<p>(ノಠ益ಠ)ノ彡┻━┻<p>(ﾟ∀ﾟ)<p>ಠ_ಠ<p>How do you guys feel about these in git commit messages?
At my old job I had to do a major cleanup of a git repo with dozens of old branches. I got really good with the `git log` command. Here my alias form my ~/.gitconfig that shows author, branches, and remotes in a colorful manner:<p><pre><code> [alias]
ll = log --graph --oneline --decorate --date=short --all --pretty=format:'%ad %h %Cgreen%an %Cred%d %Creset%s'
</code></pre>
With this you have a pretty good picture of what's going on accross all branches.
Great set of tips. Unfortunately I find that so many post that suggest rebase recommend against force pushing. This takes a lot of the power away from rebase/amend. So much does this happen that is wrote a blog post titled "You should force push more"[0].<p>0: <a href="https://hugotunius.se/2014/09/08/you-should-force-push-more.html" rel="nofollow">https://hugotunius.se/2014/09/08/you-should-force-push-more....</a>
My favourite tip for commit messages: write them as if you would explain someone how to do what was done in the commit. So, instead of "fixed a bug" use "replace datetime object with date". It can be more abstract for larger commits (e.g. "refactor payments"), but it should be roughly analogue to what you would write to a ticket title to the same effect.
My must have: pre-commit unit tests. See <a href="http://daurnimator.com/post/134519891749/testing-pre-commit-with-git" rel="nofollow">http://daurnimator.com/post/134519891749/testing-pre-commit-...</a>
Talking of commit message styling, Antirez (of Redis fame) also has a say. <a href="http://antirez.com/news/90" rel="nofollow">http://antirez.com/news/90</a>
love this one :<p><pre><code> git diff --name-only | uniq | xargs $EDITOR
</code></pre>
(opens all modified files)<p>and this one to open files with conflicts<p><pre><code> git diff --name-only --diff-filter=U | uniq | xargs $EDITOR</code></pre>
I seriously must be doing something wrong, but when I'm doing an interactive rebase, if it stops due to a merge conflict I sometimes find I need to tweak other files, and to add the files to git I find I do the following:<p><pre><code> git add $(git diff --name-only)
</code></pre>
Am I wrong, or is this the right way of doing this?
I work with git daily for couple years and I find it quite tiring to follow git branches/commits in command line.<p>I rather use Git Extensions on windows and on mac Git Kraken. For beginners I think it would be better to use GUI tools.
I'm still not even quite sure how to a) discard edits that I've made but not added/committed yet and b) delete something from a repo that I added accidentally.
I'm collecting my personal notes/tips at: <a href="https://gingkoapp.com/git-notes" rel="nofollow">https://gingkoapp.com/git-notes</a>