The less you change it during the rename-commit, the better. That's because git doesn't actually store the fact that you renamed - it uses a heuristic based on how much the file has changed to guess whether it was the same file. I highly recommend committing a rename independently of any edits to the contents of the file. To rename a file (which is preferable to using another tool or the OS to rename), you can see git detecting the rename. WordRegex = _]+|_]+Ĭonsecutive strings of alphanumerics and underscoresĬonsecutive strings of non-alphanumerics, non-underscores, and non-spaces (good for detecting operators) Word-diff format because it more clearly shows where the differences are (inserts brackets around the changes in addition to using color).
However, I like customizing the meaning of a "word" using the Git has some ability to show "word" differences in a single line. That way when you examine the logs a long time later, it will make more sense what changed. If you find yourself writing long commit messages, break up the commit into smaller parts. For example, if a file was split, say so. Use descriptive messages when committing. I suggest using GitX (I prefer the "brotherbard" fork), which allows you to interactively discard hunks before committing. Note that you won't be able to tell git to skip the space changes when committing. There's also options to show differences within a line. Or at least the committer should know exactly what changed.įlag to ignore spaces. The one who commits changes should be the same person who modifies the files. It's sounding like you need more control and standardization of the development process. This is safe, since we manually resolved the rebase (via merge) already. The "-Xtheirs" says to always prefer their changes, but "ours" and "theirs" are flipped in a rebase, so that means to always prefer ours. If this is a multiple-commit change you're working with, you may want/need to move the psuedo-merge change to a different point in the history before you squash it, to properly simulate the rebase. We could have combined this with the previous step, but actually committing the pseudo-merge gives us a commit to reset to in case something goes wrong later. Git commit -a -m "Pseudo-merge from master"Īnd "fixup" the last change into your original one. We're going to convince git that this is a regular commit, not a merge. Git merge master -Xignore-all-space -no-commit , and your working branch forked from it somewhere down the line. I'm also assuming the branch to rebase onto is This should work in a multi-commit situation, it just (again) will be more ugly. For the sake of simplicity, I am assuming that everything is in a single commit in the current branch.
0 kommentar(er)
