Gweezlebur - Latest Comments

Re: My Git Workflow

slnc — Mon, 16 Feb 2009 15:07:51 -0000

Isn't "git rerere" supossed to solve this specific case?

Re: My Git Workflow

Guillermo — Mon, 02 Feb 2009 12:46:59 -0000

Whell, it isn't correct.

In that example I assume that my local branch master can be ff to origin/master. So git pull --rebase isn't necesary.

Re: My Git Workflow

Guillermo — Mon, 02 Feb 2009 12:39:06 -0000

In my company, I decide to each commit to the repo has one ticket associated. (Excepts some minor bug fixes).
But big tickets take a lot of commits. For that insted of doing a just commit -amend, y commit in another branch, and when finished, y just run something like these:

git fetch && git rebase origin/master && git checkout master && git pull --rebase && git merge my_new_feature --no-ff --no-commit && git commit
Insert my commit message with the associated ticket id.

By these way i always know when a bug is introduced, and can revert some minor commit or all the feature.

In git log of branch master or production, all tickets (merges or simple commits) appers with its own ticket, and ing ginst(or integration system can see the commit and click to go to the ticket easily).

Re: Importing Mephisto comments into Disqus

asdfasf — Tue, 27 Jan 2009 16:10:09 -0000

awesome

Re: My Git Workflow

Walther H Diechmann — Sat, 24 Jan 2009 12:48:49 -0000

Wonderful insights shared, Mike, thank you! :)

One/several of the comments mentions the added trouble handling database versions, and I totally agree - database versioning is troublesome!

Idea: If somebody with the helicopter overview of git wrote a plugin (is that at all possible) to handle dataabase versioning on creating branches and switching between them, they'd probably do something along the lines of:

1. rollback the current database
1.1 dump whatever data is in the database
1.2 drop tables

2. rollforward database on branch
2.1 create tables
2.2 load data

