8 ms·

Git Workflow Basics

187 points by igor_marques 10y ago

dboreham 10y ago
Ugh, not this again. How many threads like this do we need before folks accept that git is not the solution to whatever problem we have?
- deleted 10y ago
  [deleted]
- mixmastamyk 10y ago
  Could you be more specific?
alanfranzoni 10y ago
At the same time, with this workflow (just like git flow) you're not doing continuous integration. Which is quite bad, imho. https://www.franzoni.eu/git-flow-is-superflous-and-complex/ https://www.franzoni.eu/git-flow-is-superflous-and-complex/
- igor_marques 10y ago
  Nothing stops you to use continuous integration with this workflow. For instance, Travis-CI and Codeship support branching (they can tell you if the new build will be fine or not). I didn't mention that in the post because it's intended for beginners and adding that info there could maybe be a little too much :/
  - alanfranzoni 10y ago
    Sure, most CI systems support branching. But what if you need to do ship a full pipeline of a branch for multi-repository project? I clarify the issue better in my post.
- stormbrew 10y ago
  If standing up a deployment or test environment for a branch that's not yet merged is difficult or impossible, that's what prevents you from doing CI, not whatever branching strategy you use. The model described in this post is basically the model used with svn, and it brings with it its own vast set of problems that active uses of topic branches are intended to resolve. We've been down this road before and it's not roses and sunshine.
- fredoliveira 10y ago
  Your suggestion feels a little misguided. You end your post by saying that you contest the a priori idea of branching, but seem to forget everything that is right about branching in the first place: * Want to see the history for a specific feature? Impossible in your proposal, native in a feature/topic branching model. * Want to do a code review on a specific feature? Again, impossible in your proposal, trivial in a feature/topic branching model. * Want multiple developers to work under the same codebase with minimal conflict resolution and clear separation of tasks? Very hard under your proposal, easy in a feature/topic branching model. You also say that using topic branching means not doing CI. I've used the idea of proper feature branching for years, and have never _not_ had a CI process. CI tools are most definitely ready for (and are quite welcoming of) workflows like git-flow. I'd be happy to speak at more length about how we implement it if you'd like, but I assure you it is all but complicated.
  - alanfranzoni 10y ago
    Hello Fred, thanks for your interest. about the history for a feature: most branching based workflows prefer squashing commits when merging, so most probably the history is lost whatsoever. you're right I didn't explain how I do code reviews - and, effectively, I usually prefer pair programming when pushing, and after-the-commit code reviews - but before the feature is toggled on by default. There's a reason for this, I usually say that a review should review the status after a merge, not just a change; many a times I've seen reviews for a PR that miss the whole point, along the lines of "the change is good, even though the resulting merged code is complete mess"; on the contrary, if you review a certain commit before toggling a feature on, you're basically declaring that the code, at the point, is basically good. Yes, it may be hard for a large codebase, and often reviews are done by looking at what changed, and not at everything. But I've seen many, many, many stupid errors done or overlooked because people just looked at the change and not at the whole code after such change.
geezerjay 10y ago
This article appears to be a cheap copy of Atlassian's Git workfflows and tutorial https://www.atlassian.com/git/tutorials/comparing-workflows/ https://www.atlassian.com/git/tutorials/comparing-workflows/
nhance 10y ago
This workflow is scary. A rebase should not be part of any everyday workflow and must be reserved _only_ for exceptional situations. Rebasing can cause the loss of history and developers should be as careful with it as system admins are with `sudo`. I can't recommend any workflow that includes it without treating is as a terrifying and scary thing. How easy is it to accidentally remove a line during interactive rebase and lose all work associated with it? This is why my team and I moved to squash merging. Sure it has it's own drawbacks, but they're far less worrisome than rebasing. If you screw up a rebase, the history is re-written or force-pushed by accident. If you screw up a squash merge, you can still check out the intermediate commits if you know the hash. We won a Ruby award for our work on Git Reflow. There are big improvements coming this week that can make it easy for teams to tweak the workflow to suit any special needs you might have. It works on github and bitbucket and automatically creates pull requests (and makes sure they're reviewed.) Gitlab support coming soon (maybe this month). http://github.com/reenhanced/gitreflow http://github.com/reenhanced/gitreflow
- nhance 10y ago
  My apologies if this comes across as overly harsh! This article was really quite well written, and it's only after having been burned through rebases that I've gotten so headstrong against it. We need more articles like this! Thank you for your work!
