8 ms·

Maybe my workflow is a lot easier than others, but I work on a team of 10+ engineers and my Git usage is dead simple. I do everything from a GUI (Fork for macOS

Maybe my workflow is a lot easier than others, but I work on a team of 10+ engineers and my Git usage is dead simple. I do everything from a GUI (Fork for macOS) and very rarely have to deal with any complicated issues that require a terminal. - Always pull w/ rebase for the current branch. - Always merge other branches into your current branch, eg master -> feature. - Always stage individual chunks of code one at a time to make sure I'm committing the right stuff. - Always squash feature branches into a single commit when merging back. - Stash changes if needed when switching branches. - Cherry-pick one-off commits if needed. - Append a previous commit that I haven't pushed yet if I happened to forget something. - For complicated merge conflicts I switch to Visual Studio Code which also has a great GUI. I think this covers 99% of the stuff I encounter in my day-to-day.

ssully 7y ago
I am in a similar boat, except I just Githubs desktop client. In the past 4 years, I think I have had to use the command line under 10 times.
- doubleunplussed 7y ago
  Am I missing something, or is it impossible to, y'know, check out a previous revision using github desktop? Create a branch at a previous revision? Reset the branch to some previous commit? Any of these things? It seems to have next to zero functionality. What is the point of it? What you you use it for, other than commit, push?
  - iamsb 7y ago
    You can do most of the things you have mentioned using atlassians desktop client https://www.sourcetreeapp.com/ https://www.sourcetreeapp.com/
    - doubleunplussed 7y ago
      I know that, I'm just wondering what the point of GitHub Desktop is. I use Sublime Merge, but no Git GUI I've used comes close to tortoisehg for mercurial. Tortoisehg is actually superior to and a comprehensive replacement for the command line. I wish something like it existed for git, if not for me then for the newbie-ish people I need to instruct on project workflows.
5trokerac3 7y ago
In my experience, if you ever use more than clone, fetch, pull, push, checkout, merge(tool), reset, add, and commit then somebody messed up.
- CameronNemo 7y ago
  I rebase all the time FWIW.
  - sixstringtheory 7y ago
    I constantly use git commit --fixup 6138D3A git rebase --autosquash --interactive origin/master to keep a clean history of cohesive commits. Rarely do I change _everything_ required for an objective in one go, I still like to commit as I work, I just like the finished product to _seem_ like I did it in one go, for future maintainers' sake. And I rebase to catch up with upstream, I can't stand having intermediate merge commits in my history and rebasing lets you resolve conflicts as they're introduced, instead of an all-at-once at the end.
    - rane 7y ago
      You might find this git alias useful. Wrote it a few years ago and find it useful daily. [alias] fix = "!_() { c=$(git rev-parse $1) && git commit --fixup $c && if grep -qv \"No local changes\" <<<$(git stash); then s=1; fi; git -c core.editor=cat rebase -i --autosquash $c~; if [[ -n "$s" ]]; then git stash pop; fi; }; _" The workflow becomes: $ git add ... # stage the changes you want to apply to 6138d3a $ git fix 6138d3a
      - sixstringtheory 7y ago
        Wow, I always love when a git/shell elder comes along and shows me something like this. I didn't know about `git -c` before, I'm assuming it's setting per-command config values? I've also not used/seen `!_()` before... I'm assuming it's introducing something like an anonymous function and calling it at the end... but why not just break out the body of the function and execute it directly in the alias? Does it help with error propagation? Thank you!
marcosdumay 7y ago
Nearly every time that I google a git command, it's something related to tags.
danpalmer 7y ago
I agree. Almost every time I hear of someone having issues unpicking a complicated git issue it's because they were trying to be too smart with it and use every feature just because they are there. Find a _simple_ git workflow, document it in a style guide, stick to it. Git doesn't have to be complicated.
whycombagator 7y ago
kdiff3 for merge conflicts is nice (I think)
arcticbull 7y ago
I agree with basically everything you wrote except I’ve had much better experience rebasing my feature onto origin/master instead of merging master into feature. Keeps the [branch] history cleaner.
- dmlittle 7y ago
  Same thing here. If I'm working on a feature that I haven't pushed up yet I might squash my commits together for a cleaner history (it also helps with rebasing). If you ever mess up a rebase and finish it before you're able to abort you can use `git reflog` to get a reference back to the previous commit. It's come super handy a few times.
- trevor-e 7y ago
  I think what I said should be equivalent to what you do. When I merge my feature back to origin/master I do `git merge --squash myFeatureBranch` which automatically rebases everything and keeps a clean history. This is really the only command I do by hand because I can't find the equivalent (yet, probably haven't looked hard enough) in Fork. edit: oh I think I misread what you said. When working on a feature branch I don't care too much about the branch history since I know it's eventually being squashed back into a single commit.
  - joombaga 7y ago
    Isn't this (or at least the end state) the same as rebasing myFeatureBranch from master before merging it in? I don't use Fork, but I assume it can do those 2 things with clicks.
