7 ms·

for about six months my git workflow was this: git add -A git commit -am "fixed some stuff" but I've finally found some time to start digging into how to rea

by n0us 11y ago

for about six months my git workflow was this: git add -A git commit -am "fixed some stuff" but I've finally found some time to start digging into how to really use it. The issue I have with it is that if you step outside the basics it's so easy to get yourself into a thorn bush and the way that git is explained most places is really not intuitive at all.

EvanPlaice 11y ago
Try using a tool like 'git cola' that allows you to selectively commit soecific lines, instead of just by file. Start a project and attempt to maintain a clean history. Break up changes logically into separate commits. To the point where 90%+ don't need more than the subject to describe a change and the history can be read like a story. Use 'gitk --all' to view the tree of changes. get comfortable with using feature branches, using interactive rebasing to clean up a messy history of changes, etc. The CLI works great for most things but visual tools make it much easier to write a clean history and reason about the changes over time.
- tuxracer 11y ago
  You can also commit specific lines using `git add -p`
  - pimlottc 11y ago
    Adding on to your helpful comment, you can also get a more concise, gitk-like graph of commits with `git log --graph`. This is my standard alias for viewing history, which also adds colors and tag/branch names: lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %C(magenta)(%cn)%Creset %Cgreen(%cr)%Creset' --abbrev-commit --date=relative --left-right
  - EvanPlaice 11y ago
    It's much easier when you can see all of the staged/unstaged files and drill down to staging/unstaging individual lines within those files. It also highlights whitespace nastiness (ie trailing spaces, missing newline at end of file, inconsistent newline chars, etc). The CLI is the ideal too for a lot of things. Preparing commits is not one of them.
    - icebraining 11y ago
      You can see all the files and drill down with "git add -i". Git also highlights whitespace problems.
      - pimlottc 11y ago
        I was excited when I first heard about git add iteractive mode but I find the interface to be quite unintuitive and idiosyncratic. I just stick to using "git add -p" to stage hunks selectively in a much more straightforward manner. Having said that, I stage all my commits on command line, and generally go to a GUI rarely for certain visualization tasks.
- brobinson 11y ago
  I use GitX (forked/updated version) so I can stage/commit line-by-line and see a nice branch/merge visualization: https://rowanj.github.io/gitx/ https://rowanj.github.io/gitx/
icelancer 11y ago
Ah yes, the "subversion" method of using git. ... I also do this. :|
- huuu 11y ago
  And I don't think it's an issue if you are using continuous delivery.
- zytek 11y ago
  Been there. You stop doing it when you start collaborating with others. It just doesn't work then. ;-)
- vlunkr 11y ago
  Also the method that gets logging, debuggers and temp files committed by accident.
  - ajross 11y ago
    Or authentication tokens. How many ssh keys or database passwords have been lost like this?
deleted 11y ago
[deleted]
the4dpatrick 11y ago
This is still my git workflow. Aside from the off times I have to rebase or revert a commit. I'm curious as what git commands you've found the most valuable or you've used the most since digging deeper into git.
- fla 11y ago
  For some time now, we use the rebase workflow. (create your branch, do some work, rebase on master, push). It is a great way to have a clean linear history. But it makes git pull 'illegal' because it does a merge implicitely. That's tipically something I didn't think about the first times I used git.
  - grayclhn 11y ago
    git pull --rebase doesn't merge implicitly and git config --global pull.rebase true will set that as the default `pull` behavior.
    - fla 11y ago
      Didn't know that. Thanks
    - gechr 11y ago
      Note that git config --global pull.rebase true was added in v1.7.9 - if you're using an earlier version of Git for whatever reason, the config you should be setting is git config --global branch.autosetuprebase always
  - brandmeyer 11y ago
    > It is a great way to have a clean linear history. Why is this considered by so many people to be a Good Thing? Engineering is an inherently messy human process, and the repository history should reflect what actually happened. To that end, I've been advocating a merge-based workflow instead: - The fundamental unit of code review is a branch. - Review feedback is incorporated as additional commits to the branch under review. - The verb used to commit to the trunk or other release series is 'merge --no-ff'. Under that model, merges are very common, particularly merges from the trunk to the feature being developed. But that's OK, because its what actually happened. When most people perform a 'rebase', they are actually performing a merge, while dropping the metadata for that merge.

