search

usdot-jpo-ode / jpo-ode

US Department of Transportation (USDOT) Intelligent Transportation Systems Operational Data Environment (ITS ODE). This is the main repository that integrates and coordinates ODE Submodules.
80 stars 44 forks source link

Git flow #8

Closed lauraGgit closed 7 years ago

lauraGgit commented 8 years ago

It looks there are ways to integrate git into eclipse to help start integrating gitflow into your regular workflow. http://www.eclipse.org/egit/. Alternatively, the git-cli is fairly easy to master.

kristinann-volpe commented 8 years ago

My comment to the team is that right now I don't see any branches other than master on git - maybe I'm missing them, but I don't see them). I think it's pretty critical to get some type of branching workflow started soon - however you the team chooses to do so. (voice of experience on this one :) )

tonychen091 commented 8 years ago

Definitely, I've started to add my changes into the develop branch first and will plan to submit pull requests into Master for the team's approval moving forward. The branch has been pushed up

lauraGgit commented 8 years ago

You might consider adding your core dev team and Tony as a collaborators to this repo too, so that all the devs are able to accept PRs from each other.

hmusavi commented 8 years ago

We currently have two branches in the repository: • master • develop

Additional branches, such as “feature branches” and “hotfix branch” is currently not needed. We have a very small team and if more than one developer will be working on a given “feature”, we could introduce a "feature branch" for them to collaborate. “hotfix” branch is also not needed at this time because we do not have a released version that is in production or being actively used by our current customer (WYDOT). Once the software is in WYDOT’s hands and being used in some sort of production environment, we will introduce a “hotfix” branch as need arises.

Here's a preliminary protocol for our version control process. This process will be finalized and document in the coming days.

Developers and collaborators will “fork” the repository into their own personal GitHub account and push their changes to the forked repository. After forking the repository, they will create a branch to which they will to commit their changes.

Pushing changes directly to the original remote branches is discouraged by team members as a normal course of action and is best left for urgent cases. Once changes are ready to be reviewed and incorporated in the , developers and collaborators must merge the latest code from the repository or rebase their branch to the upstream and test the code before creating a pull request.

One the branch has been updated and tested, the repository will be pushed to the forked repository and a Pull Request created to merge the changes into the develop branch. A Pull Request will allow other members to review and approve the changes before merging them into the active branch. Pull requests to the master branch will be rejected. Once a Pull Request is approved, the it will be merged into the main branch.

kristinann-volpe commented 8 years ago

Thanks for the info & clarification @hmusavi , much appreciated.

lauraGgit commented 8 years ago

Hamid, I completely agree that you should govern the additional code pushes with PRs. In fact, I believe you can lock branches so they can only be PR'd to. From a management perspective, PRs greatly improve code reviews.

My concern with using forks for an established development team is that it discourages collaboration on the same feature branch. Moreover, the forking discourages your developers committing early and often to feature branches. As long as the contributors are on your team, this can reduce the burden that you are seeing with you having to approve all of the PRs.

Git makes it very easy to switch and manage additional branches, so I don't think you need to be concerned with additional feature branches. Especially, since you are only working on a couple stories a sprint, it should not take too much to keep track of them.

Many teams open a PR at the beginning of their development on a feature branch so that they can see with each commit whether it will break the build and when merge conflicts arise. They can then pull the upstream changes and merge conflicts more iteratively. This can encourage more frequent integration. This ties back to #12 because with higher test coverage you can better assure that the additional contributions meeting quality standard.

ToryB1 commented 7 years ago

One thing to consider is that , as more collaborators join in, the large number of branches used in GitFlow produced a large number of merge commits which in turn will clutter the history. With Gitflow the Master branch does not contribute to the history and some will argue that the Master/Develop split is redundant. Our goal is to keep it simple and keep the history linear so that it is easy to follow.

tonychen091 commented 7 years ago

@ToryB1 @hmusavi Are we okay with closing this issue? We've been following Ariel's comments from above, where we create a new feature branch when starting a story and we can start submitting PR's is folks would like to see the commits without having to checkout a specific branch.

tonychen091 commented 7 years ago

Closing this for now, as we've established a standard process for opening and closing merge requests.