0

I am just starting to learn GIT when I should have learned it a long time ago. I have been a web developer for 25 years and rarely work with teams. However, I am learning GIT but they don't answer all of my questions.

Hypothetical situation:

My remote master contains version 1 of a deployable program written in Python. I decide to create a branch to work on a new feature.

There is another developer working on a separate branch called "Bug Fix". I create a new branch called "New Feature" and start writing the code for it.

I have the following questions:

  1. How would I go about testing the new feature before I merge it to the master branch?
  2. What if the person who is working on the "Bug fix" merges with the master and their code prevents my new feature from working properly?
  3. How does the other person working on the "Bug Fix" test their code with or without my "New Feature"?
  4. How would this work. When I am finished writing my code, would I pull the master branch code down in order to test it at that point in time or what?

If someone could give me a hypothetical answer to this, it would really be helpful. I have never worked on a team and this is why I don't understand how it works.

Also, maybe you know of some resources where I can understand this more clearly?

I just don't understand the theoretical workflow of a VCS.

Thanks in advance, Matt

Musicman
  • 49
  • 6
  • Hi @matt-paolini . From what I see you have been stressing on how will the things be tested out. I think that would need a bit more of information on how you are right now doing testing. Also if can we test things in parallel, if not then what's preventing us to do so. – Avinash Dhinwa May 16 '21 at 15:19
  • Maybe it would be a good idea to have another branch that includes the master branch files and we could merge our updates that way and test them? :) – Musicman May 16 '21 at 18:19
  • 1).Your `NewFeature` branch is an independent branch that you created off the main at some point of time. So I believe testing shouldn't be an issue here if you have your tests written for your code. 2). If someone merges their `BugFix` with master, that still shouldn't cause you any trouble as your `NewFeature` is a separate line of development and independent from `BugFix`. It just that you don't have that other developer's changes that he introduced as part of his `BugFix` branch. I am not going to comment on the testing part of the question. – Asif Kamran Malick May 16 '21 at 19:29
  • You can always have the changes of the other guy by pulling and rebasing. By default the `git pull` doesn't rebase. You can verify that by running `git config --list` and should see `pull.rebase` set to `false`. More on git pull [here](https://git-scm.com/docs/git-pull). Other helpful resources [Atlassian Git Tutorial](https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase), This [SO](https://stackoverflow.com/questions/11563319/git-rebase-basics) also explains rebase basics – Asif Kamran Malick May 16 '21 at 19:37

2 Answers2

0

How would I go about testing the new feature before I merge it to the master branch?

That depends on what workflow and team(s) you are working with. Do you do your own QA process or is there a QA team? Do you rely solely on unit testing and/or PR process before merging?

Hypothetical situation: once you are done with your feature and once it passes code review, before merging into master/develop, you give that feature branch to a QA person who makes sure that there are no bugs and everything works as expected. Giving the code to QA can come in multiple forms, all the way from them pulling the code and running it locally, to sharing with them executable binaries, to infrastructure people deploying the feature for testing, etc.

What if the person who is working on the "Bug fix" merges with the master and their code prevents my new feature from working properly?

  1. There should be a review and/or QA process to minimize chances of this happening.
  2. There should be team communication to minimize this situation.
  3. There should be tests that cover your code base so that this situation doesn't occur.

I'll combine the last two questions together

How does the other person working on the "Bug Fix" test their code with or without my "New Feature"?

How does the other person working on the "Bug Fix" test their code with or without my "New Feature"?

The same way you test your code with or without their work (QA/unit tests/review process). In the case you need their bugfix in order for you to complete your feature, then you might want to base your work off of their branch. This can be done through rebasing. Others can do this for your work as well.

Usually teams follow some form of a git workflow, where there are many types of workflows. The one I've linked is a popular amongst many, but you might also want to read the git book and see different branching models. That will also give you background how to synchronize with other people on the same code base.

mnestorov
  • 4,116
  • 2
  • 14
  • 24
0

  1. When you create a branch from master, the branch contains all the files of the commit from which the branch was created, plus any further commits made on that branch. That means you can test your changes directly on your feature branch, because all your code is there. Once everything works fine, you merge your branch back into master.

    "Merging back" will create a new "merge commit" on the master branch, or it can also work without commit in case a fast-forward merge is possible. Fast-forward means that master will simply point to the latest commit made on your feature branch.

    In git you can imagine branches to be something like tags pointing to some specific commit. These pointers can be moved around, e.g., when you create a new commit, the pointer moves forward.

  2. If the person finished working on the bug fix, and merges the fix back into the master branch, you can then merge master into your feature branch. This way your feature branch will have all new changes from master and you can test your code.

    When working in teams of some developers, it is important to update feature branches regularly - especially if their development takes more time. The more commits are made on master before merging back, the more likely merge conflicts will occur. By keeping your feature branch up-to-date, you keep the chance of conflicts low.

  3. The same way as on your feature branch, bug fixes can also be tested on the bug fix branch. If your new feature is finished and merged back into master, before the bug fix is ready, the bugfix developer should update the bugfix branch with latest changes from master before merging the bug fix back into master.

  4. This question should be answered with the previous three.

Do you know the git book? If not, take a look, it has really good information and it's worth reading for understand basic and advanced git topics, see: https://git-scm.com/book/en/v2

Sky
  • 674
  • 8
  • 22
  • That makes sense. While I am working on a new feature, I will just make sure I merge the latest commits to the master. If my code doesn't work, then the error could lie with me or one of the other developers. Yes, I downloaded the book and started reading the necessary parts. Thank you. – Musicman May 17 '21 at 18:38
  • @MattPaolini usually one wants to have only working code with functional features on master, thus it is unusual to merge commits from a feature branch back to master before the feature is fully implemented. If the feature is very big it might make sense to divide it into smaller pieces and implement them separately, one after the other in own feature branches. – Sky May 17 '21 at 19:55