by n0us 11y ago

EvanPlaice 11y ago

Try using a tool like 'git cola' that allows you to selectively commit soecific lines, instead of just by file. Start a project and attempt to maintain a clean history. Break up changes logically into separate commits. To the point where 90%+ don't need more than the subject to describe a change and the history can be read like a story. Use 'gitk --all' to view the tree of changes. get comfortable with using feature branches, using interactive rebasing to clean up a messy history of changes, etc. The CLI works great for most things but visual tools make it much easier to write a clean history and reason about the changes over time.

tuxracer 11y ago
You can also commit specific lines using `git add -p`
- pimlottc 11y ago
  Adding on to your helpful comment, you can also get a more concise, gitk-like graph of commits with `git log --graph`. This is my standard alias for viewing history, which also adds colors and tag/branch names: lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %C(magenta)(%cn)%Creset %Cgreen(%cr)%Creset' --abbrev-commit --date=relative --left-right
- EvanPlaice 11y ago
  It's much easier when you can see all of the staged/unstaged files and drill down to staging/unstaging individual lines within those files. It also highlights whitespace nastiness (ie trailing spaces, missing newline at end of file, inconsistent newline chars, etc). The CLI is the ideal too for a lot of things. Preparing commits is not one of them.
  - icebraining 11y ago
    You can see all the files and drill down with "git add -i". Git also highlights whitespace problems.
    - pimlottc 11y ago
      I was excited when I first heard about git add iteractive mode but I find the interface to be quite unintuitive and idiosyncratic. I just stick to using "git add -p" to stage hunks selectively in a much more straightforward manner. Having said that, I stage all my commits on command line, and generally go to a GUI rarely for certain visualization tasks.
brobinson 11y ago
I use GitX (forked/updated version) so I can stage/commit line-by-line and see a nice branch/merge visualization: https://rowanj.github.io/gitx/ https://rowanj.github.io/gitx/

icelancer 11y ago

Ah yes, the "subversion" method of using git. ... I also do this. :|

huuu 11y ago
And I don't think it's an issue if you are using continuous delivery.
zytek 11y ago
Been there. You stop doing it when you start collaborating with others. It just doesn't work then. ;-)
vlunkr 11y ago
Also the method that gets logging, debuggers and temp files committed by accident.
- ajross 11y ago
  Or authentication tokens. How many ssh keys or database passwords have been lost like this?

deleted 11y ago

[deleted]

the4dpatrick 11y ago

This is still my git workflow. Aside from the off times I have to rebase or revert a commit. I'm curious as what git commands you've found the most valuable or you've used the most since digging deeper into git.

fla 11y ago
For some time now, we use the rebase workflow. (create your branch, do some work, rebase on master, push). It is a great way to have a clean linear history. But it makes git pull 'illegal' because it does a merge implicitely. That's tipically something I didn't think about the first times I used git.
- grayclhn 11y ago
  git pull --rebase doesn't merge implicitly and git config --global pull.rebase true will set that as the default `pull` behavior.
  - fla 11y ago
    Didn't know that. Thanks
  - gechr 11y ago
    Note that git config --global pull.rebase true was added in v1.7.9 - if you're using an earlier version of Git for whatever reason, the config you should be setting is git config --global branch.autosetuprebase always
- brandmeyer 11y ago
  > It is a great way to have a clean linear history. Why is this considered by so many people to be a Good Thing? Engineering is an inherently messy human process, and the repository history should reflect what actually happened. To that end, I've been advocating a merge-based workflow instead: - The fundamental unit of code review is a branch. - Review feedback is incorporated as additional commits to the branch under review. - The verb used to commit to the trunk or other release series is 'merge --no-ff'. Under that model, merges are very common, particularly merges from the trunk to the feature being developed. But that's OK, because its what actually happened. When most people perform a 'rebase', they are actually performing a merge, while dropping the metadata for that merge.