5 ms·

Here are the commands I use: git init git clone git checkout git commit git commit -m git commit —amend git rebase git add/rm/diff [—cached] git push

Here are the commands I use: git init git clone git checkout git commit git commit -m git commit —amend git rebase git add/rm/diff [—cached] git push git branch and a few more I can’t remember exactly. I try to keep my git workflow simple. The most complex is probably checkout abd rebase with several different branches.

emj 9y ago
You are already using ammend and rebase, you can do plenty of complex and hairy stuff with that, especially as a team. I'm also guessing you use merge and log at times. FWIW this is my philosphy with git too, but have you not experienced the points he brings up? I was nodding my head at all of them; branches are time-consuming, staging is problematic and forks are a bad analogy. The recent post and hype about the Facebook, Google and Microsoft monorepos should make us ask the question what our systems for source control is supposed to do really. save changes to a source code save changes to big binary assets annotate those changes annotate the files themselves tagging versions signing of code code review handle regressions testing collaborating (ACL, DCVS, official monkey patching etc) merging search on the whole code base refactoring on large code bases All these things have uses but they are not really supposed to be tied to one VCS, we have very basic needs when working with source code streamlining the UX for that workflow might be more important and in the same time opening up for easy access to the other stuff.
saltedmd5 9y ago
"I try to keep my git workflow simple," and yet I see 'git rebase' but no 'git merge' in that list.
- zegl 9y ago
  `rebase` is simpler than `merge` in larger teams/projects, as the history will be much cleaner.
  - saltedmd5 9y ago
    Rebase is not simpler in any context - rebase rewrites history, which, if branches have been pushed to remotes, then necessitates force pushes, which in turn breaks any other instances of the same branch. By using rebase to "keep history clean" you are largely undermining git's power as a DVCS. Rebase as a tool is not inherently bad but it is definitely not simpler than merge - it introduces additional considerations, requires a deeper understanding of git for effective use and is a dangerous tool in the hands of people who do not understand what it is doing and in my experience most teams that are using it as a core part of their workflow are doing so for the wrong reasons (generally because of a fundamental misunderstanding of how branching and merging works in git and why it works that way).
    - muxator 9y ago
      mercurial has "phases", which means that it allows free rebasibg and history rewriting for changes that are still not public. As soon as a tree is pushes, those changes become public, and you need to explicitly force the history rewriting operations. This is part of the " safe defaults" approach of mercurial.
    - yeukhon 9y ago
      Simple or not, it's a subjective. As you said it: > > it introduces additional considerations, requires a deeper understanding of git for effective use and is a dangerous tool in the hands of people who do not understand what it is doing I am taught git with rebase (though merge when I use hg) so I am already too used to it. Branching then rebase is not that difficult if you keep your workflow consistent and quick iteration. You should be up to date whenever possible. Amending and rewriting history/comment also requires using rebase. YMMV.
    - kazinator 9y ago
      That is not correct; rebase per se doesn't rewrite history. Rebase is basically just cherry picks. You can rewind a branch and then cherry-pick, so that the picks are non-fastforward. That's rewriting history. Cherry picking without rolling back is fastforward, and so doesn't rewrite history. The Gerrit review system on top of Git is based on cherry-picking; it doesn't rewrite history. If some developers are collaborating on a feature which is on a branch, they could agree from time to time to rebase that branch to a newer mainline. Whether or not that is done by a history rewrite simply hinges on whether the same branch name is used for the rebased branch or not. The rebase is what it is: if you plant that rewrite as the original branch name, then you have a non-fastforward change. If a new branch name is made, then it isn't a rewrite. Merging a feature branch onto a trunk can always be done in a fastforward way using rebase/cherry-pick. Rebasing is provably simpler than merge. Merge depends on complications in the git object representation which could be removed while rebase remains what it is. If you only ever rebase, you never see a commit with multiple parents; the feature is superfluous and turns git histories into hairballs.
majewsky 9y ago
> I try to keep my git workflow simple. > git rebase Yeah... :)
- tarnacious_ 9y ago
  I often rebase my local commits on a remote branch to keep my branch up to date with changes in the remote branch. I find this simpler and cleaner than introducing a series of merge commits in my local branch.
  - kazinator 9y ago
    I believe a fork of git should be made which entirely eliminates the concept of multiple parents from the representation of a commit. In the same breath, it would drop support for git merge and git log --graph.
  - kazinator 9y ago
    A merge should always be done by rebasing the to-be-merged material onto the target-of-merge branch. This way not only is the history linear (and thus understandable, rather than some indecipherable "git log --graph" ball of yarn) but the individual changes are properly re-worked to fit into the target. When we go back and view those changes, they are all in terms of this codebase, not the original changes that do not apply cleanly to this codebase. That's a big problem with git merges: the merge itself is one huge jump that collapses all the changes. The original changes are traceable in its lineage through the second parent, but those are the verbatim original changes, not the merged changes.
