I'd prefer a GUI where I can see the changes and the context surrounding those changes rather than the changes in a terminal. This does seem useful when SSH'd into a server though. Thanks for buffing my ssh+git repertoire.
You can also do it from the gutter. Click the colored git indicator and it brings up the inline diff view which has a + button to staged just that diff.
^(Hi, I'm a bot for linking direct images of albums with only 1 image)
**https://i.imgur.com/GJ5yPH3.png**
^^[Source](https://github.com/AUTplayed/imguralbumbot) ^^| ^^[Why?](https://github.com/AUTplayed/imguralbumbot/blob/master/README.md) ^^| ^^[Creator](https://np.reddit.com/user/AUTplayed/) ^^| ^^[ignoreme](https://np.reddit.com/message/compose/?to=imguralbumbot&subject=ignoreme&message=ignoreme)^^| ^^[deletthis](https://np.reddit.com/message/compose/?to=imguralbumbot&subject=delet%20this&message=delet%20this%20erhimhc)
Committing certain lines is something I do as part of my git workflow using SourceTree. I'll generally do it because I'm coding to accomplish a task but that task is made up of sub-tasks.
If I know exactly what path I'll be taking to accomplish the task, I'll usually:
1. Make a branch for the task/feature/issue/whatever...
2. Make a skeleton of functions I'm likely to use
3. Make a starting commit for the task in my branch
4. Start coding and testing the functions that make up a sub-task.
5. When I'm happy with the subtask, commit the changes for that subtask.
6. *repeat for all subtasks*
7. When all subtasks are complete, do any tidy-up, make a final commit and merge+push/push+pull-request branch.
If I'm not sure exactly what path I need to take, or think I might come across a better one mid-development, I'll usually:
1. Follow steps 1-3 above.
2. Start coding and testing the functions for a few inter-related sub-tasks.
3. When I'm happy for how the implementation of those sub-tasks ended up I'll commit the changes across multiple commits (one for each subtask) by staging only the lines related for the sub-task's commit.
This advantages of this are:
* Avoids filling the branch's history with implementations of sub-tasks that were made independent of each-other and are good by themselves but bad in the context of the whole task in general (e.g. confusing method signatures, variable names across functions that seem related but aren't, etc...).
* Preventing useless commits to the git project and having to revert/branch off my branch to fix.
* Avoids monster commits with everything in a larger task completed in one go.
* Making the git history of my branch easier to comprehend, it's much easier to make a readable git history after-the-fact.
Doing this method is going to be counter productive if you're working on tasks too small or large.
To group commits. For example you changed the readme file while also doing some other changes and just want to commit saying that you updated the readme file. instead of one giant commit with all changes.
That's not just committing a few lines in one file. Those are separate files and if you don't want them lumped in one commit, you just need to stage the readme file. It's different.
>so do it from the gutter. Click the colored git indicator and it brings up the inline diff view which has a + button to staged just that diff.
I do it all the time, sort of as an alternative to having more branches. Still not "used" to the git way, and using git-tfs makes it easier to keep things in a linear history. So I will add my own local hacks, and then only commit what I know is good.
We are doing SiL stuff so we need to be very careful with what we check in.
Yes, there a command called "Stage selected range" or "stage selected lines". I can't remember which. I have it bound to Ctrl+shift+=.
Interesting, I might have to test vscode as my daily driver for git... Thanks
If you want to up your git-game learn git add —patch
For me it's the only right way to commit things, makes you able to review what you're about to commit and avoid committing things you don't want to
I'd prefer a GUI where I can see the changes and the context surrounding those changes rather than the changes in a terminal. This does seem useful when SSH'd into a server though. Thanks for buffing my ssh+git repertoire.
Yeah I just meant it’s impressive to know if it ever comes up during interviews and things. Patch and bisect are great things to flex with
You can also do it from the gutter. Click the colored git indicator and it brings up the inline diff view which has a + button to staged just that diff.
Yup. I even posted a screenshot when someone asked about this ~4 days ago. - https://imgur.com/a/nbLuqTO
^(Hi, I'm a bot for linking direct images of albums with only 1 image) **https://i.imgur.com/GJ5yPH3.png** ^^[Source](https://github.com/AUTplayed/imguralbumbot) ^^| ^^[Why?](https://github.com/AUTplayed/imguralbumbot/blob/master/README.md) ^^| ^^[Creator](https://np.reddit.com/user/AUTplayed/) ^^| ^^[ignoreme](https://np.reddit.com/message/compose/?to=imguralbumbot&subject=ignoreme&message=ignoreme)^^| ^^[deletthis](https://np.reddit.com/message/compose/?to=imguralbumbot&subject=delet%20this&message=delet%20this%20erhimhc)
Good bot.
^thanks ^^[Source](https://github.com/AUTplayed/imguralbumbot) ^^| ^^[Why?](https://github.com/AUTplayed/imguralbumbot/blob/master/README.md) ^^| ^^[Creator](https://np.reddit.com/user/AUTplayed/) ^^| ^^[ignoreme](https://np.reddit.com/message/compose/?to=imguralbumbot&subject=ignoreme&message=ignoreme)
Nice, I'll test this out
Yes, select the line you want to commit, then right click, then stage selected ranges.
In what sort of cases would committing only specific lines be useful? I might need it someday so I might as well ask.
Committing certain lines is something I do as part of my git workflow using SourceTree. I'll generally do it because I'm coding to accomplish a task but that task is made up of sub-tasks. If I know exactly what path I'll be taking to accomplish the task, I'll usually: 1. Make a branch for the task/feature/issue/whatever... 2. Make a skeleton of functions I'm likely to use 3. Make a starting commit for the task in my branch 4. Start coding and testing the functions that make up a sub-task. 5. When I'm happy with the subtask, commit the changes for that subtask. 6. *repeat for all subtasks* 7. When all subtasks are complete, do any tidy-up, make a final commit and merge+push/push+pull-request branch. If I'm not sure exactly what path I need to take, or think I might come across a better one mid-development, I'll usually: 1. Follow steps 1-3 above. 2. Start coding and testing the functions for a few inter-related sub-tasks. 3. When I'm happy for how the implementation of those sub-tasks ended up I'll commit the changes across multiple commits (one for each subtask) by staging only the lines related for the sub-task's commit. This advantages of this are: * Avoids filling the branch's history with implementations of sub-tasks that were made independent of each-other and are good by themselves but bad in the context of the whole task in general (e.g. confusing method signatures, variable names across functions that seem related but aren't, etc...). * Preventing useless commits to the git project and having to revert/branch off my branch to fix. * Avoids monster commits with everything in a larger task completed in one go. * Making the git history of my branch easier to comprehend, it's much easier to make a readable git history after-the-fact. Doing this method is going to be counter productive if you're working on tasks too small or large.
Great explanation. Thanks.
Man... gratz but I'm too lazy to do that :D I just push the files I edited when I finish my feature on my branch.. Easy and simple
Thanks for this explanation!
To group commits. For example you changed the readme file while also doing some other changes and just want to commit saying that you updated the readme file. instead of one giant commit with all changes.
That's not just committing a few lines in one file. Those are separate files and if you don't want them lumped in one commit, you just need to stage the readme file. It's different.
Oh you're right, i misread the title of the post. I thought he meant specific files not lines.
>so do it from the gutter. Click the colored git indicator and it brings up the inline diff view which has a + button to staged just that diff. I do it all the time, sort of as an alternative to having more branches. Still not "used" to the git way, and using git-tfs makes it easier to keep things in a linear history. So I will add my own local hacks, and then only commit what I know is good. We are doing SiL stuff so we need to be very careful with what we check in.