• The Git Command Requires The Command Line Developer Tools Mac Os
• The Git Command Requires The Command Line Developer Tools Macbook

Git’s basic development workflow is much different. Instead of being bound to a single line of development (e.g., trunk/), life revolves around branching and merging. When you want to start working on anything in Git, you create and check out a new branch with git checkout -b. This gives you a dedicated line of development where you can. $ git -version git version 2.21.0 hub version 2.11.2 hub: use github from the command-line hub is an extension to command-line git that helps you do everyday GitHub tasks without ever leaving the terminal.

In Why Git?, we discussed the many ways that Git can help your team become more agile. Once you’ve decided to make the switch, your next step is to figure out how to migrate your existing development workflow to Git.

This article explains some of the biggest changes you’ll encounter while transitioning your team from SVN to Git. The most important thing to remember during the migration process is that Git is not SVN. To realize the full potential of Git, try your best to open up to new ways of thinking about version control.

For administrators

Adopting Git can take anywhere from a few days to several months depending on the size of your team. This section addresses some of the main concerns for engineering managers when it comes to training employees on Git and migrating repositories from SVN to Git.

Basic Git commands

Git once had a reputation for a steep learning curve. However the Git maintainers have been steadily releasing new improvements like sensible defaults and contextual help messages that have made the on-boarding process a lot more pleasant.

Atlassian offers a comprehensive series of self-paced Git tutorials, as well as webinars and live training sessions. Together, these should provide all the training options your team needs to get started with Git. To get you started, here are a list of some basic Git commands to get you going with Git:

Git Migration Tools

There’s a number of tools available to help you migrate your existing projects from SVN to Git, but before you decide what tools to use, you need to figure out how you want to migrate your code. Your options are:

• Migrate your entire codebase to Git and stop using SVN altogether.
• Don’t migrate any existing projects to Git, but use Git for all new projects.
• Migrate some of your projects to Git while continuing to use SVN for other projects.
• Use SVN and Git simultaneously on the same projects.

A complete transition to Git limits the complexity in your development workflow, so this is the preferred option. However, this isn’t always possible in larger companies with dozens of development teams and potentially hundreds of projects. In these situations, a hybrid approach is a safer option.

Your choice of migration tool(s) depends largely on which of the above strategies you choose. Some of the most common SVN-to-Git migration tools are introduced below.

Atlassian’s migration scripts

If you’re interested in making an abrupt transition to Git, Atlassian’s migration scripts are a good choice for you. These scripts provide all the tools you need to reliably convert your existing SVN repositories to Git repositories. The resulting native-Git history ensures you won’t need to deal with any SVN-to-Git interoperability issues after the conversion process.

We’ve provided a complete technical walkthrough for using these scripts to convert your entire codebase to a collection of Git repositories. This walkthrough explains everything from extracting SVN author information to re-organizing non-standard SVN repository structures.

SVN Mirror for Stash (now Bitbucket Server) plugin

SVN Mirror for Stash is a Bitbucket Server plugin that lets you easily maintain a hybrid codebase that works with both SVN and Git. Unlike Atlassian’s migration scripts, SVN Mirror for Stash lets you use Git and SVN simultaneously on the same project for as long as you like.

This compromise solution is a great option for larger companies. It enables incremental Git adoption by letting different teams migrate workflows at their convenience.

What is Git-SVN?

The Git Command Requires The Command Line Developer Tools Mac Os

The git-svn tool is an interface between a local Git repository and a remote SVN repository. Git-svn lets developers write code and create commits locally with Git, then push them up to a central SVN repository with svn commit-style behavior. This should be temporary, but is helpful when debating making the switch from SVN to Git.

git svn is a good option if you’re not sure about making the switch to Git and want to let some of your developers explore Git commands without committing to a full-on migration. It’s also perfect for the training phase—instead of an abrupt transition, your team can ease into it with local Git commands before worrying about collaboration workflows.

Note that git svn should only be a temporary phase of your migration process. Since it still depends on SVN for the “backend,” it can’t leverage the more powerful Git features like branching or advanced collaboration workflows.

Rollout Strategies

Migrating your codebase is only one aspect of adopting Git. You also need to consider how to introduce Git to the people behind that codebase. External consultants, internal Git champions, and pilots teams are the three main strategies for moving your development team over to Git.