- johnisgood 7y ago
  I hate merges. "Merged ... into ..." is such an uninformative message! Some codebases are filled with those. I prefer seeing each individual commit messages, so... rebasing all the way for me! One problem I have with this is that the committer date of all commits become identical instead of retaining their original date aligned with the author date (which I would like to be the committer date). Is there a way to workaround this or fix it in a "non-dirty" way? It might be the case that I am doing something wrong, if so, what am I doing wrong exactly, or how should I go about it?
pjmlp 7y ago
Same here but from Visual Studio, Eclipse and Tortoise GIT, while missing Subversion and Mercurial.
mav3rick 7y ago
I will never understand why people use a UI for git. 99% of the time people who do that don't understand how git works. When something deviates from the normal workflow they struggle.
- SQueeeeeL 7y ago
  Never understand? I mostly use Git CLI, and it's a big pain. Weird terminology, needing to memorize branch names for easy use, differences between staged and pushed commits. And when you mess your incantation you ripped from SO up you get errors with strange terminology. I understand it's benefits and use it, but older simpler versioning systems like SVN had their own benefits.
  - pizza234 7y ago
    While there are definitely UX problems, the following aren't: - needing to memorize branch names for easy use: there is tab completion for this; - differences between staged and pushed commits: I'm not sure what you refer here. the closest concept to the "stage" term is "staged changes". this is by design; the idea is that while one applies changes within a single commit, some are definitive, some are evolving; for this workflow, it's very convenient. if one doesn't want, they can just add all and commit (preferrably, with a single alias ;-)). The "most extensive" Git UX problem is possibly the excess of functionality given to the `checkout` command, which in fact is being split. (I don't imply that Git UX is good, though)
- dmix 7y ago
  It's only an alternative interface... not much different pushing a button you don't understand than copy/pasting some commands.
- trevor-e 7y ago
  I think that's just your own personal bias on the matter – 99%, really? To me (IMO), Git is something that's inherently visual and not really suited to a CLI, it has nothing to do with not understanding how Git works under the hood.
gregmac 7y ago
Totally agree with everything on this list, with two exceptions: * I almost always just do a regular merge to master (rather than squash). * I use GitKraken which (in the pro version) has a great merge tool. A lot of people seem to want "clean history" so just I'd just like to put it out there that it's not really necessary (there's nothing wrong with it, of course), and regular merges work just fine. In my experience, the two main reasons I look at git history are: (1) Checking when a feature was done and what releases it got into (2) Finding out why a particular line of code exists (blame) For (1), with software with numbered releases, you end up following the branches anyway. Having the individual commits from feature branches makes you scroll more, but it doesn't make it any harder to follow. If you really don't like seeing them, you can hide anything but merge commits. Even simpler, if all you care about is whether a given feature branch is done (merged) or not, that's easy to see and the same as a squash-merge workflow. With continuously-deployed ("cloud") services, things are even simpler - you start at the hash currently deployed and go backwards. It makes no difference if there's one branch or many feature branches (other than scrolling past more granularity). For (2), the greater granularity from individual commits is generally useful (at least provided that each commit has a ticket number and useful description), and squashing erases this detail. Also, a nice thing is if you end up merging the same branch to multiple places (master and a release branch, for example) it's obvious what happened by looking at the tree. Contrast to if you cherry pick a squash merge commit, the only way to see that is to read both commits and realize they're the same -- and this is much less obvious if there's other commits between them. Basically, squash merging doesn't help with either of these, and in fact actively hinders (2). My team has been doing this for a few years, and I'm not even sure if it was a conscious decision to merge this way (or not do squash merge) but we've had no reason to change. It does depend on every commit being well-formed, but this is pretty easy to ensure in a paid team that works on this every day (whereas with open source I'm not sure it'd work well). Anyway, like many things in git, there's more than one way to do it, and there's no clear "right" or "wrong" way.
Groxx 7y ago
This likely works because a) you know what you're doing (cherry-pick), and b) you're being careful (staging carefully). Anything works when both of those prerequisites are met. You're unlikely to do the bad things that force more advanced needs. Everyone should do this. Think back to how much time you've lost due to git problems. It'd probably take less time to learn it correctly up-front, and never have to deal with them ever again.
wilg 7y ago
I am similar but avoid rebasing entirely in favor of squashing. Squashing can also be used to turn a messy branch into a new branch full of nice clean independent commits. I also don't bother appending (though my GUI lets me undo the last commit if I haven't pushed which is maybe the same thing.) Most developers get way too fancy with Git and screw something up. I use GitHub Desktop and rarely touch the command line for Git. It has a great UI for being able to just pop over and see my current changes, and easily commit just a line or two from them to make commits other people can understand.
qmmmur 7y ago
Why do you always rebase? Is your master essentially the stable branch of the program you are collaborating on?

