#Git status staged code
So you move through the hunks of code with y and n, and if a hunk is too big, using s should be enough to then carry on with y and n.Īs you get used to these options, you could make things more efficient by experimenting with a, d and some of the others. The only other command that might come in useful is s, which is used to split a hunk down further. The two options that you should hone in on to start with are pretty obvious: S - split the current hunk into smaller hunksīut what if I told you that you only really need a couple of those options? Start with a couple and build from there K - leave this hunk undecided, see previous hunk K - leave this hunk undecided, see previous undecided hunk J - leave this hunk undecided, see next hunk J - leave this hunk undecided, see next undecided hunk search for a hunk matching the given regex Q - quit do not stage this hunk or any of the remaining onesĪ - stage this hunk and all later hunks in the fileĭ - do not stage this hunk or any of the later hunks in the file Things get even more dizzying if you type ? and hit Return: y - stage this hunk
#Git status staged Patch
This will then open up patch mode, which is a bit like when you’re diffing a file, but with just the first hunk of changed code in view, followed by a bunch of options, and this is where I’ve always given up: Stage this hunk ? You could use the more explicit -patch flag instead of -p, but I like to keep it brief. Or you could cycle through every changed file by leaving out the file name/path: git add -p To open up the patch mode, you need to first tell Git what file you want to have a look through: git add -p path/to/file.html That way I can over-code if I want to, then stage only specific chunks (or “hunks”) of what I’ve changed for one commit, leaving the rest for the subsequent commit(s).
#Git status staged how to
So in order to mitigate forgetfulness or disorder, I thought it was time to make a concerted effort to learn how to use patch mode. One false move and I’ve lost the ‘redo’ history. The first might actually be Git best practice, but it means I don’t always remember what I was going to do in the next commit by the time I get to it.
Only change the lines of code that belong to the commit I’m going to make.Instead, I found a couple of work arounds: I know git add has a -patch flag, and I’ve tried it once or twice, but every time I did, it felt a bit complicated and overwhelming, so I put it off. Since leaving Tower behind and moving to command line only for Git, I’ve missed that feature a lot. I used to love the way I could chunk down a commit with Tower by looking at a file that has changed and clicking the lines that I wanted to add to staging.
0 kommentar(er)
