Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Understanding the Git Workflow

sandofsky.com

Post reply on HN
Print view View original

41–50 of 78 posts

Re: Understanding the Git Workflow

#41

Post by access_denied »

zwieback wrote: post #4

Nice post, thanks. I've been using traditional RCSs for years but find that whenever I introduce SVN (or CVS before that) to a team it's very easy for new users to fall into bad habits around branching and committing transitory changes. I'd like to try git to help manage the mess during the prototyping phase but I'm wondering how suitable it is for new users to learn git vs. learning svn. Any opions out there on the…

The main variable here is how smart you design your tutorials. Which cmds do you introduce at which reihenfolge?

Re: Understanding the Git Workflow

#43

Post by mark_story »

ulrich wrote: post #13
mooneater wrote: post #9

Earlier quoted context omitted.

they sound like smart people. why hobble them with svn in 2011? i put off the transition as long as i could out of inertia (switched from svn in 08 out of desperation when i started needing a lot of branch and merging). but once you go git, you dont look back, not one bit.

When you are used to the SVN/CVS workflow, it takes a long time to get over it. It took me a long time to understand why the distributed approach is better, despite having read a lot about them. In my company we are using git as well, but most developers refuse to work anywhere else than on master. They probably had their share of trouble with branching in other systems.

I found the thing that tipped the scales for people who were set in their ways was walking them through a merge and showing that tree conflicts don't exist. And that merging doesn't need to take more than 5 minutes.

I work on a codebase that changes pretty fast, and git has hugely reduced time wasted screwing around with tree conflicts and SVN losing its lunch.

Re: Understanding the Git Workflow

#44

Post by mark_story »

joelhaasnoot wrote: post #31

Hmm, this makes sense to me: lots of Git features I'd forgotten or not used before. Can anyone sketch my "merging" strategy I should be using in my scenario: - Have 3 branches dev, stage and master - Bugs are fixed on master, bigger bugs/changes on stage and new features on dev - Big functionality changes/additions come in the form of new branches, which currently I first merge with dev, then with stage and if everyt…

I would create feature branches for anything bigger than a few commits. Once the branch is done, you can merge it into dev, then merge that same branch into stage/master if you want.

Typically I would try to merge feature->dev->stage->master. With issues found on stage those could be put directly onto stage and merged into master. I guess it depends where you base new branches off of and where the 'stable code' is.

I usually aim to merge less stable (softer) branches into more stable (firmer) branches. And base all new feature branches off of the most firm branch I have.

Re: Understanding the Git Workflow

#46

Post by daemin »

alunny wrote: post #19

For very short, "oh there's a syntax error I missed" commits, "commit --amend" is very useful, and quicker than "rebase -i".

"git commit --amend" is very useful if you realise you forgot to include some files in the last commit.

Although if you committed since then you might be better off adding a new commit with the missing files and then doing a "git rebase -i" to move and squash the commits as appropriate.

Re: Understanding the Git Workflow

#47

Post by j-kidd »

jebblue wrote: post #42

Git is plain scary. We should stick with SVN.

Try http://hginit.com for a fantastic introduction to Mercurial for people familiar with SVN (or not).

Git was designed to suit kernel development (as shown in the article). For us simple-minded mortals who like SVN, it is much easier to migrate to Mercurial.

Re: Understanding the Git Workflow

#49

Post by pyre »

eropple wrote: post #12
pilif wrote: post #8

Earlier quoted context omitted.

I would never ever rewrite the public history. The public history is what ends up on the repository from where we deploy from. Whenever a commit is pushed there, it stays there. There will never be any rebasing (minus emergencies like removing accidentally committed files for which we don't own a license for - didn't happen so far though). "rebase -i" is a tool for personal development use. It's not a tool to use on…

IMO, that's really the wrong way to go, and it's one of the big reasons I absolutely loathe git. I want any changes that are in my tree, ever, to be in the order and position in which they happened. If somebody screwed up and forgot to add a file, fine--add it in another commit. It's not like commits cost money. As far as rolling back later--meh? I've never had a trouble in 300Krev heavily branched SVN barf, I strong…

  > I want any changes that are in my tree, ever,
  > to be in the order and position in which they
  > happened.
Could you explain this better. When I read this I hear, "I absolutely loathe modern operating systems, I think that all code should go in ~/code and all documents in ~/Documents, but modern operating systems allow you to put things anywhere. The horror!"

Do you really loathe the tool because it allows for flexibility? Do you have so little faith in the end-user? Do you really understand git, or only at a cursory level? (That isn't meant to be an insult)

  > indelible history is a good thing
So long as you have a central git repository and manage it so that no one can rewrite the master/trunk branch, then you have that. If someone screws up the history in their local tree, then it won't allow them to overwrite the history on the canonical version.

(If you say, "well someone with access to the canonical version could do X," then you're just trolling, because someone with access to the central SVN repo could 'rm -rf' it too. It's the same issue.)

Re: Understanding the Git Workflow

#50

Post by pyre »

westi wrote: post #30
eropple wrote: post #25

Earlier quoted context omitted.

I dunno, I think the claim that those commits "waste time" (in the sense of any meaningful amount of time, even cumulatively) is a little hyperbolic. I guess you view history differently than I do: I consider all development history to be "public history" regardless of whether it was pulled in from a clone or not. If you commit it to a repository I am going to be fulfilling a pull request from, I want the history the…

I completely agree with this. If a change was worth committing then it is worth sharing that commit with everyone. Otherwise you run the very real risk of loosing important information about the design of a feature the bugs that were found and addressed during development. Every change should been accompanied by a well described commit message and big changes are much harder to review. I can see a very small positive…

  > If a change was worth committing then it is worth
  > sharing that commit with everyone
You're misunderstanding some of the workflows that people are discussing. Sometimes I commit things that are half-finished, or even half-baked because I know that when it comes time to push I can rewrite things into a set of commits that makes sense.

This workflow makes sense because rewriting is easy enough. Obviously, I might not do this if I had to publish every commit that I made. But then I would just resort to using something like quilt to manage patches onto of SVN, which is ridiculous. You VCS is a patch management system. The idea that someone would use a patch management system on top of a patch management system suggests that something is broken (yes, I have had people on HN claim that git sucks because SVN + quilt 'work for me').

Post reply on HN