cryptonector 9y ago
I especially use: - git add -e - git rebase -i --autostash <upstream> - git checkout -f -- <file> (to undo changes) - git diff/log (of course) - git reset HEAD^ (to undo the head commit but leave its changes extant in the workspace so I can then git add -e and commit them in logical units)

emj 9y ago

You are already using ammend and rebase, you can do plenty of complex and hairy stuff with that, especially as a team. I'm also guessing you use merge and log at times. FWIW this is my philosphy with git too, but have you not experienced the points he brings up? I was nodding my head at all of them; branches are time-consuming, staging is problematic and forks are a bad analogy. The recent post and hype about the Facebook, Google and Microsoft monorepos should make us ask the question what our systems for source control is supposed to do really. save changes to a source code save changes to big binary assets annotate those changes annotate the files themselves tagging versions signing of code code review handle regressions testing collaborating (ACL, DCVS, official monkey patching etc) merging search on the whole code base refactoring on large code bases All these things have uses but they are not really supposed to be tied to one VCS, we have very basic needs when working with source code streamlining the UX for that workflow might be more important and in the same time opening up for easy access to the other stuff.

saltedmd5 9y ago

"I try to keep my git workflow simple," and yet I see 'git rebase' but no 'git merge' in that list.

zegl 9y ago
`rebase` is simpler than `merge` in larger teams/projects, as the history will be much cleaner.
- saltedmd5 9y ago
  Rebase is not simpler in any context - rebase rewrites history, which, if branches have been pushed to remotes, then necessitates force pushes, which in turn breaks any other instances of the same branch. By using rebase to "keep history clean" you are largely undermining git's power as a DVCS. Rebase as a tool is not inherently bad but it is definitely not simpler than merge - it introduces additional considerations, requires a deeper understanding of git for effective use and is a dangerous tool in the hands of people who do not understand what it is doing and in my experience most teams that are using it as a core part of their workflow are doing so for the wrong reasons (generally because of a fundamental misunderstanding of how branching and merging works in git and why it works that way).
  - muxator 9y ago
    mercurial has "phases", which means that it allows free rebasibg and history rewriting for changes that are still not public. As soon as a tree is pushes, those changes become public, and you need to explicitly force the history rewriting operations. This is part of the " safe defaults" approach of mercurial.
  - yeukhon 9y ago
    Simple or not, it's a subjective. As you said it: > > it introduces additional considerations, requires a deeper understanding of git for effective use and is a dangerous tool in the hands of people who do not understand what it is doing I am taught git with rebase (though merge when I use hg) so I am already too used to it. Branching then rebase is not that difficult if you keep your workflow consistent and quick iteration. You should be up to date whenever possible. Amending and rewriting history/comment also requires using rebase. YMMV.
  - kazinator 9y ago
    That is not correct; rebase per se doesn't rewrite history. Rebase is basically just cherry picks. You can rewind a branch and then cherry-pick, so that the picks are non-fastforward. That's rewriting history. Cherry picking without rolling back is fastforward, and so doesn't rewrite history. The Gerrit review system on top of Git is based on cherry-picking; it doesn't rewrite history. If some developers are collaborating on a feature which is on a branch, they could agree from time to time to rebase that branch to a newer mainline. Whether or not that is done by a history rewrite simply hinges on whether the same branch name is used for the rebased branch or not. The rebase is what it is: if you plant that rewrite as the original branch name, then you have a non-fastforward change. If a new branch name is made, then it isn't a rewrite. Merging a feature branch onto a trunk can always be done in a fastforward way using rebase/cherry-pick. Rebasing is provably simpler than merge. Merge depends on complications in the git object representation which could be removed while rebase remains what it is. If you only ever rebase, you never see a commit with multiple parents; the feature is superfluous and turns git histories into hairballs.

majewsky 9y ago

> I try to keep my git workflow simple. > git rebase Yeah... :)

tarnacious_ 9y ago
I often rebase my local commits on a remote branch to keep my branch up to date with changes in the remote branch. I find this simpler and cleaner than introducing a series of merge commits in my local branch.
- kazinator 9y ago
  I believe a fork of git should be made which entirely eliminates the concept of multiple parents from the representation of a commit. In the same breath, it would drop support for git merge and git log --graph.
- kazinator 9y ago
  A merge should always be done by rebasing the to-be-merged material onto the target-of-merge branch. This way not only is the history linear (and thus understandable, rather than some indecipherable "git log --graph" ball of yarn) but the individual changes are properly re-worked to fit into the target. When we go back and view those changes, they are all in terms of this codebase, not the original changes that do not apply cleanly to this codebase. That's a big problem with git merges: the merge itself is one huge jump that collapses all the changes. The original changes are traceable in its lineage through the second parent, but those are the verbatim original changes, not the merged changes.

cryptonector 9y ago

I especially use: - git add -e - git rebase -i --autostash <upstream> - git checkout -f -- <file> (to undo changes) - git diff/log (of course) - git reset HEAD^ (to undo the head commit but leave its changes extant in the workspace so I can then git add -e and commit them in logical units)