(on Rails projects, you'd have rake db:migrate along to assist in the rolling back/forward, but it would have to be refined to handling data as well)

I know - on large projects, this added workflow would prove to be a inhibitor on branching which is certainly undesireable, but on the other hand, developers would be spared the agonies of recreating databases or finding themselves fighting bugs which really are the consequence of missing syncronizations to database versions.

Just an idea - I'm afraid I am not myself able to take this idea into any kind of beta, though :(

But - again - thank you for sharing, Mike!

Re: My Git Workflow

michaelivey — Sat, 24 Jan 2009 11:50:13 -0000

You could use post-commit hooks to automatically deploy a production branch (see Daniel Miessler's post above) but I'd look into a deployment tool like Capistrano, which was designed for Ruby on Rails but works for any kind of deployment. I'm not a huge fan of using version control as a deployment tool, because I like to be able to control my deployments more.

Re: My Git Workflow

Markux — Sat, 24 Jan 2009 05:03:07 -0000

Hi, I'm using svn, but it lacks in deployment on site production (since I need to login on every site and launch svn up).
How git deploying change on server production (or other server)? Can I distribute change on every server from my local machine?

Re: Biden was never the President

Jeffrey Hulten — Fri, 23 Jan 2009 13:38:21 -0000

In addition, the 25th amendment is very clear about the rules for the VP taking over for the President (see below).

Section 1. In case of the removal of the President from office or of his death or resignation, the Vice President shall become President.

Section 2. Whenever there is a vacancy in the office of the Vice President, the President shall nominate a Vice President who shall take office upon confirmation by a majority vote of both Houses of Congress.

Section 3. Whenever the President transmits to the President pro tempore of the Senate and the Speaker of the House of Representatives his written declaration that he is unable to discharge the powers and duties of his office, and until he transmits to them a written declaration to the contrary, such powers and duties shall be discharged by the Vice President as Acting President.

Section 4. Whenever the Vice President and a majority of either the principal officers of the executive departments or of such other body as Congress may by law provide, transmit to the President pro tempore of the Senate and the Speaker of the House of Representatives their written declaration that the President is unable to discharge the powers and duties of his office, the Vice President shall immediately assume the powers and duties of the office as Acting President.

Thereafter, when the President transmits to the President pro tempore of the Senate and the Speaker of the House of Representatives his written declaration that no inability exists, he shall resume the powers and duties of his office unless the Vice President and a majority of either the principal officers of the executive department or of such other body as Congress may by law provide, transmit within four days to the President pro tempore of the Senate and the Speaker of the House of Representatives their written declaration that the President is unable to discharge the powers and duties of his office. Thereupon Congress shall decide the issue, assembling within forty-eight hours for that purpose if not in session. If the Congress, within twenty-one days after receipt of the latter written declaration, or, if Congress is not in session, within twenty-one days after Congress is required to assemble, determines by two-thirds vote of both Houses that the President is unable to discharge the powers and duties of his office, the Vice President shall continue to discharge the same as Acting President; otherwise, the President shall resume the powers and duties of his office.

Re: My Git Workflow

RayMorgan — Fri, 23 Jan 2009 04:07:42 -0000

We have a similar workflow where I work. We create a topic branch for each ticket that comes. Developers actually do not have access to push back to origin/master, instead we push our topic branches up to a personal fork. We then put in a merge request with the release team and they go through these topic branches, merge them in and push that up to origin/qa which is then tested. If branches failed to merge, the developer then rebases off of the new origin/qa branch and re-pushes up to their fork.

Once the qa branch has been successfully tested, the release team tags the HEAD of qa and deploys that code base. Then finally this is merged back into origin/master so that all the developers can update. It might seem like quite a bit, but it works... and allows some really fast emergency release patterns when they are needed.

Re: My Git Workflow

danielrm26 — Fri, 23 Jan 2009 02:58:36 -0000

Nice. Here's mine: http://dmiessler.com/blog/using-git-to-maintain...

Re: My Git Workflow

mernen — Fri, 23 Jan 2009 02:45:15 -0000

My workflow has changed as time passed, and I believe what changed it the most was to always (and constantly) use add -p. I like to use it as a quick self-review before staging anything. One of the consequences is that I'm using a lot less "checkpoint" commits, since often just staging everything into small chunks is enough. My checkpoint commits usually have crappy messages, like `git commit -m WIP` or `git commit -m '[W] extracted methods'`, and I have to admit that sometimes they are not really enough to remind me of what to write in the final commit message when squashing everything together in the end (I particularly use rebase -i for that, as the checkpoints might actually turn into two or more final commits); I should improve that.

Another characteristic, not directly related to that, is that now I'm working directly on the "main" branch much more often. I realized that a lot of the time when people use the temporary branching pattern (even for small things and with very remote possibility of having to interrupt work), they tried to keep master "clean". Why that? There's origin/master there already, no need to duplicate its function. If the need arises for me to work on something else, *then* I will stash the changes, or create a new branch and back out some commits from master — and often this is just a reset to origin/master. (Of course, if this is something I expect to work for a long time before merging in, then I will just create a new branch from the start.)

Re: My Git Workflow

justinwr — Wed, 21 Jan 2009 09:30:34 -0000

When in Git-SVN, I like to see the merges... because it keeps with how I used to use SVN.

Re: My Git Workflow

justinwr — Wed, 21 Jan 2009 09:29:13 -0000

So when you go to create a new topic branch you just base it off the previous topic branch? Or do you go in and rebase your master from the topic branch where you dcommit'ed?

Re: My Git Workflow

Antti Rasinen — Wed, 21 Jan 2009 07:47:18 -0000

This is precisly what I am using as well. I basically only have topic branches and remote branches and hardly ever anything that tracks the remote branch for a long time.

Re: My Git Workflow

Joao Vitor — Wed, 21 Jan 2009 07:46:39 -0000

git rebase origin/master

Never tried this.
Nice to know that this is possible.

Re: My Git Workflow

Adam Hupp — Wed, 21 Jan 2009 05:11:34 -0000

I have a pretty similar workflow with two changes. First, at step #5 I'm always rebasing against the origin, git-svn in this case. I've never felt the need to rebase against something else.

Also, there's no need to for steps 7-9 since I just dcommit right from topic-branch. This saves a few steps and makes master entirely unnecessary.

Re: My Git Workflow

drogus — Wed, 21 Jan 2009 03:57:40 -0000

# git rebase master
# At this point, either it goes well or I have merge conflicts. If I have conflicts, I fix them, and keep going. It’s better to have conflicts on a topic branch than in master.

Could you write how do you handle these conflicts not to have any commits on top of your topic branch commit? git --amend is very good and I also like it for one commit fixes but often I find it hard to leave this one specified commit on top and I end up with git rebase --interactive anyway :)

Re: My Git Workflow

Long Nguyen — Wed, 21 Jan 2009 03:32:27 -0000

Handling development that switches between different versions of a database schema (that's what I'm assuming you meant) is a challenge for any VCS. The issue is that you've got an external dependency (the database you're connecting to) that needs to be kept in sync with the branch you're on.

