It’s tempting when starting to use git to clone a repository several times and work on different things in each. Only keep one copy of a repository per computer This matches the way that I like to work on things, as well – you can work on one idea until you’re stuck, then switch to something easier for a bit, etc. One of the things that I love about working with git is that it’s quite easy and natural to create a new branch for every idea you have, and just merge them into your master branch when you’re happy with them. In other version control systems branching and merging are awkward compared to git, and this means that people are often reluctant to create new branches. … which, if I recall correctly, was partly based on Tony Finch‘s. The example in the image uses: PS1=' \: " (%s)")\n ' git status won’t remind you of this (a bug, IMHO) but if it’s there in your bash prompt, it’s hard to ignore. It’s easy to abandon a rebase but forget to do git rebase –abort at the end. Another very nice feature about _git_ps1 is that it will remind you if you’re in the middle of a rebase. If you are not currently in a git repository, this evaluates to the empty string. You can use the $(_git_ps1 ” (%s)”) in your PS1 environment variable to include some useful information about your current branch in your bash prompt. It’s very easy to forget which branch you’re working on, particularly once you get used to switching your working tree to different branches with git checkout. (This suggests that you should create a branch that tracks the remote-tracking branch origin/fiji, and you’ll find the commit in the history for that branch.)
For example: $ git branch -a -contains 6f2293e7f6428 You might, however, want to do some work on the branch that commit is on.
Git list branches regular expression update#
For example, if you’re using submodules, then git submodule update will detach HEAD in each submodule in order to move it to the right commit. There are a lot of common situations where it’s useful to find out all the branches that a particular commit is on. If you want to find all the branches that one of those commits is on, see the next tip: Finding commits by SHA1sum In git version 1.74 and later you can use -G instead, which has more obvious semantics – it displays commits where the change introduced genuinely adds or removes a line that matches the given regular expression. Update and correction: note that “git log -S” doesn’t quite do what I said there: in fact it finds where there are different numbers of occurrences of the string in a file before and after that commit.
Git list branches regular expression Patch#
If you want to see the patch as well (which is often helpful) add -p to that command.
For example, suppose you know that “Factory” occurred as part of the class name that you’re looking for then git log -SFactory –all will list all commits in your repository (including remote-tracking branches) that mention “Factory” in the change they introduce. You can find it again simply with git log -S –all. Particularly if you are in the habit of creating lots of branches (as I suggest below) it is easy to forget where you introduced a particular bit of code. Finding text anywhere in your complete history It might take a while to get used to reading the graphic representation of what’s going on, but it very often explains why things aren’t working as you might expect.
The –all parameter is important so that you see all your local and remote-tracking branches.
Whenever you’re confused, use gitk –all to work out what’s going on. I owe thanks to Johannes Schindelin, who passed on at least three of these tips to me in the course of working on Fiji :) Update: this page was written when I was relatively new to git – some of the general remarks about the philosophy of git are better expressed in a short tutorial I wrote recently.
0 kommentar(er)
