2

I need some help with GIT. We have just begun starting to use GIT and we just do not have a good setup placed in our company right now, so everything is a mess in my opinion. I have provided my history to aid you guys better understand what I am trying to do. Our Git History

Git history continued

So today I am trying to post to our support and master servers. We first post to Sup and then merge Sup into Live/master system.

If you look at the history and find Branch "130029," which I am trying to merge into Support, but wanted to see if I can "Squash" all the branches/commits I am suppose to post today into one package.

I have read about re-basing and tried it on Branch "130029" I did following code

git checkout DEV.130029
git rebase SUPPORT -i

This took me to the rebase editor, where it listed all the commits, but I was expecting those commits to be the other branches, so I could squash them and then merge into Support. I did not get further than the code above, I just did abort since it seemed I got lost. Is there any other way where I can select all the branches I am suppose to post, then merging all of them as one commit into Sup/master?

Thanks in advance!

Bananeweizen
  • 21,797
  • 8
  • 68
  • 88
ScrumMaster Guy
  • 267
  • 2
  • 6
  • 16
  • 5
    Wow. That looks like the London Underground map. http://www.tfl.gov.uk/assets/downloads/standard-tube-map.pdf – Graham Borland Jul 26 '12 at 14:36
  • the problem here is most likely that whenever you pull from another branch it becomes the history of your branch as well. thats soo messed up I would rather say. ignore that and do it better next time. But you can have a look at git-filter-branch(1) to get a bit of cleanup here. – Alexander Oh Jul 26 '12 at 14:45
  • Graham...ahahahahahahahaaa...yeah man..see what i mean..we just started out, so we are learning – ScrumMaster Guy Jul 26 '12 at 14:56
  • If I took your recommendation on starting over, which I have brought this up to my management. We typically have 3 systems Dev/Sup/live(master). If work is done in Dev...how would you go about keeping things clean? Would it be better to branch off of master or our Development server? Thanks! – ScrumMaster Guy Jul 26 '12 at 15:02
  • Any recommendations from anyone that we can improve our process? see my above comment on how are system is built. I would appreciate it:) – ScrumMaster Guy Jul 26 '12 at 17:14

1 Answers1

0

I'd argue your problem, if you have one, is workflow. Any sufficiently complex project using feature branches is going to have a messy graph. If you want a good example look no farther than git.git, the git source itself. This is the project that literally wrote the docs about git workflow, and if you drop a current snapshot of master into gitk or tig, it's going to look fairly chaotic at first pass.

What is concerning about your graph isn't that it looks like a subway map per se. It's that it doesn't show a clear conception of upstream vs. downstream branches, or an ordered graduation from upstream branches into downstream ones. In fact, it looks an awful lot like a workflow we used to use at my employer when we moved from SVN to git: Highly centralized, dependent on multiple "permanent" branches that weren't merged into one another often, whose integration was done entirely ad hoc. That could also be totally wrong. It's hard to infer your company's workflow policies from a few history snapshots.

If you feel it isn't easily explainable, and that feeling is shared by your team, it might be time for a new workflow. Version control is there to make your life easier, not suck away all your time. Many successful git workflows exist out there:

At the very least, if you aren't fixing bugs in the oldest upstream branch available, aren't keeping downstream development branches up-to-date with changes to their upstream ancestors, or are cherry-picking regularly between branches, it's time for a change.

Finally, without any other information about your workflow, if you work on, say, one feature branch during the day, and want to merge with it with the SUPPORT branch, squashing first, this is one of many methods to do it:

git checkout DEV.130029
git rebase -i --onto SUPPORT <branch_DEV_was_cut_from> DEV.130029 ;# squash what you want here
git checkout SUPPORT
git merge DEV.130029

That written, if you're rebasing just to make the graph look simpler, spend your time on the workflow instead.

Community
  • 1
  • 1
Christopher
  • 42,720
  • 11
  • 81
  • 99
  • Thanks Christopher for your explanation. Yeah I actually started doing more rebase -i. I am moving away from just merging and cherry-picking, which makes the history look crappy. I think my management likes that approach, so hopefully with time, the history will look much cleaner. I'm just not sure how other software companies handle their workflow. I know we're not the only ones that have 3 different environment systems for each project. I was hoping to get some feedback on what the workflow should be to handle that operation. Thanks a lot! – ScrumMaster Guy Jul 27 '12 at 14:11
  • Although we don't use it at my employer, I'd probably point you in the direction of Gitflow, above, which seems to be quite popular and accommodates different environments well. Our workflow, which has a "staging" (dev playground), "next" (QA / next release candidate), and "production" branches, is based on git's workflow. It works great for us, but we also have dedicated integration managers who handle merging. Either could be adapted to CI if you guys work that way. – Christopher Jul 27 '12 at 15:00
  • 1
    Oh, and one other thing: I would strongly recommend not making `cherry-pick` a habit between long term branches. Do it often, and it will make merging them together later one of the most miserable days of your life. – Christopher Jul 27 '12 at 15:03