ssully 7y ago

I am in a similar boat, except I just Githubs desktop client. In the past 4 years, I think I have had to use the command line under 10 times.

doubleunplussed 7y ago
Am I missing something, or is it impossible to, y'know, check out a previous revision using github desktop? Create a branch at a previous revision? Reset the branch to some previous commit? Any of these things? It seems to have next to zero functionality. What is the point of it? What you you use it for, other than commit, push?
- iamsb 7y ago
  You can do most of the things you have mentioned using atlassians desktop client https://www.sourcetreeapp.com/ https://www.sourcetreeapp.com/
  - doubleunplussed 7y ago
    I know that, I'm just wondering what the point of GitHub Desktop is. I use Sublime Merge, but no Git GUI I've used comes close to tortoisehg for mercurial. Tortoisehg is actually superior to and a comprehensive replacement for the command line. I wish something like it existed for git, if not for me then for the newbie-ish people I need to instruct on project workflows.

5trokerac3 7y ago

In my experience, if you ever use more than clone, fetch, pull, push, checkout, merge(tool), reset, add, and commit then somebody messed up.

CameronNemo 7y ago
I rebase all the time FWIW.
- sixstringtheory 7y ago
  I constantly use git commit --fixup 6138D3A git rebase --autosquash --interactive origin/master to keep a clean history of cohesive commits. Rarely do I change _everything_ required for an objective in one go, I still like to commit as I work, I just like the finished product to _seem_ like I did it in one go, for future maintainers' sake. And I rebase to catch up with upstream, I can't stand having intermediate merge commits in my history and rebasing lets you resolve conflicts as they're introduced, instead of an all-at-once at the end.
  - rane 7y ago
    You might find this git alias useful. Wrote it a few years ago and find it useful daily. [alias] fix = "!_() { c=$(git rev-parse $1) && git commit --fixup $c && if grep -qv \"No local changes\" <<<$(git stash); then s=1; fi; git -c core.editor=cat rebase -i --autosquash $c~; if [[ -n "$s" ]]; then git stash pop; fi; }; _" The workflow becomes: $ git add ... # stage the changes you want to apply to 6138d3a $ git fix 6138d3a
    - sixstringtheory 7y ago
      Wow, I always love when a git/shell elder comes along and shows me something like this. I didn't know about `git -c` before, I'm assuming it's setting per-command config values? I've also not used/seen `!_()` before... I'm assuming it's introducing something like an anonymous function and calling it at the end... but why not just break out the body of the function and execute it directly in the alias? Does it help with error propagation? Thank you!

marcosdumay 7y ago

Nearly every time that I google a git command, it's something related to tags.

danpalmer 7y ago

I agree. Almost every time I hear of someone having issues unpicking a complicated git issue it's because they were trying to be too smart with it and use every feature just because they are there. Find a _simple_ git workflow, document it in a style guide, stick to it. Git doesn't have to be complicated.

whycombagator 7y ago

kdiff3 for merge conflicts is nice (I think)

arcticbull 7y ago

I agree with basically everything you wrote except I’ve had much better experience rebasing my feature onto origin/master instead of merging master into feature. Keeps the [branch] history cleaner.

dmlittle 7y ago
Same thing here. If I'm working on a feature that I haven't pushed up yet I might squash my commits together for a cleaner history (it also helps with rebasing). If you ever mess up a rebase and finish it before you're able to abort you can use `git reflog` to get a reference back to the previous commit. It's come super handy a few times.
trevor-e 7y ago
I think what I said should be equivalent to what you do. When I merge my feature back to origin/master I do `git merge --squash myFeatureBranch` which automatically rebases everything and keeps a clean history. This is really the only command I do by hand because I can't find the equivalent (yet, probably haven't looked hard enough) in Fork. edit: oh I think I misread what you said. When working on a feature branch I don't care too much about the branch history since I know it's eventually being squashed back into a single commit.
- joombaga 7y ago
  Isn't this (or at least the end state) the same as rebasing myFeatureBranch from master before merging it in? I don't use Fork, but I assume it can do those 2 things with clicks.