- stormbrew 10y ago
  > This is why my team and I moved to squash merging. Sure it has it's own drawbacks, but they're far less worrisome than rebasing. If you screw up a rebase, the history is re-written or force-pushed by accident. If you screw up a squash merge, you can still check out the intermediate commits if you know the hash Until the original branch is deleted and the refs are garbage collected, anyways. It seems strange to me to advocate for squash merging on a premise of not losing history. A squash merge is a rebase.
  - steveklabnik 10y ago
    > A squash merge is a rebase. Well, it's not a rebase in the literal sense: the base commit isn't changing. It _is_ modifying history, though.
Matt3o12_ 10y ago
How do you guys approach the one branch per developer rule? For smaller changes, i do it all the time but it is very hard for bigger changes. When we write bigger features we always need at least two dev. One writing the front end (HTML templates) and one the backend (whatever populates the templates, makes sql query). We both need immediate feedback. I design the models around the templates so i need the templates at least partly to work. He needs the models to properly do his work either (if he wrote the templates before I write the models, the development of the whole feature would slow down and it is not nice to only work with a lorem impsum all the time. We also get very detached from the actual feature that way. How do you manage those situations? Just do one branch per feature and if that feature requires more work, then just let two people work on that feature?
- K0nserv 10y ago
  Do what you say and both work in the same branch. If the branch diverges from master and you need to catch synchronize and then one of you does a rebase the other does git reset --hard origin/feature-branch. Alternatively just leave any cleanup till the end of the MR and designate one person to it
Karunamon 10y ago
Could anyone who follows the "rebase all the merges" workflow detail why they choose to work that way? It seems to me that Git's strength is being able to time travel in your repo (especially with something like git-bisect, one of the few tools I'd call downright magical) But if you're rebasing your commits, haven't you lost that? The concerns about a "clean commit graph" seem more aesthetic than functional.
- steveklabnik 10y ago
  > more aesthetic than functional It is easier to understand a cleaner history than a messy one. > haven't you lost that? You've lost the ability to look through one kind of history, but not other ones. bisect still works if you've rebased.
  - Karunamon 10y ago
    Only easier to understand if the commit messages suck. If your commit messages are descriptive, and each commit is an atomic unit of work (in other words: following best practices) rebasing has thrown away history that you can never get back.
    - steveklabnik 10y ago
      Right, but often, that's not something that happens the first time around. The idea is that you rebase in order to get that kind of history 100% of the time. You cannot get things perfect on the first try; this is part of the whole principle of code review. When my patch is perfect, except for that one little typo, what should be done? Is a history with two commits, one amazing, one saying "fix typo" with a one-character diff, or one commit that's perfect, an easier to understand history? What is actually lost by "throw[ing] away history that you can never get back"? If it had been right in the first time, that history would have never even existed in the first place. So you end up with the exact same thing.
      - Karunamon 10y ago
wodenokoto 10y ago
So, commenters do not seem particularly impressed with this workflow. What is a good workflow around git?
- falsedan 10y ago
  There are plenty; there's no one right workflow, because different teams have different requirements. At work, we use deploy branches for a few repos, and integration branches for others. Personally, I use rebase for my own projects.
jboons 10y ago
Typo - CTRL + F "Oficial"
- igor_marques 10y ago
  thanks for pointing this. It's fixed!
  - wyclif 10y ago
    I would re-write the first sentence to "You probably know how to use Git on a daily basis" or perhaps "You probably know how to use Git in your daily workflow."
samblr 10y ago
Does anybody dislikes git ?
EliasJorgensen 10y ago
Personally, i prefer having a develop branch which all the development happens on, with developers creating feature branches from that, and then merge develop with master, when a new version is achieved.
- EliasJorgensen 10y ago
  Keep in mind that i only work on small teams with smallish projects, this workflow would probably not work for big projects with a bunch of developers working simultaneously.
  - pawadu 10y ago
    Actually this works perfectly fine in large teams too, if you add another level of branches. In fact, that is how the Linux kernel development works
juped 10y ago
Wow, a blog post called "Git Workflow Basics" that really does just have simple and useful basics and doesn't try to terrify you out of or into using specific git features that the author decided are infinitely sacred or infinitely profane. I can't really explain the depth of how pleasant, and how surprising, this pleasant surprise was. Thanks!
wyclif 10y ago
The English needs a massage here. The very first sentence is grammatically incorrect, which doesn't inspire confidence. It's a fine introductory post for learning Git, though, and as such I welcome it.