Odds are you'll need multiple databases (one per version of the schema). If the database connection is versioned, just make sure the correct info is on each branch. If it's not versioned, then it's up to you to make sure that it gets updated properly on the "git checkout" call.

Don't forget you can also have a repository clone for each database version. And you can connect each one up to the others via remotes (just put in the directory path as the URL).

Re: My Git Workflow

Long Nguyen — Wed, 21 Jan 2009 02:26:32 -0000

If you're working in a team, then rebasing has benefits over merging in that you have a stronger guarantee that everyone is starting from the right version of the code. As a single developer, it's not as critical unless you really like having an optimal branch structure (although the more simultaneous branches you have, the better off you are in using rebase).

In some cases, I've seen Git "choke" on a rebase because the deltas between the old and new starting points contain changes that overlap with the commits on the branch. Because the commits are reapplied one by one, you end up having to resolve basically the same merge issue manually with each commit. In that case you're better off canceling the rebase and performing a merge which gets everything in one step. Not really something to discourage you from using rebase but something to be aware of.

Re: My Git Workflow

michaelivey — Wed, 21 Jan 2009 02:04:16 -0000

Rebasing keeps you from having a merge commit, so the log is a little cleaner. Some people never bother and always merge (Linus included, as I understand it) so you shouldn't feel compelled to rebase.

Re: My Git Workflow

bradly — Wed, 21 Jan 2009 00:37:05 -0000

Nice post. Git was one of those tools for me where I just had to keep using it until it started to make sense.

One question though... I always merge master into my topic branches. Does rebaseing have any benefit over merging? I'm also still trying to figure out how to handle branches with different database versions.

Re: My Git Workflow

Russell Jones — Tue, 20 Jan 2009 20:58:08 -0000

Very useful info. I was particularly interested in the bit about development, staging and production branches. Thanks Mike.

Re: My Git Workflow

nothingmuch — Tue, 20 Jan 2009 20:03:58 -0000

you can go back to the topic branch and then do

git reset HEAD^

to undo that commit.

also gitk --all will show the stash (git stash is kind of like doing git checkout -b stash, git commit -am "wip on blah blah blah")

Re: My Git Workflow

nothingmuch — Tue, 20 Jan 2009 19:58:38 -0000

Topic branches can be easier to use.

Instead of:

git checkout master
git pull
git checkout topic
git rebase master

you can do something like:

git fetch
git rebase origin/master

and save the trouble of switching

merging, resetting and rebasing from the explicit refs is also very useful for working with topic branches in git svn, where you often need a little more voodoo.

Re: My Git Workflow

Dave — Tue, 20 Jan 2009 19:44:03 -0000

Fascinating workflows. This is exactly what I, as a relative newcomer to DVCS in groups >1 people, need to know. And that is also, paradoxically, the kind of thing that is not that easy to find, since everyone just keeps repeating that I'm free to do whatever the heck I want, without ever pointing me at best practices, or even "things that work in my experience".

So, thanks for the insight.