Git partial commit of changes
Assume a single file gets a few changes related to different issues. We can easily just post git commit with a note to describe each change for each issue, push that, and remind ourselves not to do that again.
Depending on how complex the changes are, I use this pattern to give each change its own commit:
- Copy the finished working file to a new Final file.
- Revert the working file back to its last commit state.
- Diff the working file and the Final file, and hand-merge individual lines for an issue.
- Commit with a clean comment for a single issue.
- Repeat as required.
- Delete the Final file as it's now just a copy of the current working file.
Is there a better way to do this, other than "don't do that"? In short, I'm cherry-picking within a single file. But as any developer knows, changes can spread across multiple files, and sometimes it's difficult to avoid making a change right now when we're looking right at a line that needs to be changed, compared to flagging it and coming back later for a dedicated change/commit. Thanks.
git
asked Jan 11 at 17:21
TonyGTonyG
1237
add a comment |
Assume a single file gets a few changes related to different issues. We can easily just post git commit with a note to describe each change for each issue, push that, and remind ourselves not to do that again.
Depending on how complex the changes are, I use this pattern to give each change its own commit:
- Copy the finished working file to a new Final file.
- Revert the working file back to its last commit state.
- Diff the working file and the Final file, and hand-merge individual lines for an issue.
- Commit with a clean comment for a single issue.
- Repeat as required.
- Delete the Final file as it's now just a copy of the current working file.
Is there a better way to do this, other than "don't do that"? In short, I'm cherry-picking within a single file. But as any developer knows, changes can spread across multiple files, and sometimes it's difficult to avoid making a change right now when we're looking right at a line that needs to be changed, compared to flagging it and coming back later for a dedicated change/commit. Thanks.
git
asked Jan 11 at 17:21
TonyGTonyG
1237
Do you work with branches? The reality is this whole post makes my head throb and I use Git daily. If you are trying to note specific commit means something in a linear way, that defeats the purpose of Git. Read up on “git flow” and why branches are the best way you can use Git.
– JakeGould
Jan 11 at 17:47
add a comment |
Assume a single file gets a few changes related to different issues. We can easily just post git commit with a note to describe each change for each issue, push that, and remind ourselves not to do that again.
Depending on how complex the changes are, I use this pattern to give each change its own commit:
- Copy the finished working file to a new Final file.
- Revert the working file back to its last commit state.
- Diff the working file and the Final file, and hand-merge individual lines for an issue.
- Commit with a clean comment for a single issue.
- Repeat as required.
- Delete the Final file as it's now just a copy of the current working file.
Is there a better way to do this, other than "don't do that"? In short, I'm cherry-picking within a single file. But as any developer knows, changes can spread across multiple files, and sometimes it's difficult to avoid making a change right now when we're looking right at a line that needs to be changed, compared to flagging it and coming back later for a dedicated change/commit. Thanks.
git
asked Jan 11 at 17:21
TonyGTonyG
1237
Assume a single file gets a few changes related to different issues. We can easily just post git commit with a note to describe each change for each issue, push that, and remind ourselves not to do that again.
Depending on how complex the changes are, I use this pattern to give each change its own commit:
- Copy the finished working file to a new Final file.
- Revert the working file back to its last commit state.
- Diff the working file and the Final file, and hand-merge individual lines for an issue.
- Commit with a clean comment for a single issue.
- Repeat as required.
- Delete the Final file as it's now just a copy of the current working file.
Is there a better way to do this, other than "don't do that"? In short, I'm cherry-picking within a single file. But as any developer knows, changes can spread across multiple files, and sometimes it's difficult to avoid making a change right now when we're looking right at a line that needs to be changed, compared to flagging it and coming back later for a dedicated change/commit. Thanks.
git
git
asked Jan 11 at 17:21
TonyGTonyG
1237
asked Jan 11 at 17:21
TonyGTonyG
1237
asked Jan 11 at 17:21
TonyGTonyG
1237
asked Jan 11 at 17:21
TonyGTonyG
1237
asked Jan 11 at 17:21
TonyGTonyG
1237
1237
Do you work with branches? The reality is this whole post makes my head throb and I use Git daily. If you are trying to note specific commit means something in a linear way, that defeats the purpose of Git. Read up on “git flow” and why branches are the best way you can use Git.
– JakeGould
Jan 11 at 17:47
add a comment |
Do you work with branches? The reality is this whole post makes my head throb and I use Git daily. If you are trying to note specific commit means something in a linear way, that defeats the purpose of Git. Read up on “git flow” and why branches are the best way you can use Git.
– JakeGould
Jan 11 at 17:47
Do you work with branches? The reality is this whole post makes my head throb and I use Git daily. If you are trying to note specific commit means something in a linear way, that defeats the purpose of Git. Read up on “git flow” and why branches are the best way you can use Git.
– JakeGould
Jan 11 at 17:47
Do you work with branches? The reality is this whole post makes my head throb and I use Git daily. If you are trying to note specific commit means something in a linear way, that defeats the purpose of Git. Read up on “git flow” and why branches are the best way you can use Git.
– JakeGould
Jan 11 at 17:47
add a comment |
1 Answer
1
active
oldest
votes
Yes, that's basically the purpose of Git's "staging area". Commits do not actually store the working tree, but only changes that you've copied to the staging area. You've already used git add to stage individual files in preparation for a commit, but it also allows more fine-grained operations. See for example Chapter 7.2 in the Git Book.
The usual pattern is to use git add -p to select individual diff hunks, with the ability to edit them further (e.g. in case you have unrelated lines in the same hunk). There is also a corresponding git reset -p to unstage individual changes in case you've added too much.
Use git diff --cached to see what's staged. Finally just run git commit as usual.
(If you want a shortcut, git commit -p does everything in one step.)
You can also run git gui or git citool to get a graphical commit interface, which has the ability to select individual lines with a mouse (right-click to stage). It's also built in to most other graphical Git clients. However, these usually only work at whole-line level – if your file has unrelated changes within the same line, you'll still have to use git add -p and hand-edit the patch.
answered Jan 11 at 17:30
grawitygrawity
236k37498553
I do sometimes unstage some changes for one commit, then come back to stage others, essentially getting a few consecutive commits from one updated workspace. But you've provided exactly the kind of feedback I was looking for. I'll try your suggestion, report back here, and will check this as the answer if all goes well. Thanks.
– TonyG
Jan 11 at 21:50
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1393252%2fgit-partial-commit-of-changes%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Yes, that's basically the purpose of Git's "staging area". Commits do not actually store the working tree, but only changes that you've copied to the staging area. You've already used git add to stage individual files in preparation for a commit, but it also allows more fine-grained operations. See for example Chapter 7.2 in the Git Book.
The usual pattern is to use git add -p to select individual diff hunks, with the ability to edit them further (e.g. in case you have unrelated lines in the same hunk). There is also a corresponding git reset -p to unstage individual changes in case you've added too much.
Use git diff --cached to see what's staged. Finally just run git commit as usual.
(If you want a shortcut, git commit -p does everything in one step.)
You can also run git gui or git citool to get a graphical commit interface, which has the ability to select individual lines with a mouse (right-click to stage). It's also built in to most other graphical Git clients. However, these usually only work at whole-line level – if your file has unrelated changes within the same line, you'll still have to use git add -p and hand-edit the patch.
answered Jan 11 at 17:30
grawitygrawity
236k37498553
I do sometimes unstage some changes for one commit, then come back to stage others, essentially getting a few consecutive commits from one updated workspace. But you've provided exactly the kind of feedback I was looking for. I'll try your suggestion, report back here, and will check this as the answer if all goes well. Thanks.
– TonyG
Jan 11 at 21:50
add a comment |
Yes, that's basically the purpose of Git's "staging area". Commits do not actually store the working tree, but only changes that you've copied to the staging area. You've already used git add to stage individual files in preparation for a commit, but it also allows more fine-grained operations. See for example Chapter 7.2 in the Git Book.
The usual pattern is to use git add -p to select individual diff hunks, with the ability to edit them further (e.g. in case you have unrelated lines in the same hunk). There is also a corresponding git reset -p to unstage individual changes in case you've added too much.
Use git diff --cached to see what's staged. Finally just run git commit as usual.
(If you want a shortcut, git commit -p does everything in one step.)
You can also run git gui or git citool to get a graphical commit interface, which has the ability to select individual lines with a mouse (right-click to stage). It's also built in to most other graphical Git clients. However, these usually only work at whole-line level – if your file has unrelated changes within the same line, you'll still have to use git add -p and hand-edit the patch.
answered Jan 11 at 17:30
grawitygrawity
236k37498553
I do sometimes unstage some changes for one commit, then come back to stage others, essentially getting a few consecutive commits from one updated workspace. But you've provided exactly the kind of feedback I was looking for. I'll try your suggestion, report back here, and will check this as the answer if all goes well. Thanks.
– TonyG
Jan 11 at 21:50
add a comment |
Yes, that's basically the purpose of Git's "staging area". Commits do not actually store the working tree, but only changes that you've copied to the staging area. You've already used git add to stage individual files in preparation for a commit, but it also allows more fine-grained operations. See for example Chapter 7.2 in the Git Book.
The usual pattern is to use git add -p to select individual diff hunks, with the ability to edit them further (e.g. in case you have unrelated lines in the same hunk). There is also a corresponding git reset -p to unstage individual changes in case you've added too much.
Use git diff --cached to see what's staged. Finally just run git commit as usual.
(If you want a shortcut, git commit -p does everything in one step.)
You can also run git gui or git citool to get a graphical commit interface, which has the ability to select individual lines with a mouse (right-click to stage). It's also built in to most other graphical Git clients. However, these usually only work at whole-line level – if your file has unrelated changes within the same line, you'll still have to use git add -p and hand-edit the patch.
answered Jan 11 at 17:30
grawitygrawity
236k37498553
Yes, that's basically the purpose of Git's "staging area". Commits do not actually store the working tree, but only changes that you've copied to the staging area. You've already used git add to stage individual files in preparation for a commit, but it also allows more fine-grained operations. See for example Chapter 7.2 in the Git Book.
The usual pattern is to use git add -p to select individual diff hunks, with the ability to edit them further (e.g. in case you have unrelated lines in the same hunk). There is also a corresponding git reset -p to unstage individual changes in case you've added too much.
Use git diff --cached to see what's staged. Finally just run git commit as usual.
(If you want a shortcut, git commit -p does everything in one step.)
You can also run git gui or git citool to get a graphical commit interface, which has the ability to select individual lines with a mouse (right-click to stage). It's also built in to most other graphical Git clients. However, these usually only work at whole-line level – if your file has unrelated changes within the same line, you'll still have to use git add -p and hand-edit the patch.
answered Jan 11 at 17:30
grawitygrawity
236k37498553
edited Jan 11 at 17:36
answered Jan 11 at 17:30
grawitygrawity
236k37498553
answered Jan 11 at 17:30
grawitygrawity
236k37498553
answered Jan 11 at 17:30
grawitygrawity
236k37498553
236k37498553
I do sometimes unstage some changes for one commit, then come back to stage others, essentially getting a few consecutive commits from one updated workspace. But you've provided exactly the kind of feedback I was looking for. I'll try your suggestion, report back here, and will check this as the answer if all goes well. Thanks.
– TonyG
Jan 11 at 21:50
add a comment |
I do sometimes unstage some changes for one commit, then come back to stage others, essentially getting a few consecutive commits from one updated workspace. But you've provided exactly the kind of feedback I was looking for. I'll try your suggestion, report back here, and will check this as the answer if all goes well. Thanks.
– TonyG
Jan 11 at 21:50
I do sometimes unstage some changes for one commit, then come back to stage others, essentially getting a few consecutive commits from one updated workspace. But you've provided exactly the kind of feedback I was looking for. I'll try your suggestion, report back here, and will check this as the answer if all goes well. Thanks.
– TonyG
Jan 11 at 21:50
I do sometimes unstage some changes for one commit, then come back to stage others, essentially getting a few consecutive commits from one updated workspace. But you've provided exactly the kind of feedback I was looking for. I'll try your suggestion, report back here, and will check this as the answer if all goes well. Thanks.
– TonyG
Jan 11 at 21:50
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1393252%2fgit-partial-commit-of-changes%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Do you work with branches? The reality is this whole post makes my head throb and I use Git daily. If you are trying to note specific commit means something in a linear way, that defeats the purpose of Git. Read up on “git flow” and why branches are the best way you can use Git.
– JakeGould
Jan 11 at 17:47