187 points by igor_marques 10y ago

Ugh, not this again. How many threads like this do we need before folks accept that git is not the solution to whatever problem we have?

deleted 10y ago
[deleted]
mixmastamyk 10y ago
Could you be more specific?

alanfranzoni 10y ago

At the same time, with this workflow (just like git flow) you're not doing continuous integration. Which is quite bad, imho. https://www.franzoni.eu/git-flow-is-superflous-and-complex/ https://www.franzoni.eu/git-flow-is-superflous-and-complex/

igor_marques 10y ago
Nothing stops you to use continuous integration with this workflow. For instance, Travis-CI and Codeship support branching (they can tell you if the new build will be fine or not). I didn't mention that in the post because it's intended for beginners and adding that info there could maybe be a little too much :/
- alanfranzoni 10y ago
  Sure, most CI systems support branching. But what if you need to do ship a full pipeline of a branch for multi-repository project? I clarify the issue better in my post.
stormbrew 10y ago
If standing up a deployment or test environment for a branch that's not yet merged is difficult or impossible, that's what prevents you from doing CI, not whatever branching strategy you use. The model described in this post is basically the model used with svn, and it brings with it its own vast set of problems that active uses of topic branches are intended to resolve. We've been down this road before and it's not roses and sunshine.
fredoliveira 10y ago
Your suggestion feels a little misguided. You end your post by saying that you contest the a priori idea of branching, but seem to forget everything that is right about branching in the first place: * Want to see the history for a specific feature? Impossible in your proposal, native in a feature/topic branching model. * Want to do a code review on a specific feature? Again, impossible in your proposal, trivial in a feature/topic branching model. * Want multiple developers to work under the same codebase with minimal conflict resolution and clear separation of tasks? Very hard under your proposal, easy in a feature/topic branching model. You also say that using topic branching means not doing CI. I've used the idea of proper feature branching for years, and have never _not_ had a CI process. CI tools are most definitely ready for (and are quite welcoming of) workflows like git-flow. I'd be happy to speak at more length about how we implement it if you'd like, but I assure you it is all but complicated.
- alanfranzoni 10y ago
  Hello Fred, thanks for your interest. about the history for a feature: most branching based workflows prefer squashing commits when merging, so most probably the history is lost whatsoever. you're right I didn't explain how I do code reviews - and, effectively, I usually prefer pair programming when pushing, and after-the-commit code reviews - but before the feature is toggled on by default. There's a reason for this, I usually say that a review should review the status after a merge, not just a change; many a times I've seen reviews for a PR that miss the whole point, along the lines of "the change is good, even though the resulting merged code is complete mess"; on the contrary, if you review a certain commit before toggling a feature on, you're basically declaring that the code, at the point, is basically good. Yes, it may be hard for a large codebase, and often reviews are done by looking at what changed, and not at everything. But I've seen many, many, many stupid errors done or overlooked because people just looked at the change and not at the whole code after such change.

geezerjay 10y ago

This article appears to be a cheap copy of Atlassian's Git workfflows and tutorial https://www.atlassian.com/git/tutorials/comparing-workflows/ https://www.atlassian.com/git/tutorials/comparing-workflows/

nhance 10y ago

This workflow is scary. A rebase should not be part of any everyday workflow and must be reserved _only_ for exceptional situations. Rebasing can cause the loss of history and developers should be as careful with it as system admins are with `sudo`. I can't recommend any workflow that includes it without treating is as a terrifying and scary thing. How easy is it to accidentally remove a line during interactive rebase and lose all work associated with it? This is why my team and I moved to squash merging. Sure it has it's own drawbacks, but they're far less worrisome than rebasing. If you screw up a rebase, the history is re-written or force-pushed by accident. If you screw up a squash merge, you can still check out the intermediate commits if you know the hash. We won a Ruby award for our work on Git Reflow. There are big improvements coming this week that can make it easy for teams to tweak the workflow to suit any special needs you might have. It works on github and bitbucket and automatically creates pull requests (and makes sure they're reviewed.) Gitlab support coming soon (maybe this month). http://github.com/reenhanced/gitreflow http://github.com/reenhanced/gitreflow

