1 Git:Care-free Committing
2 ========================
3 :author: Aaron Ball
4 :email: nullspoon@iohq.net
5
6
7 == {doctitle}
8
9 In the past, I have found myself a bit afraid to fully use git, because git
10 history is something so painful to rewrite, especially when the repo is shared
11 by other users. Besides, it just seems bad practice (and it is) to rewrite
12 history.
13
14 With true code, my concerns are a bit alleviated because most of the time you
15 can test that locally. The situation I'm referring to is using git as a
16 deployment mechanism for servers. Let me walk you through my old thought
17 process.
18
19 I want to try a new change for particular server type. I have two options. I
20 can just log into the server and try out my change, hoping the one that I
21 commit as a "copy-paste" later into the git repo works identically, or I can
22 make the change inside the git repo, push it upstream, triggering the test
23 deployment, which I can (and should) test with. However, what if the change
24 doesn't work? I can fix it sure, but I'll muck up the history with unecessary
25 "Broke it...fixed it" commits, and removing those will require rewriting
26 history.
27
28
29 == Branching
30
31 Git is well known for its "cheap branching". Because it makes it so easy to
32 rebase and merge onto any given branch.
33
34
35 == Squashing Commits
36
37 Firstly, find the first commit of your branch. We'll assume that this branch
38 came off of master and that we are currently working inside this branch (if
39 not, run +git checkout <branchname>+)
40
41 ----
42 git log master..HEAD
43 ----
44
45 That command will give you a list of all commits that have happened on your
46 feature branch ahead of the master branch. Assuming someone hasn't rewritten
47 history (which has happened to me before...ugh), you should be looking at only
48 your branch's commits. Scroll to the bottom and copy the commit id for the very
49 first commit in the series.
50
51 Now run...
52
53 ----
54 git rebase -i <commit_id>^1
55 ----
56
57 Don't forget the "carrot 1" (+^1+) at the end there, as it is very important.
58 We just told git to rebase the commit series on top of the most recent commit
59 from master (the "carrot 1" says "one commit before this commit", hence one
60 commit before your work started since you selected your first branch commit),
61 interractively. Iterractive mode gives us a chance to tell git how to handle
62 each commit, be it picking, squashing, editing, rewording, etc.
63
64 Running the interractive rebase should bring you into an editor with text that
65 looks something like...
66
67 ----
68 pick e57d408 Implemented new ifcfg profile functionality
69 pick cd476e8 Fixed minor issue
70 pick 96a112b Fixed another stupid issue
71 pick 9741e2c Testing a small change
72 pick ec32a51 Revert "Testing a small change"
73 pick 5d61d26 Revert "Fixed another stupid issue"
74 ...
75 ----
76
77 Here we can change what we want to do with each commit as the rebase proceeds.
78 In this case, I want to reduce my commit set down to one commit, the most
79 recent (note in your set, the most recent is on the bottom).
80
81 ----
82 pick e57d408 Implemented new ifcfg profile functionality
83 s cd476e8 Fixed minor issue
84 s 96a112b Fixed another stupid issue
85 s 9741e2c Testing a small change
86 s ec32a51 Revert "Testing a small change"
87 s 5d61d26 Revert "Fixed another stupid issue"
88 ...
89 ----
90
91 It doesnt matter what the commit messages are at this point. When the time
92 comes to merge the commits, you'll get a chance to rewrite the commit message.
93
94 Category:Git
95 Category:Drafts
96
97 // vim: set syntax=asciidoc:
|
