top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Branches and workflow issue in GIT

0 votes
255 views

I'm fine with Git and branches when it's simple, but as soon as things get a little complicated, I get baffled and frustrated.

For example...

I've set up a members' log in system for a website, including a log-in form on the home page. The template for the home page was amended in the process. That's all committed on branch "memlogin".

That work is on hold because I have to get adverts on the home page, and I've made a new branch - "adverts". This was branched from the master branch, so does not include any of the work on "memlogin". But I need the revised home page template file because the log-in form affects the position of the adverts.

This is just an example. The general point is about how branches are not, in reality, completely independent, and work on one can affect another. What should I do?

I have the feeling that I'm missing the point about branches. Everyone raves about them, but they seem to fail as soon as the complexity of the real world kicks in.

BTW, I'm familiar with the diagram from nvie.com, but it doesn't answer this problem - its feature branches are completely independent until merged into the develop branch. In my experience the world is not that
neat and tidy.

posted May 22, 2013 by anonymous

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

+1 vote
 
Best answer

With the risk of sounding a bit patronising it seems you've forgotten the other side of the coin -- merging.

If, and this is a big if, your changes to your work on the home page template file is contained in self-contained patches, then you can merge those changes from 'memlogin' to 'adverts'.

If that's not possible you might be facing the risk of having to progressing 'memlogin' to a point where it can be deployed. Merge it into 'master' and then restart 'adverts' from there.

I think feature branches are the bee's knees too, but they aren't as easy as in all the examples one reads -- they require some up-front thinking. In particular it's problematic when dependencies between
features emerge during development. In essence you then only have two options, finish them in order of dependency, A then B, or don't. If you don't you'll probably end up hacking up certain aspects of B just
to make it good enough, then when A is finished you can revisit B.

Unfortunately not an answer to "What should I do?" Because that's really only an answer you, or your project manager, can answer. But hopefully it aids in thinking about the trade-offs of your options.

answer May 22, 2013 by anonymous
Similar Questions
+1 vote

I have a large Git project which I would like to dissect into subprojects with their own repositories. Git subtrees are ideal for this task: I first

  • create a branch with the contents of only one subfoldergit subtree split -P -b

and then

  • pull this branch into another repository.

For a transitional phase, I would like to have the subprojects read-only and sync them from master. The question is how to organize this. For every commit to master, I could of course perform the above procedure repeatedly for all subprojects, but this seems less then ideal since it does all the work all over again.

Is there a way to merge master into the subtree branches?

+2 votes

One practice of using git to have one feature per branch.

Let's say a developer has worked on many small features in many branches. Then he sends one pull request to the central (not controlled by him) for each feature he has developed. While he is waiting for all the features be merged into the central repository, he needs to use all these feature locally.

To do so, he may need to merge the changes in these branches to his local master branch. But this can be tedious when he has many branches.

Is there a way to somehow setup a branch so whenever something is committed to the branch, the changes will also be simultaneously committed to the local master branch? By this way, the develop can avoid having to merge changes from many branches.

+2 votes

I tend to accumulate lots of branches as I'd do one branch per feature. When cleaning up, I'd like to
delete all branches, which have been merged.

I could use

 $ git branch -d (which was merged already?) ^C
 $ git branch --merged # let's find out
 ...
 $ # Now run git branch -d with each of the branches.

This kind of question has already been discussed,
http://stackoverflow.com/questions/6127328/how-can-i-delete-all-git-branches-which-are-already-merged
suggests: git branch --merged | grep -v "*" | xargs -n 1 git branch -d

I could think of:

 $ git branch -d --merged # no need to specifiy a branch iff --merged is given with -d
 $ git branch --delete-merged # comes as an new extra option, doesn't clutter other commands
 $ git branch -d keyword-for-all-merged-branches

Before starting such a feature, I'd like to hear input of others.

+1 vote

At some point I added a large file into a git repository. It now exists on multiple branches, possibly with some changes to it. I'd like to remove it from git, but leave its current form (say the one on the master branch) on the file system.

I tried (on a dummy git archive)

git filter-branch --index-filter 'git rm --cached --ignore-unmatch bigfile' master branch1 branch2

That, however, does not leave a copy of bigfile on the file system.It isn't clear to me why not, though the description of the --tree-filteroption to filter-branch (I'm using the --index-filter option, but is is "similar") states:" (new files are auto-added, disappeared files are auto-removed ... )".
Is there a direct way to do what I want, with git? I've found similar requests;none of the responses point out that the above command actually deletes the file from the file system.

...