nhance 10y ago
My apologies if this comes across as overly harsh! This article was really quite well written, and it's only after having been burned through rebases that I've gotten so headstrong against it. We need more articles like this! Thank you for your work!
stormbrew 10y ago
> This is why my team and I moved to squash merging. Sure it has it's own drawbacks, but they're far less worrisome than rebasing. If you screw up a rebase, the history is re-written or force-pushed by accident. If you screw up a squash merge, you can still check out the intermediate commits if you know the hash Until the original branch is deleted and the refs are garbage collected, anyways. It seems strange to me to advocate for squash merging on a premise of not losing history. A squash merge is a rebase.
- steveklabnik 10y ago
  > A squash merge is a rebase. Well, it's not a rebase in the literal sense: the base commit isn't changing. It _is_ modifying history, though.

Matt3o12_ 10y ago

How do you guys approach the one branch per developer rule? For smaller changes, i do it all the time but it is very hard for bigger changes. When we write bigger features we always need at least two dev. One writing the front end (HTML templates) and one the backend (whatever populates the templates, makes sql query). We both need immediate feedback. I design the models around the templates so i need the templates at least partly to work. He needs the models to properly do his work either (if he wrote the templates before I write the models, the development of the whole feature would slow down and it is not nice to only work with a lorem impsum all the time. We also get very detached from the actual feature that way. How do you manage those situations? Just do one branch per feature and if that feature requires more work, then just let two people work on that feature?

K0nserv 10y ago
Do what you say and both work in the same branch. If the branch diverges from master and you need to catch synchronize and then one of you does a rebase the other does git reset --hard origin/feature-branch. Alternatively just leave any cleanup till the end of the MR and designate one person to it

Karunamon 10y ago

Could anyone who follows the "rebase all the merges" workflow detail why they choose to work that way? It seems to me that Git's strength is being able to time travel in your repo (especially with something like git-bisect, one of the few tools I'd call downright magical) But if you're rebasing your commits, haven't you lost that? The concerns about a "clean commit graph" seem more aesthetic than functional.

steveklabnik 10y ago
> more aesthetic than functional It is easier to understand a cleaner history than a messy one. > haven't you lost that? You've lost the ability to look through one kind of history, but not other ones. bisect still works if you've rebased.
- Karunamon 10y ago
  Only easier to understand if the commit messages suck. If your commit messages are descriptive, and each commit is an atomic unit of work (in other words: following best practices) rebasing has thrown away history that you can never get back.
  - steveklabnik 10y ago
    Right, but often, that's not something that happens the first time around. The idea is that you rebase in order to get that kind of history 100% of the time. You cannot get things perfect on the first try; this is part of the whole principle of code review. When my patch is perfect, except for that one little typo, what should be done? Is a history with two commits, one amazing, one saying "fix typo" with a one-character diff, or one commit that's perfect, an easier to understand history? What is actually lost by "throw[ing] away history that you can never get back"? If it had been right in the first time, that history would have never even existed in the first place. So you end up with the exact same thing.
    - Karunamon 10y ago

wodenokoto 10y ago

So, commenters do not seem particularly impressed with this workflow. What is a good workflow around git?

falsedan 10y ago
There are plenty; there's no one right workflow, because different teams have different requirements. At work, we use deploy branches for a few repos, and integration branches for others. Personally, I use rebase for my own projects.

jboons 10y ago

Typo - CTRL + F "Oficial"

igor_marques 10y ago
thanks for pointing this. It's fixed!
- wyclif 10y ago
  I would re-write the first sentence to "You probably know how to use Git on a daily basis" or perhaps "You probably know how to use Git in your daily workflow."

samblr 10y ago

Does anybody dislikes git ?

EliasJorgensen 10y ago

Personally, i prefer having a develop branch which all the development happens on, with developers creating feature branches from that, and then merge develop with master, when a new version is achieved.

EliasJorgensen 10y ago
Keep in mind that i only work on small teams with smallish projects, this workflow would probably not work for big projects with a bunch of developers working simultaneously.
- pawadu 10y ago
  Actually this works perfectly fine in large teams too, if you add another level of branches. In fact, that is how the Linux kernel development works

juped 10y ago

Wow, a blog post called "Git Workflow Basics" that really does just have simple and useful basics and doesn't try to terrify you out of or into using specific git features that the author decided are infinitely sacred or infinitely profane. I can't really explain the depth of how pleasant, and how surprising, this pleasant surprise was. Thanks!

wyclif 10y ago

The English needs a massage here. The very first sentence is grammatically incorrect, which doesn't inspire confidence. It's a fine introductory post for learning Git, though, and as such I welcome it.