
Git Workflow Basics - igor_marques
https://blog.codeminer42.com/git-workflow-basics-d405746f6205#.g648r8nuy
======
nhance
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)

~~~
tanderson92
But some of us use git-rebase every day perfectly fine and never lose
information. Yes, you must be careful. No, you should never use it on public
commits.

I wouldn't recommend it to others as I don't trust them to read the man page
and understand what git-rebase does. Those of us who use git-rebase also know
how to recover the refs since before they are GCed, though I've never had to
do that.

It's dangerous to pronounce certain powerful features of a system as off
limits for day to day private use. That's a different pronouncement than a
decision not to share "why everyone should use git-rebase often".

~~~
rralian
And we use git-rebase commonly on public commits without concern. Everyone
uses git differently.

~~~
K0nserv
I think this depends on your definition of public? For me public means "in
stable branches". I sure hope you aren't rebasing master

~~~
dimino
That's a weird definition of 'public'; for most folks, I imagine 'public' to
mean anything accessible without any authorization.

~~~
_ikke_
When people talk about public commits it means commits other people have
access too, and more specific, were able to commit on top. Authorization has
nothing to do with it. In practice it means anything you have pushed.

An exception can be made for topic branches, especially in a pull-request
workflow. These branches could be rebased / amended to update the final
result, even after they have been pushed already.

~~~
dimino
"commits other people have access to"

That's authorization.

~~~
_ikke_
You said:

> anything accessible without any authorization.

Even if it does require authorization, it's considered public in regard to
this discussion.

~~~
dimino
It's not public if the public can't read it (requires authorization).

Why is this a conversation?

~~~
mbrameld
Because you've applied a different definition of public that doesn't fit the
context. Public in the context in which it was used in this thread regarding
git commits simply means commits you have pushed to a repo that another
developer can access even if authorization is required to access it.

~~~
dimino
That's not what public means, though, in _any_ context.

~~~
_ikke_
What we are talking about is whether or not you should rewrite public history.
The technical reason is based on the fact if others have access to this
history or not.

It does not matter if you pushed it to a private repository where some other
people still have access to; they might have fetched that history and
committed on, which causes unexpected results when you rewrite such a branch.

I tend to use published history / commits for this reason to make it less
confusing.

------
alanfranzoni
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
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
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.

------
juped
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!

------
Karunamon
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.

~~~
dimino
I don't know about rebasing _everything_ , but a commit is a changeset, and a
changeset should always have a distinct and succinct purpose. There is no
value added in having a single feature spread out over 5 commits.

When writing a feature, I use git to save my progress, and once I'm done, I
would like to present the feature as a clear and complete changeset. A commit
is me saying, "These are the changes I'd like to make to the codebase", and I
feel that argument is easier to make when I present one thought, rather than
the dozens of thoughts I had on the way.

If I were perfect, then I would commit in a way that _was_ one cohesive
thought, but I'm not. My commits are often, "Did the thing", then "redid the
thing, with better testability", and "Re-redid the thing, fixing some
fundamental bug in how I did the thing at first", etc.

~~~
pawadu
I really don't understand all the opposition ti this idea. This is exactly how
git should be used, and it is how most successful large open source projects
require you to work.

------
EliasJorgensen
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
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
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

------
Matt3o12_
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
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

------
wodenokoto
So, commenters do not seem particularly impressed with this workflow.

What is a good workflow around git?

~~~
falsedan
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.

------
samblr
Does anybody dislikes git ?

------
wyclif
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.

------
jboons
Typo - CTRL + F "Oficial"

~~~
igor_marques
thanks for pointing this. It's fixed!

~~~
wyclif
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."

------
dboreham
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?

~~~
mixmastamyk
Could you be more specific?

------
geezerjay
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/)