External Git Consultants

Git consultants can essentially handle the migration process for you for a nominal fee. This has the advantage of creating a Git workflow that’s perfectly suited to your team without investing the time to figure it out on your own. It also makes expert training resources available to you while your team is learning Git. Atlassian Experts are pros when it comes to SVN to Git migration and are a good resource for sourcing a Git consultant.

On the other hand, designing and implementing a Git workflow on your own is a great way for your team to understand the inner workings of their new development process. This avoids the risk of your team being left in the dark when your consultant leaves.

Internal Git Champions

A Git champion is a developer inside of your company who’s excited to start using Git. Leveraging a Git champion is a good option for companies with a strong developer culture and eager programmers comfortable being early adopters. The idea is to enable one of your engineers to become a Git expert so they can design a Git workflow tailored to your company and serve as an internal consultant when it’s time to transition the rest of the team to Git.

Compared to an external consultant, this has the advantage of keeping your Git expertise in-house. However, it requires a larger time investment to train that Git champion, and it runs the risk of choosing the wrong Git workflow or implementing it incorrectly.

Pilot Teams

The third option for transitioning to Git is to test it out on a pilot team. This works best if you have a small team working on a relatively isolated project. This could work even better by combining external consultants with internal Git champions in the pilot team for a winning combo.

This has the advantage of requiring buy-in from your entire team, and also limits the risk of choosing the wrong workflow, since it gets input from the entire team while designing the new development process. In other words, it ensures any missing pieces are caught sooner than when a consultant or champion designs the new workflow on their own.

On the other hand, using a pilot team means more initial training and setup time: instead of one developer figuring out a new workflow, there’s a whole team that could potentially be temporarily less productive while they’re getting comfortable with their new workflow. However, this short term pain is absolutely worth the long term gain.

Security and Permissions

Access control is an aspect of Git where you need to fundamentally re-think how you manage your codebase.

In SVN, you typically store your entire codebase in a single central repository, then limit access to different teams or individuals by folder. In Git, this is not possible: developers must retrieve the entire repository to work with it. You typically can not retrieve a subset of the repository, as you can with SVN. permissions can only be granted to entire Git repositories.

This means you have to split up your large, monolithic SVN repository into several small Git repositories. We actually experienced this first hand here at Atlassian when our Jira development team migrated to Git. All of our Jira plugins used to be stored in a single SVN repository, but after the migration, each plugin ended up in its own repository.

Keep in mind that Git was designed to securely integrate code contributions from thousands of independent Linux developers, so it definitely provides some way to set up whatever kind of access control your team needs. This may, however, require a fresh look at your build cycle.

If you’re concerned about maintaining dependencies between your new collection of Git repositories, you may find a dependency management layer on top of Git helpful. A dependency management layer will help with build times because as a project grows, you need “caching” in order to speed up your build time. A list of recommended dependency management layer tools for every technology stack can be found in this helpful article: 'Git and project dependencies'.

For developers

A Repository for Every Developer

As a developer, the biggest change you’ll need to adjust to is the distributed nature of Git. Instead of a single central repository, every developer has their own copy of the entire repository. This dramatically changes the way you collaborate with your fellow programmers.

Instead of checking out an SVN repository with svn checkout and getting a working copy, you clone the entire Git repository to your local machine with git clone.

Collaboration occurs by moving branches between repositories with either git push, git fetch, or git pull. Sharing is commonly done on the branch level in Git but can be done on the commit level, similar to SVN. But in Git, a commit represents the entire state of the whole project instead rather than file modifications. Since you can use branches in both Git and SVN, the important distinction here is that you can commit locally with Git, without sharing your work. This enables you to experiment more freely, work more effectively offline and speeds up almost all version control related commands.

However, it’s important to understand that a remote repository is not a direct link into somebody else’s repository. It’s simply a bookmark that prevents you from having to re-type the full URL each time you interact with a remote repository. Until you explicitly pull or push a branch to a remote repository, you’re working in an isolated environment.

The other big adjustment for SVN users is the notion of “local” and “remote” repositories. Local repositories are on your local machine, and all other repositories are referred to as remote repositories. The main purpose of a remote repository is to make your code accessible to the rest of the team, and thus no active development takes place in them. Local repositories reside on your local machine, and it’s where you do all of your software development.