johnisgood 7y ago
I hate merges. "Merged ... into ..." is such an uninformative message! Some codebases are filled with those. I prefer seeing each individual commit messages, so... rebasing all the way for me! One problem I have with this is that the committer date of all commits become identical instead of retaining their original date aligned with the author date (which I would like to be the committer date). Is there a way to workaround this or fix it in a "non-dirty" way? It might be the case that I am doing something wrong, if so, what am I doing wrong exactly, or how should I go about it?

pjmlp 7y ago

Same here but from Visual Studio, Eclipse and Tortoise GIT, while missing Subversion and Mercurial.

mav3rick 7y ago

I will never understand why people use a UI for git. 99% of the time people who do that don't understand how git works. When something deviates from the normal workflow they struggle.

SQueeeeeL 7y ago
Never understand? I mostly use Git CLI, and it's a big pain. Weird terminology, needing to memorize branch names for easy use, differences between staged and pushed commits. And when you mess your incantation you ripped from SO up you get errors with strange terminology. I understand it's benefits and use it, but older simpler versioning systems like SVN had their own benefits.
- pizza234 7y ago
  While there are definitely UX problems, the following aren't: - needing to memorize branch names for easy use: there is tab completion for this; - differences between staged and pushed commits: I'm not sure what you refer here. the closest concept to the "stage" term is "staged changes". this is by design; the idea is that while one applies changes within a single commit, some are definitive, some are evolving; for this workflow, it's very convenient. if one doesn't want, they can just add all and commit (preferrably, with a single alias ;-)). The "most extensive" Git UX problem is possibly the excess of functionality given to the `checkout` command, which in fact is being split. (I don't imply that Git UX is good, though)
dmix 7y ago
It's only an alternative interface... not much different pushing a button you don't understand than copy/pasting some commands.
trevor-e 7y ago
I think that's just your own personal bias on the matter – 99%, really? To me (IMO), Git is something that's inherently visual and not really suited to a CLI, it has nothing to do with not understanding how Git works under the hood.

gregmac 7y ago

Totally agree with everything on this list, with two exceptions: * I almost always just do a regular merge to master (rather than squash). * I use GitKraken which (in the pro version) has a great merge tool. A lot of people seem to want "clean history" so just I'd just like to put it out there that it's not really necessary (there's nothing wrong with it, of course), and regular merges work just fine. In my experience, the two main reasons I look at git history are: (1) Checking when a feature was done and what releases it got into (2) Finding out why a particular line of code exists (blame) For (1), with software with numbered releases, you end up following the branches anyway. Having the individual commits from feature branches makes you scroll more, but it doesn't make it any harder to follow. If you really don't like seeing them, you can hide anything but merge commits. Even simpler, if all you care about is whether a given feature branch is done (merged) or not, that's easy to see and the same as a squash-merge workflow. With continuously-deployed ("cloud") services, things are even simpler - you start at the hash currently deployed and go backwards. It makes no difference if there's one branch or many feature branches (other than scrolling past more granularity). For (2), the greater granularity from individual commits is generally useful (at least provided that each commit has a ticket number and useful description), and squashing erases this detail. Also, a nice thing is if you end up merging the same branch to multiple places (master and a release branch, for example) it's obvious what happened by looking at the tree. Contrast to if you cherry pick a squash merge commit, the only way to see that is to read both commits and realize they're the same -- and this is much less obvious if there's other commits between them. Basically, squash merging doesn't help with either of these, and in fact actively hinders (2). My team has been doing this for a few years, and I'm not even sure if it was a conscious decision to merge this way (or not do squash merge) but we've had no reason to change. It does depend on every commit being well-formed, but this is pretty easy to ensure in a paid team that works on this every day (whereas with open source I'm not sure it'd work well). Anyway, like many things in git, there's more than one way to do it, and there's no clear "right" or "wrong" way.

Groxx 7y ago

This likely works because a) you know what you're doing (cherry-pick), and b) you're being careful (staging carefully). Anything works when both of those prerequisites are met. You're unlikely to do the bad things that force more advanced needs. Everyone should do this. Think back to how much time you've lost due to git problems. It'd probably take less time to learn it correctly up-front, and never have to deal with them ever again.

wilg 7y ago

I am similar but avoid rebasing entirely in favor of squashing. Squashing can also be used to turn a messy branch into a new branch full of nice clean independent commits. I also don't bother appending (though my GUI lets me undo the last commit if I haven't pushed which is maybe the same thing.) Most developers get way too fancy with Git and screw something up. I use GitHub Desktop and rarely touch the command line for Git. It has a great UI for being able to just pop over and see my current changes, and easily commit just a line or two from them to make commits other people can understand.

qmmmur 7y ago

Why do you always rebase? Is your master essentially the stable branch of the program you are collaborating on?