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

1–10 of 78 posts

Re: Understanding the Git Workflow

#3

Post by pilif »

The minute I learned about "rebase -i" and "add -p" has changed how I think about commits. I learned how I could easily keep the history clean and conversely, I learned the huge value that a clean history has for maintenance.

Now, building the commits as self-contained entities that don't break the build in between not only helps me while searching bugs later on, it sometimes helps me detect code smells around unneeded dependencies.

That said, I still like to merge big features with --no-ff if they change a lot of code and evolved over a long time, as that, again, helps keeping history clean because a reader can clearly distinguish code before the big change from code after the big change.

Of course the individual commits in the branch are still clean and readable, but the explicit merge still helps if you look at the history after some time.

"you said 'a long time in development' - surely the merge target has changed in between. Why still -no-ff?" you might ask.

The reason, again, is clean history: before merging I usually rebase on top of the merge target to remove eventual bitrot and in order to keep the merge commit clean. Having merge commits with huge code changes in them which we're caused by fixing merge conflicts, again, feels bad.

But this is certainly a matter of taste.

Re: Understanding the Git Workflow

#4

Post by zwieback »

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 suitability of git as a first version control system? My team consists of highly experienced engineers (EE/FW) with little or no software engineering experience.

Re: Understanding the Git Workflow

#6

Post by sunchild »

This opened my eyes a bit. I am a walking, talking git anti-pattern today. I'm mostly on a two-man team, so I can get away with it. I'm definitely going to start thinking more about a clean history on master.

What are some other best-practice git workflows that HN readers use?

Re: Understanding the Git Workflow

#7

Post by diminish »

pilif wrote: post #3

The minute I learned about "rebase -i" and "add -p" has changed how I think about commits. I learned how I could easily keep the history clean and conversely, I learned the huge value that a clean history has for maintenance. Now, building the commits as self-contained entities that don't break the build in between not only helps me while searching bugs later on, it sometimes helps me detect code smells around unneed…

just like you, i enjoy rebase -i, to change history; but I also hear some poeple claim the history should be kept as it is and should not be rewritten. What are your arguments for rebase?

Re: Understanding the Git Workflow

#8

Post by pilif »

diminish wrote: post #7
pilif wrote: post #3

The minute I learned about "rebase -i" and "add -p" has changed how I think about commits. I learned how I could easily keep the history clean and conversely, I learned the huge value that a clean history has for maintenance. Now, building the commits as self-contained entities that don't break the build in between not only helps me while searching bugs later on, it sometimes helps me detect code smells around unneed…

just like you, i enjoy rebase -i, to change history; but I also hear some poeple claim the history should be kept as it is and should not be rewritten. What are your arguments for rebase?

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 a public repository as it will make following history incredibly hard and it will screw with the clones other developers might have.

Conversely though, what I do on my personal development machine or on my personal public clone (everyone of us has a personal public clone we use for code reviews or discussions around code), is my business.

Nobody is telling me which editor to use and nobody is telling me whether I can clean up my commits or not.

Now in general, since learning that having clean commits is possible (it's not in subversion for example), I encourage my fellow developers to have clean commits and I discourage them from committing those famous "oops - removed typo" or "oops - added forgotten file" commits as they are completely useless for the overall history of the project.

Two months from now, nobody is going to care about you forgetting to add a file. But I'm likely going to care about when a feature has been added and why some lines have changed. So that's what I want to have in the public repository. Not a history of your personal forgetfulness.

If they manage to do that without ever rebasing (you can do it with add -p, it's just easy to make a mistake), then fine. In the end, I only care about a clean history on our public repository.

Re: Understanding the Git Workflow

#9

Post by mooneater »

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…

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.

Post reply on HN