Don’t Be Scared of Branching or Merging

In SVN, you commit code by editing files in your working copy, then running svn commit to send the code to the central repository. Everybody else can then pull those changes into their own working copies with svn update. SVN branches are usually reserved for large, long-running aspects of a project because merging is a dangerous procedure that has the potential to break the project.

Git’s basic development workflow is much different. Instead of being bound to a single line of development (e.g., trunk/), life revolves around branching and merging.

When you want to start working on anything in Git, you create and check out a new branch with git checkout -b . This gives you a dedicated line of development where you can write code without worrying about affecting anyone else on your team. If you break something beyond repair, you simply throw the branch away with git branch -d . If you build something useful, you file a pull request asking to merge it into the master branch.

Potential Git Workflows

When choosing a Git workflow it is important to consider your team's needs. A simple workflow can maximise development speed and flexibility, while a more complex workflow can ensure greater consistency and control of work in progress. You can adapt and combine the general approaches listed below to suit your needs and the different roles on your team. A core developer might use feature branches while a contractor works from a fork, for example.

• A centralized workflow provides the closest match to common SVN processes, so it's a good option to get started.
• Building on that idea, using a feature branch workflow lets developers keep their work in progress isolated and important shared branches protected. Feature branches also form the basis for managing changes via pull requests.
• A Gitflow workflow is a more formal, structured extension to feature branching, making it a great option for larger teams with well-defined release cycles.
• Finally, consider a forking workflow if you need maximum isolation and control over changes, or have many developers contributing to one repository.

But, if you really want to get the most out of Git as a professional team, you should consider the feature branch workflow. This is a truly distributed workflow that is highly secure, incredibly scalable, and quintessentially agile.

Conclusion

Transitioning your team to Git can be a daunting task, but it doesn’t have to be. This article introduced some of the common options for migrating your existing codebase, rolling out Git to your development teams, and dealing with security and permissions. We also introduced the biggest challenges that your developers should be prepared for during the migration process.

Hopefully, you now have a solid foundation for introducing distributed development to your company, regardless of its size or current development practices.

• Get the Flutter SDK
• iOS setup
• Android setup

System requirements

To install and run Flutter,your development environment must meet these minimum requirements:

• Operating Systems: macOS (64-bit)
• Disk Space: 2.8 GB (does not include disk space for IDE/tools).
• Tools: Flutter uses git for installation and upgrade. We recommendinstalling Xcode, which includes git, but you can also install git separately.

Important: If you’re installing on a Mac with the latest Apple M1 processor, you may find these supplementary notes useful reading as we complete support for the new Apple Silicon architecture.

Get the Flutter SDK

1. Download the following installation bundle to get the lateststable release of the Flutter SDK:

   For other release channels, and older builds,see the SDK releases page.

2. Extract the file in the desired location, for example:

3. Add the flutter tool to your path:

   This command sets your PATH variable for thecurrent terminal window only.To permanently add Flutter to your path, seeUpdate your path.

You are now ready to run Flutter commands!

Note: To update an existing version of Flutter, see Upgrading Flutter.

Run flutter doctor

Run the following command to see if there are any dependencies you need toinstall to complete the setup (for verbose output, add the -v flag):

This command checks your environment and displays a report to the terminalwindow. The Dart SDK is bundled with Flutter; it is not necessary to installDart separately. Check the output carefully for other software you mightneed to install or further tasks to perform (shown in bold text).

For example:

The following sections describe how to perform these tasks and finish the setupprocess.

Once you have installed any missing dependencies, run the flutter doctorcommand again to verify that you’ve set everything up correctly.

Downloading straight from GitHub instead of using an archive

This is only suggested for advanced use cases.

You can also use git directly instead of downloading the prepared archive. For example,to download the stable branch:

Update your path, and run flutter doctor. That will let you know if there areother dependencies you need to install to use Flutter (e.g. the Android SDK).

If you did not use the archive, Flutter will download necessary development binaries as theyare needed (if you used the archive, they are included in the download). You may wish topre-download these development binaries (for example, you may wish to do this when settingup hermetic build environments, or if you only have intermittent network availability). Todo so, run the following command:

For additional download options, see flutter help precache.

Warning: The flutter tool uses Google Analytics to anonymously report feature usage statistics and basic crash reports. This data is used to help improve Flutter tools over time.

