0

I am using sourceTree for Mac as my GUI so I would appreciate instructions on using it but obviously I would like to learn the bash commands as my first language.

We have a remote repo we call develop, and the practice is, when you develop a feature, you create a branch from develop for that feature, for example feature1, pull it down, and then submit a pull request on the branch you created.

I have recently developed some analysis tools which I don't want to get put into the remote code base (yet, anyway).

How would I, locally, merge my analysis branch with my feature1 branch for testing, and then unmerge analysis after I'm completed?

Which branch should I have checked out at the time I do the merge, feature1 or analysis?

NOTE: I want to retain all the file changes to feature1 I did while the branches were merged; the files and edits from analysis are extremely unlikely to conflict with my feature branch, so essentially I'm adding in some non-conflicting code, then pulling the branch out; so any commits I have done to feature1, I don't want to lose.

Oliver Williams
  • 5,966
  • 7
  • 36
  • 78

2 Answers2

0

To unmerge a branch, you can simply git revert the merge commit like so:

git checkout feature_branch
git revert -m 1 <merge_commit_sha>

It is possible that you will end up with some conflicts that you'll have to manually unmerge, just like when merging normally.

Alex Pan
  • 4,341
  • 8
  • 34
  • 45
  • 1
    Might want to add that the `git revert` command be done on the `feature1` branch – Thong Kuah May 23 '15 at 08:58
  • I edited my question to clarify some concerns I didn't voice very well. The two main questions actually are: 1. which branch should I be in when I do this (or does it matter), and 2. will this only remove file changes associated with `analysis` and NOT the commits that were done on `feature1` while they were merged? – Oliver Williams May 23 '15 at 09:22
  • Merging is not a good way here. And `reset --hard` will delete all feature changes anyway. So downvote. – Nick Volynkin May 23 '15 at 09:27
  • 1
    @OliverWilliams `reset --hard` will remove changes to `feature1`, and `revert` will just make extra commits, resulting in dirtier commit history. – Nick Volynkin May 23 '15 at 09:29
  • @ThongKuah, I added clarification for which branch the `git revert` should happen on. – Alex Pan May 23 '15 at 10:34
  • 1
    @OliverWilliams, yes, git reverting the merge commit will remove file changes associated with `analysis` and NOT the commits done on `feature1` when they were merged. – Alex Pan May 23 '15 at 10:42
  • @NickVolynkin, I removed the `git reset --hard` alternative solution because the original poster wants to keep commits done while the branches were merged. – Alex Pan May 23 '15 at 10:44
0

tl;dr

I recommend you to approach your analysis tools as a separate code under it's own source control and never merge it to your feature branches. Keep it in a folder with own git repo and under .gitignore from higher-level repo.

Detailed explanation

Do I understand it right that:

  1. You have separate analysis code which is used for development but doesn't become a part of feature code,
  2. And it is not supposed to become a part of shared codebase,
  3. But you want it in the project during the development time?

If this is so:

  1. Merging is not a way at all. By merging you bring your code into the commits that will be later pushed to develop repo. It will still exist in the remote code base in several middle commits on each feature branch. (This can be solved with git filter-branch, but to my opinion it's crushing a fly with a steam-roller. Not worth it.)
  2. Most probably you will develop your analysis tool, so it needs own versioning and source control.

Solution

Make a special folder in your project and put it in .gitignore:

/analysis/*

If you're using Maven or some other tool which implies strict structure policy, this may be /../../../../../analysis, but that's no difference.

Have all your analysis-related code in that folder. Initiate a separate repo there and make commits as you develop your tools.

Work with your feature branches just as you did before. The only file you have changed now is your .gitignore. Before you push to remote, do:

git checkout <sha-of-branching-time-commit> -- .gitignore
git commit -m'fixed .gitignore'

This returns the master-repo .gitignore to initial state. You may want to make a backup of modified gitignore for future featur branches.

Optionally, you can make an agreement with your team to have a designated "this is my code and I'm not gonna share it" folder. Then it can be added to common .gitignore

Community
  • 1
  • 1
Nick Volynkin
  • 14,023
  • 6
  • 43
  • 67
  • Nick, there are good things here but I'm thinking that I might have to have the analysis tools eventually merged anyway and from a structure standpoint at least for this project a separate folder might not be the best way. Also, it requires me to use register_shutdown_function( ) in PHP so I *think* that this merge might be a good solution - as well as giving me more experience with GIT. Thanks! – Oliver Williams May 23 '15 at 13:30
  • Ok, I see. Just know that your analysis code will still be available in the commits you push. So you're effectively pushing it to the develop repo, although not in a last commit. – Nick Volynkin May 23 '15 at 13:54
  • Hmm.. I have no problem with people seeing the code I put in, I just want to "take it out" before pushing to remote by unmerging. I'm 100% sure that what I write won't touch the same files as are changed for the feature, but I don't want my analysis going to QA first due to system load check etc. etc. - all the stuff that you'd want to do on a remote brach before it made its way in production. – Oliver Williams May 23 '15 at 17:36