Best approach to test new stuff in sources without damage anything

Question

I was working with Git for a while (not an expert though) and this question never comes to my mind but now is rounding around.

Let's said I have a repository with three branches plus master:

• master
• branch_1
• branch_1_devel
• branch_1_devel_test

I am not using master at all so branch_1 becomes and behaves like master. Usually and as it should be I make new development at branch_1_devel and then I merge those changes when them are ready into branch_1.

Now I want to test a new functionality so I have created a new branch branch_1_devel_test. After checkout into that branch I have made changes in a file named file1.

Something with more priority needs to be done in branch_1_devel so I need to checkout that branch and edit the same file1. After all is done I've added the file, commit the changes and then merge into branch_1.

Then I go back to branch_1_devel_test because I want continue testing where I left in file1.

Having this scenario (if you don't understand let me know and I'll try to be more clear) a few questions:

• if I pull the changes from branch_1_devel will be file1 getting into a conflict? meaning I will loose my previous changes?
• do I need to commit the changes made at branch_1_devel_test as soon as I checkout into another branch? meaning will be a problem if I try to checkout in a new branch without commit changes in the current one?

The whole idea behind all of this is: I want to test something but I don't want to push changes to branch_1_devel neither branch_1.

Update

This is a small test I have made to understand how Git behaves.

$ git branch
  master
  branch_1
* branch_1_devel

$ git checkout -b branch_1_devel_test
Switched to a new branch 'branch1_devel_test'

$ git branch
  master
  branch_1
  branch_1_devel
* branch_1_devel_test

Now I am in branch_1_devel_test so I have created a new empty file

$ git status
# On branch branch_1_devel_test
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   application/controllers/AdminconsoledemoController.php
#
nothing added to commit but untracked files present (use "git add" to track)

Switch back to branch_1_devel

$ git checkout branch_1_devel
Switched to branch 'branch_1_devel'
$ git status
# On branch branch_1_devel
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   application/controllers/AdminconsoledemoController.php
#
nothing added to commit but untracked files present (use "git add" to track)

Why if the file was created at branch_1_devel_test is being tracked at branch_1_devel? That's exactly why I am trying to avoid because I will need to commit the changes before pull anything from origin at branch_1_devel

Answer 1

If I understand correctly... if you create a file in branch_1_devel_test without committing it, it will be independent from the branches (it will not be part of the repo). This means that when you switch back to branch_1_devel the file will be still there as an untracked file. If you commit the file in branch_1_devel_test the file will be part of the repo and will disappear when you change the branch.

If you want to avoid having the file lying around, you can use the stash mechanism. Actually, I am not sure you can stash untracked files. Anyway, what you are trying to do looks weird: if you create a file that is worth keeping, you should commit it. If then, in the future, you will not need it anymore, you can delete it (of course, if it is a large file things are different... )

Answer 2

You can use git worktree in order to keep development in different branches without comitting or stashing. It allows to checkout branches in their own working directories independently. Example:

git worktree add ../project-branch_1 branch_1

However worktree command has been introduced in Git 2.5 and is still considered experimental:

Multiple checkout in general is still experimental, and the support for submodules is incomplete. It is NOT recommended to make multiple checkouts of a superproject.

I've never encountered problems with it even with submodules, except for need to manually delete working directories. Other links: What would I use git-worktree for?, github worktree notes.