Flutter tool analytics are not sent on the very first run. To disable reporting, type flutter config --no-analytics. To display the current setting, type flutter config. If you opt out of analytics, an opt-out event is sent, and then no further information is sent by the Flutter tool.

By downloading the Flutter SDK, you agree to the Google Terms of Service. Note: The Google Privacy Policy describes how data is handled in this service.

Moreover, Flutter includes the Dart SDK, which may send usage metrics and crash reports to Google.

Update your path

You can update your PATH variable for the current session atthe command line, as shown in Get the Flutter SDK.You’ll probably want to update this variable permanently,so you can run flutter commands in any terminal session.

The steps for modifying this variable permanently forall terminal sessions are machine-specific.Typically you add a line to a file that is executedwhenever you open a new window. For example:

1. Determine the path of your clone of the Flutter SDK.You need this in Step 3.
2. Open (or create) the rc file for your shell.Typing echo $SHELL in your Terminal tells youwhich shell you’re using.If you’re using Bash,edit $HOME/.bash_profile or $HOME/.bashrc.If you’re using Z shell, edit $HOME/.zshrc.If you’re using a different shell, the file pathand filename will be different on your machine.

3. Add the following line and change[PATH_OF_FLUTTER_GIT_DIRECTORY] to bethe path of your clone of the Flutter git repo:

4. Run source $HOME/.<rc file>to refresh the current window,or open a new terminal window toautomatically source the file.

5. Verify that the flutter/bin directoryis now in your PATH by running:

   Verify that the flutter command is available by running:

Note: As of Flutter’s 1.19.0 dev release, the Flutter SDK contains the dart command alongside the flutter command so that you can more easily run Dart command-line programs. Downloading the Flutter SDK also downloads the compatible version of Dart, but if you’ve downloaded the Dart SDK separately, make sure that the Flutter version of dart is first in your path, as the two versions might not be compatible. The following command (on macOS, linux, and chrome OS), tells you whether the flutter and dart commands originate from the same bin directory and are therefore compatible. (Some versions of Windows support a similar where command.)

As shown above, the two commands don’t come from the same bin directory. Update your path to use commands from /path-to-flutter-sdk/bin before commands from /usr/local/bin (in this case). After updating your shell for the change to take effect, running the which or where command again should show that the flutter and dart commands now come from the same directory.

To learn more about the dart command, run dart -h from the command line, or see the dart tool page.

Platform setup

macOS supports developing Flutter apps in iOS, Android,and the web (technical preview release).Complete at least one of the platform setup steps now,to be able to build and run your first Flutter app.

iOS setup

Install Xcode

To develop Flutter apps for iOS, you need a Mac with Xcode installed.

1. Install the latest stable version of Xcode(using web download or the Mac App Store).

2. Configure the Xcode command-line tools to use thenewly-installed version of Xcode byrunning the following from the command line:

   This is the correct path for most cases,when you want to use the latest version of Xcode.If you need to use a different version,specify that path instead.

3. Make sure the Xcode license agreement is signed byeither opening Xcode once and confirming or runningsudo xcodebuild -license from the command line.

Versions older than the latest stable version may still work,but are not recommended for Flutter development.Using old versions of Xcode to target bitcode is notsupported, and is likely not to work.

With Xcode, you’ll be able to run Flutter apps onan iOS device or on the simulator.

Set up the iOS simulator

To prepare to run and test your Flutter app on the iOS simulator,follow these steps:

1. On your Mac, find the Simulator via Spotlight orby using the following command:

2. Make sure your simulator is using a 64-bit device(iPhone 5s or later) by checking the settings inthe simulator’s Hardware > Device menu.
3. Depending on your development machine’s screen size,simulated high-screen-density iOS devicesmight overflow your screen. Grab the corner of thesimulator and drag it to change the scale. You can alsouse the Window > Physical Size or Window > Pixel Accurateoptions if your computer’s resolution is high enough.
   • If you are using a version of Xcode olderthan 9.1, you should instead set the device scalein the Window > Scale menu.

Create and run a simple Flutter app

To create your first Flutter app and test your setup,follow these steps:

1. Create a new Flutter app by running the following from thecommand line:

2. A my_app directory is created, containing Flutter’s starter app.Enter this directory:

3. To launch the app in the Simulator,ensure that the Simulator is running and enter:

