Daily Git

There were already articles about the fundamentals of the gita ( 0 , 1 , 2 ), there were also articles about the internal structure of the repository. Today we'll talk about how a mere mortal to work with git on autopilot and not fool yourself.

Firstly, shortcuts (in descending order of popularity):

alias gst = 'git-status'
alias ga = 'git-add'
alias gc = 'git-commit -m'
alias gp = 'git pull && git push'
alias gull = 'git pull'
alias gush = 'git push'
alias gb = 'git-branch'
alias gco = 'git-checkout'
alias gd = 'git-diff'
')
Second, display the current branch on the command line:

export PS1 = '`__git_ps1"% s "` \ w \ $'

Looks like that:

lazy-args-in-futures ~ / Work / io / oleganza-io.git $

(How to install: ericgoodwin.com/2008/4/10/auto-completion-with-git )

Typical work flow in one thread


1) Something pee, drove tests
2) $ gst - you saw which files are new, which are updated.
3) $ ga abc - added new and updated files to the index.
4) $ gc 'something is done' - recorded a commit in the repository
5) They wrote something again, again commited.
6) $ gp - merged other people's changes, filled in their changes. If a conflict suddenly arises, they will write to you about this, you will be merjit.

To just pull up updates, type $ gull (git pull).

Local branches

Principle: one feature - one branch. One bugfix (if it is supposed longer than two kommit) - one branch. One experiment - one branch. One feature inside the experiment is a branch from a branch. Well, you get the idea.

Why is it needed? Imagine that you started the day with feature A, but they approached you and said that you need to fix B. And five minutes later it turned out that in order to fix B in a human way, you need to fasten and check C. If each of these tasks keep in separate branches, then the head will not go round, and the work will not rise across the throat.

We collect:
master ~ / project $ gco -b my-feature

We get:
my-feature ~ / project $

List of all branches: $ gb
Switch to another branch: $ gco some-branch

Do not forget that you can always add some thread to the current branch with the help of git merge other-branch.

Life situations with branches

1) Bug fix / adding features. Make a branch, test everything, add the master to it: gull && git merge master, test again, exit the master (gco master), add the branch (git merge my-branch), test, fill in the master (gush) and delete the branch (gb -D my-branch).

2) Publishing a collaboration thread: gush origin my-branch: refs / heads / my-branch
Deleting a branch: gush origin: refs / heads / my-branch (attention to the space before the colon)

3) You are sitting in one branch and have done something that you would like to commit to another branch. If you have not yet committed, then do git reset HEAD for already added files (via ga / git-add), then git-stash, exit to the correct branch, do git-stash apply and then act as if we are right here all and changed.

4) You made a commit to some experimental branch, which makes sense to upload to the master, but git merge my-branch is not suitable, because after this commit there were a few more experimental commits.

In this case, there is git-cherry-pick. First, look at git-log and copy the number of the desired commit. Further, you must commit all changes in the branch into which you will throw the pulled commit. Then, do git-cherry-pick and resolve conflicts, if any.
I had such a situation with the addition of a commit to the master, so after these surgical procedures I had to add the master to the local branch. Since cherry-pick only applies diff (the commit number becomes different), the branch does not know that it has already made the change, and cannot merge it normally. Therefore, with the master wizard in the branch, you are guaranteed to get stupid conflicts a la "ABC line conflicts with ABC."
If someone knows how to avoid conflicts in this situation (and save 5 minutes of time), share your experience.

Boring moralizing at last

1) commits should be small. The five-screen diff should be the exception, not the rule.
2) At first, do not fool yourself with the rebase and "clean" line of commits. This worries only the latest aesthetes or Linus (who has a dozen branches per day). Reading the git-log and ignoring the commonplace merge commits is no problem.
3) Read git-log after pull, scold your colleagues for unintelligible descriptions of commits.
4) Examine .git / config :-)

Next time you need to write a few words about comfortable work with git-submodule and git-svn.