Deploy to iOS devices

To deploy your Flutter app to a physical iOS deviceyou’ll need to set up physical device deployment in Xcodeand an Apple Developer account. If your app is using Flutter plugins,you will also need the third-party CocoaPods dependency manager.

1. You can skip this step if your apps do not depend onFlutter plugins with native iOS code.Install and set up CocoaPods by running the following commands:

   Note: The default version of Ruby requires sudo to install the CocoaPods gem. If you are using a Ruby Version manager, you may need to run without sudo.

2. Follow the Xcode signing flow to provision your project:

   1. Open the default Xcode workspace in your project byrunning open ios/Runner.xcworkspace in a terminalwindow from your Flutter project directory.
   2. Select the device you intend to deploy to in the devicedrop-down menu next to the run button.
   3. Select the Runner project in the left navigation panel.

   4. In the Runner target settings page,make sure your Development Team is selectedunder Signing & Capabilities > Team.

      When you select a team,Xcode creates and downloads a Development Certificate,registers your device with your account,and creates and downloads a provisioning profile (if needed).

      • To start your first iOS development project,you might need to sign intoXcode with your Apple ID. Development and testing is supported for any Apple ID.Enrolling in the Apple Developer Program is required todistribute your app to the App Store.For details about membership types,see Choosing a Membership.

      • The first time you use an attached physical device for iOSdevelopment, you need to trust both your Mac and theDevelopment Certificate on that device.Select Trust in the dialog prompt whenfirst connecting the iOS device to your Mac.

        Then, go to the Settings app on the iOS device,select General > Device Managementand trust your Certificate.For first time users, you may need to selectGeneral > Profiles > Device Management instead.

      • If automatic signing fails in Xcode, verify that the project’sGeneral > Identity > Bundle Identifier value is unique.

3. Start your app by running flutter runor clicking the Run button in Xcode.

Android setup

The Git Command Requires The Command Line Developer Tools Macbook

Note: Flutter relies on a full installation of Android Studio to supply its Android platform dependencies. However, you can write your Flutter apps in a number of editors; a later step discusses that.

Install Android Studio

1. Download and install Android Studio.
2. Start Android Studio, and go through the ‘Android Studio Setup Wizard’.This installs the latest Android SDK, Android SDK Command-line Tools,and Android SDK Build-Tools, which are required by Flutterwhen developing for Android.

Set up your Android device

To prepare to run and test your Flutter app on an Android device,you need an Android device running Android 4.1 (API level 16) or higher.

1. Enable Developer options and USB debugging on your device.Detailed instructions are available in theAndroid documentation.
2. Windows-only: Install the Google USBDriver.
3. Using a USB cable, plug your phone into your computer. If prompted on yourdevice, authorize your computer to access your device.
4. In the terminal, run the flutter devices command to verify thatFlutter recognizes your connected Android device. By default,Flutter uses the version of the Android SDK where your adbtool is based. If you want Flutter to use a different installationof the Android SDK, you must set the ANDROID_SDK_ROOT environmentvariable to that installation directory.

Set up the Android emulator

To prepare to run and test your Flutter app on the Android emulator,follow these steps:

1. EnableVM accelerationon your machine.
2. Launch Android Studio, click the AVD Managericon, and select Create Virtual Device…
   • In older versions of Android Studio, you should insteadlaunch Android Studio > Tools > Android > AVD Manager and selectCreate Virtual Device…. (The Android submenu is only presentwhen inside an Android project.)
   • If you do not have a project open, you can choose Configure > AVD Manager and select Create Virtual Device…
3. Choose a device definition and select Next.
4. Select one or more system images for the Android versions you wantto emulate, and select Next.An x86 or x86_64 image is recommended.
5. Under Emulated Performance, select Hardware - GLES 2.0 to enablehardwareacceleration.

6. Verify the AVD configuration is correct, and select Finish.

   For details on the above steps, see ManagingAVDs.

7. In Android Virtual Device Manager, click Run in the toolbar.The emulator starts up and displays the default canvas for yourselected OS version and device.

Web setup

Flutter has support for building web applications in thestable channel. Any app created in Flutter 2 automaticallybuilds for the web. To add web support to an existing app, followthe instructions on Building a web application with Flutter when you’ve completed the setup above.

Next step

Set up your preferred editor.